• myQwil

    I recently heard about the Zig programming language and wanted to see if I could make Pd externals with it, so I put together a "hello world" external, which showcases things like printing to console, working with symbols, and sending floats through an outlet.

    Getting it to work required using a local copy of m_pd.h and making a small change to the t_text struct, since Zig's C-translator apparently doesn't like bit fields.:

    -    unsigned int te_type:2;     /* from defs below */
    +    unsigned char te_type;      /* from defs below */
    

    Currently, the build file is catered to a Linux installation, but probably all that would need to be changed for a different platform is the system include path and the library extension.

    To do a build, just run:

    zig build -Doptimize=ReleaseFast
    

    EDIT: Changed the struct to an extern struct to guarantee the ordering of its fields.

    EDIT2: Functions are now inside the struct. This seems to be more idiomatic to Zig, plus it looks nicer.

    EDIT3: Link with libc during the build process.
    This keeps the external's size small, even when adding math functions like log or exp to it. Otherwise, there's an increase of about 115KB because those functions get baked right into the external.

    EDIT4: Replace m_pd.h with custom definitions that allow many functions to be called as methods. Some examples:

    adding a method to a class:

    pd.class_addbang(myclass, @ptrCast(&bang)); // old way
    myclass.addBang(@ptrCast(&bang)); // new way
    

    creating a new instance of an object

    // old way
    const self: *Self = @ptrCast(pd.pd_new(myclass));
    _ = pd.outlet_new(&self.obj, &pd.s_float);
    self.sym = pd.gensym("world");
    
    // new way
    const self: *Self = @ptrCast(myclass.new());
    _ = self.obj.outlet(pd.s.float);
    self.sym = pd.symbol("world");
    

    sending a float through the main outlet:

    pd.outlet_float(self.obj.te_outlet, f * 2); // old way
    self.obj.out.float(f * 2); // new way
    

    hello-zig.zip

    repo: https://github.com/myQwil/pd-zig-external

    More examples can be found on my library's Zig rewrite branch:
    https://github.com/myQwil/pd-quilt/tree/zig-rewrite

    posted in extra~ read more
  • myQwil

    @pajzd said:

    so, what does this mean for os X

    Same thing. It should work for both OS X and macOS.

    If gme(s) are not working as expected, let me know. There's a gme post where we can continue that discussion: https://forum.pdpatchrepo.info/topic/11828/gme-gmes-game-music-emu

    Also, bear in mind that the latest version of the quilt library switched from using ffmpeg@4 to just ffmpeg. That's if you download the library through deken, which I would recommend from now on.

    posted in extra~ read more
  • myQwil

    @tatsuya_yamada That would probably prove to be quite difficult. The packets would have to be retrieved in reverse order, but FFmpeg doesn't index the packets. So for the time being, reverse playback is not a feature.

    posted in extra~ read more
  • myQwil

    @whale-av You should be able to find those missing objects in the original zip of the first post

    posted in extra~ read more
  • myQwil

    Performing a static build is also an option. That would make it so that the libraries are built into the external. I've always been on the fence about distributing a static build though because I've read that some of the decoders used in the ffmpeg library are proprietary. Their site talks about that near the bottom of this page: https://www.ffmpeg.org/legal.html

    It sounds like it's only a problem if someone, as they put it, "starts trying to make money from patented technologies" but since this is being distributed freely, it's probably not an issue.

    posted in extra~ read more
  • myQwil

    Okay, I think I've found out the problem. Here's the list of dependencies of ffplay~.m_amd64:
    avcodec-58.dll
    avformat-58.dll
    avutil-56.dll
    swresample-3.dll

    But all the libraries have been updated since I built it, so the version numbers in their names have been incremented to 59, 57, and 4.

    So, you could probably just rename the dll's and my guess is it'll still work.

    posted in extra~ read more
  • myQwil

    My guess is it either needs a fresh build or it's missing some other dependency from MSYS2/MinGW.
    I recommend trying Dependency Walker. It might be able to shed some light on which dependencies aren't being met. Their site: https://www.dependencywalker.com/

    If that doesn't work, I'll see about doing a fresh build tomorrow

    posted in extra~ read more
  • myQwil

    ffplay~.m_amd64 can be found inside of ffplay.zip
    It's basically a dll with a special naming convention so that 64 and 32-bit builds of the same external can reside in the same folder

    posted in extra~ read more
  • myQwil

    Also, thank you for sharing your OSX build :)

    posted in extra~ read more
  • myQwil

    This should be what you need for the Windows version: https://www.gyan.dev/ffmpeg/builds/ffmpeg-release-full-shared.7z

    Inside the zip, there's a 'bin' folder and you just need to extract the .dll files and place them in the same folder as ffplay~.m_amd64. I'm assuming it'll still work. Even though the ffmpeg libraries are newer than when I built it, no big changes have been made to how any of the functions are called.

    posted in extra~ read more
  • myQwil

    You can find all my pd externals here: https://github.com/myQwil/pdxtra

    I wasn't able to build for OSX, but only because the environment I use for OSX builds is really old and out-dated, and I was not able to do a brew install of ffmpeg. For anyone with a more up-to-date version of OSX, they should be able to build it by installing ffmpeg and running make

    As for Windows, I did a 64-bit build (m_amd64), but not 32-bit. I came across an issue when attempting to build for 32-bit, though I can't recall at the moment what the exact issue was.

    posted in extra~ read more
  • myQwil

    @fotisandstuff I don't know about crashing, but as you start to venture outside of foo_pd's example patches, there will definitely be errors regarding missing pd externals. That's because libpd, depending on its implementation, isn't always capable of loading externals. Instead, they need to be built directly into the library. The pd.dll that comes with foo_pd only has a few externals added to it.

    posted in libpd / webpd read more
  • myQwil

    @fotisandstuff Can you give a specific example in ARGOPd?

    posted in libpd / webpd read more
  • myQwil

    I found that the images depicting equations were a bit difficult to read due to their low resolution, so I converted all of the equations to MathML with the help of LaTeXML.

    For the HTML version, I recommend using Firefox to read it, as it's the only browser thus far to offer exceptionally good MathML support. MathJax can also be used to render the MathML in other browsers. It is not included by default but it has been tested and catered to in terms of CSS styling. I would suggest getting a local installation via NPM like so:

    npm install --prefix ./ mathjax
    

    and then, using a regex-replace method with your favorite text editor, this line of html would be added to each node*.html file's head section:

    <script id="MathJax-script" async src="node_modules/mathjax/es5/tex-mml-chtml.js"></script>
    

    Several EPUB3 readers are able to render MathML via MathJax. A table showing the MathML support for various readers can be found here: https://docs.mathjax.org/en/v2.7-latest/misc/epub.html

    book-mathml.zip
    (Apr 13, 2021)

    posted in Off topic read more
  • myQwil

    You can add lines of tcl code to the .tcl files. I had a similar problem with the file dialog windows, so I added this to pd-gui.tcl in proc init_for_platform:

    option add *TkFDialog*foreground "black" userDefault
    option add *TkChooseDir*foreground "black" userDefault
    

    To change the canvas background color, you would add:

    option add *PatchWindow*Canvas.background "red" userDefault
    

    Unfortunately, if you want to change foreground color, that's specified in c, not tcl. If you're okay with performing a local build, you can check out my github fork of Pd, where I've implemented a dark theme.

    posted in technical issues read more
  • myQwil

    So I'm about 99% certain that the problem this whole time has been libwinpthread-1.dll. I think what must've happened was that back in 2018 I added the file to the syswow64 folder for the sake of convenience but then completely forgot about it. Now it comes with the fb2k-component.

    posted in libpd / webpd read more
  • myQwil

    @fotisandstuff What version of Windows are you running?

    If you look in the folder profile/user-components/foo_pd are the files in that folder recently modified? I know that I can get that error if I move or rename pd.dll.

    posted in libpd / webpd read more
  • myQwil

    Ok, I believe this is ready. It's been updated to also work with portable installations, whereas before, the "extra" folder wouldn't get added properly to pd's search path unless it was a regular installation with user components residing in foobar's AppData folder. Latest zip is in original post.

    posted in libpd / webpd read more
  • myQwil

    Not sure if there's a better solution but you could try this really simple external. It returns 1 or 0 if it finds a match or not. I only have a linux build at the moment but the source is there if you want to try building it yourself.

    EDIT: zip now includes Windows and Mac builds

    has.zip

    posted in technical issues read more
Internal error.

Oops! Looks like something went wrong!