• beep.beep

    @nickporcaro Hi there,

    You might want to take a look at William Brent's DRFX if you haven't already done so:
    https://github.com/wbrent/DRFX

    As far as I can tell, it uses dynamic patching to route signals through effects, perhaps in a similar way to what you're looking to do.

    posted in patch~ read more
  • beep.beep

    @emji Hi,

    If you're using a recent version of Pd (0.46 or newer, I believe), you might check out the built in help patches for [oscparse] and [oscformat] if you haven't already, as well as [netsend] and [netreceive].

    There's also a good mrpeach-to-vanilla tutorial patch which I've found very helpful in trying to go 100% vanilla with OSC communication:
    https://github.com/danomatika/BangYourHead/blob/master/6.Communication/mrpeach-to-vanilla-osc.pd
    It has working examples that should give you a decent idea of how to make it work.

    posted in tutorials read more
  • beep.beep

    @RetroMaximus Hi there, I see a couple of issues that might explain what you're experiencing (although no guarantees, since I'm just looking at a screenshot without being able to debug the patch...)

    Dollar sign variables function differently in objects than message boxes. Your unpack & pack are objects, which means $1 through $16 are looking for creation arguments to be passed from the parent, not values that are being passed & unpacked from the list. What you probably wanted there is [unpack f f f f f f f f f f f f f f f f(, which will send out the 16 values in right-to-left order from the outlets.

    The result being sent to the outlet is all ending up on one line of the textfile object because you are sending one "add" message with all of the values at once, whereas it sounds like you want to serialize them (textfile will create a new line for each new "add $1" message). Here's a simplification of everything between your [list] and [outlet] in the top screenshot:

    [list]
    |
    |$1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16(
    |
    |add $1(
    |
    {outlet}

    As for having to push a button twice for everything to work: that sounds very much like a problem with undefined execution order. Just for example: your [$7] object (again, I don't think a dollar sign variable is what you wanted there... it's looking for a 7th creation argument, probably failing & defaulting to zero, and effectively becoming a [f] object) is sending to a bang and the buildactivepatternPath subpatch, but you haven't defined the order. Basically anytime you need to control the order of operations (which is 99.9% of the time), use a trigger object, like [t b f] or [t f b].

    Not to only dwell on bugs though... your vertical lines & overall patching style make for a very clean & readable patch, so nice work there! :trophy:

    posted in technical issues read more
  • beep.beep

    @Johnny-Mauser For sure... (at the risk of veering somewhat off of the original topic) Here's the 64-bit [helmholtz~] I compiled for Mac:

    helmholtz~.pd_darwin
    (by the way, @katjav included a README with build instructions in the helmholtz download, and it worked right out of the box for me, so I'd imagine you can compile for whichever platform/architecture you like)

    The only other two things I ended up recompiling for 64-bit Pd were [pvoc~] from the bsaylor library, and the iem_dp library for double precision operations within normal Pd. (funny that you should mention double precision as well... maybe the latter could be of use to current you, not just future you!) I uploaded both of those in previous forum threads:

    the pvoc~ one
    the iem_dp one

    posted in technical issues read more
  • beep.beep

    If I may weigh in (on both the pitch detection & 32/64 topics):

    I have tried all three of the aforementioned objects, and personally found [helmholtz~] to work best for my uses. I can't say I was extremely scientific in my comparisons, but I generally got the sense that it performs a bit better than [sigmund~].

    When I first began migration from extended to 64-bit vanilla, all of the 32-bit externals I was using needed to be replaced, and [helmholtz~] was the one I missed the most. I replaced it for a while with [sigmund~], but eventually I went & compiled a new [helmholtz~] from source against 64-bit vanilla, which is working fine.

    Now, as for comparing performance of 32 vs 64 bit Pd in general (very much FWIW... I'm on MacOS, not Windows, and I have no technical knowledge to back these observations up): a couple years ago I did test my most CPU-intensive patch in both 32 and 64 bit vanilla, and found a modest ~15-20% CPU performance boost (according to the load meter) when using 64-bit. I remember seeing some discussion of this on the Pd-list a while back, it might have been this thread. I did not compare memory usage between versions, so I can't speak to that.

    posted in technical issues read more
  • beep.beep

    @jacoblast I’m using the same setup (Mojave + 0.49-1). I find it to be pretty stable in general, and definitely more so than the combination I started with years ago (Lion + Pd-extended, vanilla 0.46-6). Back in those days, I had something similar to what you’re describing happen a lot, where Pd would freeze and a zombie process would gobble 100% of the CPU until I would manually kill it. I never did track down the absolute cause, but I suspect it might have been a tcl issue due to my inadvisably-huge GUI for my patch. I don’t recall opening/closing patches or switching DSP to be a problem, though.

    I suppose if I were troubleshooting this now I’d ask myself:
    -does it happen with any particular patch?
    -could it be an external library that I’m loading?
    -am I running any other audio software that might be locking up Pd?

    I believe you can start Pd from the command line with flags that post errors to the terminal, but I don’t remember offhand... I think -stderr is one (?), but can’t remember specifically at the moment. Maybe that could give you some insight into what’s happening once Pd hangs?

    posted in technical issues read more
  • beep.beep

    If you're using a recent Pd vanilla (0.49), you can do this easily using the built in [array] object. You can read more about it in the help browser: Pure Data/5.reference/array-object-help.pd

    If I were tracking the play counts of 200 audio files, I would use [array define playcount 200] for storage of the stats, with each index representing a specific track. When a track is played, get the previous count at that index using [array get playcount], then add 1 to that total and use [array set playcount] to update the index. Finally, when you want to find the index with the greatest number of plays, use [array max playcount].

    Things would get a little more complicated if you wanted a top 10 most played, etc., but totally doable either in vanilla or with externals.

    UPDATE: @whale-av edited his reply to mention this too!

    posted in technical issues read more
  • beep.beep

    I discovered by accident a while ago that this undocumented functionality is actually built in to the [gemwin] abstraction. (I can't test this on versions of Gem where [gemwin] is an object that cannot be opened, which I've come across in the past, maybe in Pd-Extended?)

    You can just do this (send "debug 1" message to turn on FPS output):

    |debug 1(
    |
    [gemwin]
    |
    [route real_fps]
    |
    |here'syourFPSoutput\

    @korakinos I haven't looked at your framerate patch, but as you mentioned, [avg~] as a smoother requires DSP... if the goal is to keep FPS high, you wouldn't want unnecessary calculation going on (indeed, if you're doing any audio at the same time as your visuals, best to run it in a separate Pd instance). The other external objects you mentioned would work, or there are a number of vanilla ways you could slow/smooth output in the control domain. I myself send the real_fps output to a vslider as my FPS meter—I don't use smoothing, but I only turn on the debug output for testing purposes, never in performance.

    posted in pixel# read more
  • beep.beep

    @jancsika Congrats, and many thanks for including the "diff view" idea we were discussing last week as a part of this!

    posted in news read more
  • beep.beep

    @jancsika Brilliant!

    Yes, I see how the situation becomes complicated very quickly—my original mental image was of a single Pd canvas with black (unchanged), green (new/modified), and red (deleted) Pd objects, perhaps with view filters to compare versions. But indeed, the question of how to handle canvas resizing, subpatch/abstraction changes, etc. within a single window sounds like a messy one to answer.

    Also, the notion of recording every canvas edit poses a useful question to me: what level of detail do I really want/need to save as I develop a project? There have certainly been times when I wanted quick access to an old version of a part of my patch, but if I were to comb through a sequence of hundreds of individual edits to find the right state, I could see this ultimately being more work than simply redoing the work anew. I assume this is the idea behind “commits” in Git, which represent meaningful milestones, so for now I’ll keep studying up & see if I can get a good workflow going that way.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!