update: version 2.0 is available, see below

Hi folks,

My first contribution to the Patch Repo (and greater Pure Data community at large)!

In my own performance patch, I found myself re-creating this concept over & over again with slightly different parameters, and eventually realized I should just make an abstraction to save myself a lot of time & energy in the future.

The basic idea is simple—essentially just feeding [random] into [line] so that values will float around within a defined range at unpredictable intervals (without discontinuities between the ramps). You can set a center value and deviation percentage, so that the ramps will stick close to a value within the overall range. For example: playing sound files with [phasor~] and [tabread4~], I often like to add a touch of warping to the speed, so with this module I can send the phasor speed to argumentname-randcenter, set a range of values around the center (with small deviation %), and let the warping begin without having to redo all of the math.

Also, the module's output is sent to both the outlet and also to a [send] which is set by the creation argument, thus you can use the receive name of an existing slider in your patch as a creation argument, set the min/max and other preferred parameters, and it's ready to go.

Finally, I added the low clip % control to prevent the "jumpiness" that results when very low values of [random] are fed into the right inlet of [metro] (which can sound like discontinuities in certain applications). So, for instance, if your maximum rate in milliseconds (set by rate_range) is 3000, and you set low clip to 10%, none of the ramps will be faster than 300 ms. And, setting low clip % to 100% will result in a regular metro pulse at the specified maximum rate.

Hope you find it useful! Feedback/improvements welcome of course. (and apologies for the messy patching with the min/max/center calculations, still learning how to keep simple math from looking incomprehensible with cables running all over the place…)

randmodule.zip
update: version 2.0 is available, see below

Cheers,
-Jon

@beep.beep Thanks for this patch! The only thing is that the abstraction isn't ready for multiple instances in another patch --I tried to use a couple of randmodules but with the second one the first started to behave in an erratic way. Any ideas?

@prandam It looks as though it is ready..... but maybe there is an error.
$1 in all the sends and receives (and objects) gets its value from the abstraction argument.
Did you put for example ..... [randmodule lala] ...... randmodule woof]..... as shown in the help patch?
The argument, which replaces $1 in any object, makes them separate and different.
I see a couple of sends with no name [s] top left and at the bottom....... but they will send to [r "patch-argument"] I think in the help patch.
David,

@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.

@beep.beep thanks a lot! and of course would be nice to see that 2.0 version! Thanks to you and @whale-av for the help.

OK, here’s a new & improved randmodule version 2.0! Download the abstraction & help patch here:
randmodule_2.0.zip

Changes:
-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.