• myQwil

    They act similar to delay and line objects, but when they're in the middle of a delay or a ramp, the message "pause" will act as a toggle between pausing and resuming.

    The delay object, delp, has two additional outlets. The remaining time passes through the 2nd outlet whenever a pause occurs, and the toggle's current state passes through the 3rd outlet.

    These objects all use timers to calculate their remaining time and ramp state, which means that linp will be precise regardless of what its time grain is set to. On the other hand, it also means that linp~ will sound inaccurate if there's any discrepancy between your audio server's sample rate and pd's sample rate because discrepancies of that kind, in general, result in the audio's timing being either too fast or too slow in relation to Pd's system timing.

    Included is an example where these objects help with playback control, with linp displaying the remaining time, linp~ handling the fade-out effect, and delp triggering the fade-out and end of playback.

    delp-linp.zip

    posted in abstract~ read more
  • myQwil

    @alfonso.santimone Sorry it took so long. I finally got around to making win64 builds of my externals. They're all up on my Github page but here's gme(s)~ for the sake of convenience:

    gme.zip

    posted in extra~ read more
  • myQwil

    @deframmentazione-geometrica It looks like your select box is trying to prevent repeat values from getting through, so when random outputs the same value as it did previously, select will keep telling random to produce another value until it's different, then it'll assign that to the single number box on the right. The two number boxes at the bottom will retain the duplicate value and continue to reassign the value to each other until it's caught by the stack overflow error.

    Then again, how everything plays out will depend on whether you create the select box before or after creating the looped number boxes at the bottom, because that'll determine what gets triggered first. If you create the select box last, then the number boxes at the bottom will change and it may never even get to the number box on the right.

    posted in technical issues read more
  • myQwil

    MSYS2 is 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

    I went ahead and built plaits for 32-bit pure data. Hopefully that works for you.

    plts~.zip

    When building it, I needed to change one thing in the Makefile. See that line where it says:

    cflags = -DTEST -Wno-unused-local-typedefs -I./
    

    That doesn't work. -I./ needs to be changed to the absolute path that your plaits project happens to be in. For example, mine looked like this:

    cflags = -DTEST -Wno-unused-local-typedefs -I/c/Users/myQwil/Desktop/pd-plaits-master
    

    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 extension C/C++, then you'd build pd-vanilla based on the instructions given on pd's website and the INSTALL.txt file, and using the --enable-debug 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

Internal error.

Oops! Looks like something went wrong!