• myQwil

    MSYS2 was the new standard last time I checked. You can follow along with the purr data build guide to guarantee the right dependencies get installed. You only need to go as far as step 4, and you can also skip the inno setup if you're just building externals.

    https://git.purrdata.net/jwilkes/purr-data#windows-32-bit-using-msys2

    posted in extra~ read more
  • myQwil

    @seb-harmonik.ar No, I'm not the creator of the gme library. There's a lot about its behaviour that I don't fully comprehend at this point. One of the first issues I came across was the instant fade. Another was that it would come to a full stop after maybe 2 repetitions or so. I've tried preventing these issues by changing the original code in as minimal a way as possible but there are probably further changes that could make it run more smoothly in pd. Again, the only reason I added that ifndef clause is because it's what worked for me personally. I wanted it to behave the same way across multiple platforms in such a way that it repeated the song forever, leaving the stopping of the track up to the patch itself.

    In gme.zip you should see the folder gme-diff. It contains whatever changes I made to the original code. If you're building your own version of gme, you'll need to incorporate those changes to see where I'm coming from. Either way, it's worth knowing that it behaves differently on your end. What OS are you using, by the way?

    posted in extra~ read more
  • myQwil

    @seb-harmonik.ar That was there because that same issue would happen to me, but under different circumstances depending on if I was using linux or windows. I believe I was using ubuntu studio 64-bit.

    posted in extra~ read more
  • myQwil

    Hi @alfonso-santimone, at this point, none of my externals are built for win64, but I'll look into making those builds

    posted in extra~ read more
  • myQwil

    I've noticed that pd-vanilla and purr-data currently handle pointers differently, making the is.pd object work in pd-vanilla, but not purr-data. I've created another pd-native variation of the external [is] that works in both purr-data and pd-vanilla.

    While the route object in pd-vanilla can detect pointers as a type of symbol, in purr-data, a pointer is detected as a list by the symbol object, but not detected as a list by the route object. So if an atom passing through [route list] gets sent to the rejection outlet, then later reveals to have a string value of "list" when sent to a [symbol] object, we can assume that that atom is a pointer.

    is.pd

    posted in extra~ read more
  • myQwil

    You can also debug with VSCode, which is something I recently just tried out for the first time. You'd need to install the VSCode extensions C/C++ and Native Debug, then you'd build pd-vanilla based on the instructions given on pd's website and the INSTALL.txt file, and using the debug build option.

    Then open the pure-data folder in VSCode, either by navigating to that folder in a terminal and typing code . or by right-clicking the folder and selecting "Open With->VSCode"

    Then in VSCode, you switch to the debug pane and from a drop-down at the top of the pane, click "Add Configuration" and after selecting a config preset, a file called launch.json will pop up. You'll need to specify where the binary is. In my case, the location was:
    "program": "/home/myqwil/Documents/pure-data/bin/pd",

    Then lastly, and maybe there's a better way of doing this last part but the quick and easy way is just to inject your external into some part of pd's code, change the setup function so that it's static, and make sure the setup function gets called at some point, usually the setup calls are kept inside of one function at the very end of a .c file. Then it's just a matter of adding your breakpoints and re-building pd when changes are made.

    posted in technical issues read more
  • myQwil

    Works very much the same as trigger except that when you use 'a' for creation arguments, lists that consist of only 1 atom will output as the atom itself and not as a list. This also includes pointers. You'll notice that with trigger, a pointer will output as a list, which makes it difficult to type-check.

    The [unpak] object had a similar problem where it would output lists instead of raw atom values, and that has also been changed with unpak's latest update.

    EDIT: I've made it so that floats default to anything outlets and no creation args defaults to 2 anything outlets.

    x.zip

    posted in extra~ read more
  • myQwil

    Similar to [pack ] and [unpack ] but instead of the default atom type being a float, the default type is anything.

    Also comes with a new creation arg 'a' for anything. Numbers and unrecognized types will also default to anything.

    For strict type checking, use f(loat), s(ymbol), and p(ointer).
    The pak object will also store unrecognized types as symbols and interpret 'b' as a 'bang' symbol.

    EDIT: You can now send lists to any of the additional pak inlets and it will store the list values with the inlet as the starting point. For example, sending the message [foo bar 3 baz( to the 2nd inlet of [pak 1 2 3 4] would result in the list: 1 foo bar 3

    EDIT2: pak still has a bug when setting a pointer from any inlet other than the first one. This became more apparent when trying to work with the object in pd-vanilla.

    EDIT3: pak is much more stable now and works in pd-vanilla. The example includes a new object I've created called [x ], which is a kind of trigger object that dehusks lists that consist of only 1 element when you use 'a' for creation args. For pd-vanilla users, the example also requires zexy's [demux].

    EDIT4: You can now use "." to skip inlets and assign only specific ones.
    For example, sending the message [. . 123( would assign 123 to the 3rd inlet and leave the first two values the same as they were. You can also send these messages to any inlet.

    EDIT5: I made it so that the skip arg feature only applies to list and anything type messages, so if you really want to, you can still assign a single period to an inlet by sending it as a symbol. I also needed to make it so the skip arg feature also works on strict-type inlets.
    It's also worth mentioning that the proxy inlets now have their own pointer, float, symbol, and list functions, rather than an anything function that handles all message types by running string comparisons, so it should be a bit faster if only slightly, and overall better coding practice for a pure data external.

    EDIT6: The skip arg feature was only added to pak so I added the same feature to unpak as well. Using a period as an arg will skip the outlet and not send any value through it.

    EDIT7: fixed one more bug in pak, where the first inlet could only receive raw pointers and every other inlet could only receive pointers in lists. I also changed unpak so that when a stored symbol is "bang", it will output as an actual bang message rather than as a bang symbol.
    Added two more objects [@pak] / [@unpak] - reverse pak/unpak. Outputs the lists in reverse order.

    EDIT8: I've changed the pack related objects so that strict-type error messages are muted by default and to unmute them, you need to send [mute 0( to the 1st inlet. The number sent to mute acts as a bit mask for the inlets, so when a bit is turned on, the associated inlet will not output error messages.

    pak-unpak.zip

    posted in extra~ read more
  • myQwil

    @ingox I recently made a slight change to how the c external works and went ahead and made the same change to your pd external. I just needed to include the rejection outlet of the left route object. is.pd

    posted in extra~ read more
  • myQwil

    Neat! I've used route with custom messages, but it didn't occur to me that it could also be used as a type checker.

    posted in extra~ read more

Internal error.

Oops! Looks like something went wrong!