Pure data parameters and buttons

Here’s a template patch showing input and output parameters, and buttons, on the upcoming Witch device. Also compatible with Wizard and Alchemist.

Add the special @owl attribute to a send or receive object in Pure data for input and output parameters respectively. The attribute must be followed by the parameter you want to assign it to, along with optional min, max and default specifications. If not stated, default will be calculated as half ways between min and max, max will be 1.0, and min 0.0.
You can alternatively use explicit owl_param, owl_min owl_max and owl_default attributes if preferred. (Big up once more to @ykmm for his awesome work on this!)

The new thing is that you can map buttons and trigger/gate outputs in the same way as other parameters. Just use the names ‘B1’, ‘B2’ et c to specify which button to assign a receive or send to. (In current Alchemist and Wizard documentation this corresponds to names ButtonA, ButtonB et c)

The changes have been deployed to the online compiler and are merged into OwlProgram master branch.

1 Like

Nifty. Can we get a Faust template next?

Good idea! But let’s do it in a new thread.

I’ve been trying to put together a MIDI example but finding Pure data really difficult to get my head around!

One thing I’ve found is that I think currently [bendin] is faulty, and should produce values between 0 and 16384 instead of from -8192 to 8191. So a no-bend message would come through as 8192. No idea why this is, but it is clearly stated in the Vanilla Pd help page for MIDI objects:

Known bug: [bendin] and [bendout] are inconsistent. While [bendin] outputs values from 0 to 16383, [bendout] takes values from -8192 to 8191 - this won’t change.

Then I’ve been hitting against what I thought should be easy: let’s say I want to send pitch bend messages based on some parameter, but I only want to send them when the parameter changes. There’s a [change] object for that - but in my patch at least it doesn’t work as I’d expect. I’ve tried combinations of [int] and [change], but still I get a steady stream of identical pitch bend messages coming out. I guess it has something to do with our parameter [receive] objects firing every block, but still I thought [change] would filter out duplicate values.

If anyone wants to have a look the patch it is here: https://www.rebeltech.org/patch-library/patch/PD_MIDI

This exercise also reminds me we don’t have support for [midiin] and [midiout], or [stripnote] for that matter. The first two would be kind of important if we want to distinguish between different MIDI ports, e.g. the USB Host and Device interfaces.

Hmm just tried this for a laugh: Instruments-poly-midi-synth | Patchstorage
Is it a good patch, worth adding to our patch library?
Compiles and loads fine, but got some zippery noises when changing parameters. Any ideas?

You could try filtering problematic parameters with [lop~] to get smooth values.

Aha, the selection parameters don’t work:

[ctlin 20 1]

should only pass through CC 20 on channel 1, but instead all CCs come through.

Also [ctlin 20] is wrong: second output should be the channel, instead it is the CC id (ie same behaviour as with no init parameter).

I’ve started a documentation page: Pure Data OWL Patches | OpenWareLab

I’ve done this crazy edit of [ctlin] to try to make it work like the Puredata builtin version, ie, to allow you to select controller and channel with initialisation arguments (or whatever those things are called in Pd). The idea would be to replace the Heavy [ctlin] - and eventually also [notein] et al.

It seems to work with this test patch I’ve made: https://www.rebeltech.org/patch-library/patch/untitled_7f2b0ad5dd8c
but I’ve not got much confidence that I’ve done it the right way. Any input from all you Pd people out there would be much appreciated!

It still produces channel on the wrong outlet when a controller is passed in btw.

Updated now with a couple more spigots to swap the second outlet value to channel if a cc id has been selected.