Hi there, I think in order to do this you may need to use $0 at the beginning of the send/receive name — i.e., $0_slider instead of slider_$0. I've encountered some other quirks with the GUI objects & name variables... I seem to remember reading somewhere on the Pd-list or Pd's Github that work is in progress to standardize/fix some of them.
OK, here’s a new & improved randmodule version 2.0! Download the abstraction & help patch here:
-no longer requires a creation argument to use multiple instances (although you can still use one to enable remote input/output)
-improved/simplified control message input formatting
-added new modes (random ramps, binary output, rhythmic output), for sending output to different kinds of controls
-ability to smooth transitions between ramps (big thanks to @whale-av and @LiamG for the excellent ideas on this subject!)
-new & improved help patch
-bug fixes & simplifications
Enjoy! Please do feel free to post any audio/video here if you find a fun use for it… I’d be interested to see how other folks might work it in to their patches.
@prandam Hi there, glad you found this abstraction useful! I've actually added a lot of stuff to it since this version that I uploaded 3 years ago... I might try to clean it up & upload a version 2.0 someday if folks are interested.
I did mention in the help patch (and @whale-av is also correct in observing) that creation arguments are required for multiple instances, which also allow you to send the output remotely to any existing control in your patch via [s $1]. Sort of a built-in "wireless mode".
But, it would be nice to have the argument be an option rather than a necessity. In the past few years I've seen a few approaches for supplying a default argument if none is given by the user, which I may try to incorporate. The just-released version of Pd vanilla (0.50) has a new [pdcontrol] object that can get an abstraction's arguments... I'm very curious to see if there might be a new, slicker way to have an abstraction default to $0 if there is no argument given.
@ddw_music Thanks for sharing that audio! Very interesting timbres.
And also interesting to hear that SC uses different precision for audio versus language-side math. As for Pd, I've seen plenty of discussion on the Pd-list about going full double precision in vanilla, but it sounds like a pretty daunting task, for various reasons.
@ddw_music Intriguing! Would love to hear an example of how this sounds in SuperCollider if you've uploaded a recording somewhere.
I'm not the best one to speak to your filter question (although I know the iemlib library has quite a few filters, you could check those out).
As for double precision: yes! It can be done with the iem_dp library. However, you will have to roll up your sleeves to use it—documentation is sparse, and you'll have to compile from source. (unless you happen to be on a recent MacOS, in which case you could try the version I compiled & uploaded here)
@nickporcaro Hi there,
You might want to take a look at William Brent's DRFX if you haven't already done so:
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.
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:
It has working examples that should give you a decent idea of how to make it work.
@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:
|$1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16(
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!
@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:
(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:
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.