Orac : module developers guide

Nice one mate! Thanks for sharing, look forward to trying it.

1 Like

Can a module send a signal to cause an Orac preset to load? or is this not a good idea? I guess the module could cause itself to unload if the preset that it called didn’t include itself… the idea is a module to quickly select presets (and even sequence them?)

2 Likes

yes, the KontrolRack object has a ‘loadpreset’ message

it also has nextpreset, prevpreset, savepreset, savecurrentpreset,
and quite a few other messages, like selecting modules, loading modules :slight_smile:

is it a good idea?
theoretically it should be technically fine - I use a similar mechanism for switching presets with midi program change control messages.

there could well be a disruption of audio (aka audio glitch) , unless you know there are not sounds being generated (because you’d abruptly might take a wave output of 1.0/-1.0 instantly to 0.0), of if not a glitch, then audio going silent for a very brief time. (milliseconds id guess)

how quickly it will be done is interesting… if a large number of modules remain the same, then it should be pretty quick… iirc, i will just end up reloading the parameter data , rather than having to reload modules. (remember when I change modules, Im re-writing the pure data patch!)

it seems very fast when done from the UI, but if you started automating, thats when you would really noticed the time taken :wink:

knowing about what presets there are…
ok, so unfortunately, im not publishing the ‘resource list’ to PD (it is published over OSC)
but you can use getsetting dataDir to find the location of the data directory,
(if you look at any of the sample based modules, you’ll see i use this same trick for the media directory)


conceptually the only issue I see, is your likely to adding some ‘rules’ e.g. what are the presets called,
or generating a large number of presets, which might make the normal preset menu feel uncomfortable.

perhaps just bare in mind, that the way its setup in Orac 2.0, is that a user can just rename a preset by renaming the directory to what ever they like
(at some point Id love to implement a ‘keyboard’ on the organelle so they can rename presets from within orac)

also Im not sure how you will be able to make preset selection much quicker…given you have will first have to select the module (of your preset selector) before you can select … seems going to the menu is quicker :wink:


one parting thought… perhaps a way for you to test proof of concept/viability of sequencing preset changes is simply to use an external sequencer (or daw) to sequence preset changes via program change messages via midi - if it works satisfactorily there, then it might be ok from within PD.

This is great, thanks for the info. I was just thinking about a proof of concept… I’m thinking of presets as sections of songs (also thinking of sequencers that would begin playing upon recall, etc), so you can piece together music by selecting the sections, maybe the change happens at the top of the beat. hitting a button to make a selection like this would have a natural feel. true, you would need to get into the preset selection module to make a selection, but once there it is only 1 press, versus a ‘find and select’ using the encoder.

but yeah, it does open a can of worms about which presets are the ones mapped to the keys, and how are they named, etc… mostly just curious if it could work, which will probably depend on if modules have to be reloaded, especially modules that load samples which might interrupt the flow.

so if no modules change, the patch is not changed, and Pd doesn’t have to load anything, right? but if even one module changes, the patch changes and Pd will then have to load all the modules?

thanks for the tip… I’ll just make a patch for a 2nd Organelle :wink:

2 Likes

from memory, I believe not, it should just load the new set of parameters from the preset for that module.

nope, it’ll only load that one module … it only rewrites the slot that has changed.

sounds like a plan :slight_smile:

its one of those things, that perhaps if we try it, then we will find some small oddities - some of which might be easy fixes…
e.g. i think even if changing/loading new modules turns out to be problematic (*), we should be able to make it that changing settings works instantly - which would be an interesting thing to sequence in itself.

(*) the only thing that I do know is currently the audio will be briefly interrupted, as I have to stop the dsp, to prevent Pure Data audio glitching as it loads the module file.
(this we saw in Orac 1.0, so I fixed in Orac 2.0)

i’ll be interested to hear how the proof of concept works out :slight_smile:

yeah even if the modules had to stay the same and just the settings of those modules could be selected and sequenced it would be fun… I’ve been playing a lot with setting up a few chains and then trying to make different sequences or scenes keeping the same module setup, sort of like musicians playing specific instruments. quick change presets might work well under this setup.

Another random question: for graphics messages, I ran across this trying to figure out how to do a graphical representation of page parameters:

but I don’t fully understand. Is there a way to merely disable the default param text display and show a graphic instead?, for example and ADSR page that displays the envelope as 4 lines, instead of text prarams.

yes… this is pretty easy to achieve…

the answer is made up of a few concepts:

  • you can define a parameter, but if you don’t put it on a page then it will exist but not be displayed
  • you can define an empty page(s), i.e. one without any parameters on it… so it be displayed blank, and so give you a ‘canvas’ to draw on

ok, so the next thing to understand , is you need to only draw when ‘that page’ is displayed, which is why there is a message to tell you when pages are changed.
(see polybeats module as an example of this)

now… the next thing is, as mentioned above, is you will want to use parameters - because this enables the values to be saved/loaded in presets, midi learn etc.
as above, that’s ok, as they can be hidden.

you will still get the values via the sends as normal… so the last piece of the puzzle is there is a message called ‘setparam’ which sets the parameter

its defined as:

setparam module_id param_id value e.g. setparam a1 m_transpose -12.0

note:
a) getparam
there is also a getparam,
getparam module_id param_id defaultvalue sendsymbol
but this is usually not needed since you can usually just use the normal receive mechanism
b) do not be tempted to ‘send’ the value usually sent by kontrolrack
this will just get things out of sync


the only disadvantage with custom displays like this, is they will not work with ‘remote displays’ , since the rendering is specific to the organelle…
this might not seem that important for the organelle, as its got a display but I’ve got some interesting plans
e.g. controlling the orac on the organelle from a VST on your computer, for things like parameter modulation
this is likely not to work, since all though the VST will know about the parameters they won’t be on a page, and also the custom page will not be able to be rendered, since the render code only exists in PD.

anyway… thats not to say its not a good thing, e.g. i like the scope object.
its just why, at the moment ive tended not to put functionality in a graphics display that is not useable without it. (or like its not so relevant to a remote display)

thanks for explanation, this makes sense, still confused about this:

what is the module receiving if there are no parameters specified for a page? e.g. you don’t list any page params in module.json for the second page. so the second page can be used for graphics, but then you won’t receive any values at all, or no?

preset being loaded, or if midi learn so you had a midi cc mapped etc

The main point is , the pages are ‘merely’ for grouping for display- parameters still exist and can be manipulated that don’t appear on a page.

Note: when I implement the mod matrix this will also allow for non displayed parameters to be modulated.

ok, that makes sense… so taking the ADSR example, we would:

  • define params for attack, decay, sustain, release
  • define blank page for graphics, called ADSR
  • in the module listen for ADSR becoming active. lets say knob 1 is attack. When the ADSR page becomes active we receive oknob1 and use that value to draw the attack line on screen and also send the attack value back to kontrolrack ? (this is still where I’m unclear)
  • implement getparam logic for keeping things updated from presets / modulation / cc

I’ll make a simple module as an example of this once I’m sure this is the right idea.

1 Like

This is where you call setparam

You probably won’t need getparam

Say you define the param as m-attack

You should just be able to use
[r m-attack] as you would normally ( when the param is displayed)

The only thing I’d need to test is if setparam will broadcast m-attack back to the Pd patch, I think it does/should.

this appears to work. for example I just tried sending ‘setparam b1 as_cutoff 1’ (for the analog style module). the value gets sent back out, and I also checked it is stored when you save a preset. I did notice setparam takes a value 0-1 (pre scaling), is this how it should be? e.g. as_cutoff is mapped to 100-2100, so when you set as_cutoff to 1 using setparam, you get 2100 back…

1 Like

hmm, i thought it was in the scale of the parameter e.g. 100-2100
(and should definitely be consistent with getparam)

the only drawback (and perhaps why i did it like this originally) was if you use the scaled parameters, you need to know the limits (min/max)…
but i’ll take a look next time im in the code :slight_smile:

ok cool ! thanks for the insights

also wondering if it would be easier if a module could just send a flag to suppress the display of a page… so the ADSR page could be setup as a usual textual display, but then if the module wanted to display a graphic page instead, it could just send something like ‘disabledisplay module_id page_id’. this would keep platform specific receives (r oknob1) out of the module. although all the oled display stuff is platform specific stuff already going in the module, so maybe this a moot point…

one other thing while discussing param scaling. a bunch of parameters when mapped to a knob work better as ‘log pots’. for example with something like delay time going from 0 - 4000 ms, at the low end of the scale you don’t get much adjustment. in Pd I often simply square the 0-1 knob value, so first half of the knob would go from 0-1000 ms… I was thinking about an attribute you could set in the module.json parameters list indicating linear or audio taper (or just a number to which the 0-1 input value is raised pre scaling)?

Super stupid question :
how do you save the json file when edited ? (In the Organelle, editing with VIM)

I tried to make a gain module as a first module.
Couldn’t make it work, would anyone check it please ?

gainmoduletattempt.zip (1.9 KB)

I’m looking to add a “gate length” type of parameter to some synth modules. Have seen various methods employed when looking at some patches and modules. Makenote (arpeggio synth, and ORAC polybeats), and vline~ (C&G pow pow polybeats) for example. My pd skills are VERY rudimentary - what would be the simplest way to try and add this parameter to an existing synth module?
*Notes will be coming into orac from external sequencer

(I apologize for having made similar posts in other threads. In hindsight I should have started here)

in module.json, the names of page parameters should match names of parameters, so

["pg_main","Main",["gain"]]

should be

["pg_main","Main",["gain_gain"]]
1 Like

most synth modules will respond to note-on and note-off messages (essentially the same as a gate). so the length of the note or gate is determined by what is driving the synth (key presses or an arpeggiator or sequencer of some kind), usually this is the expected behavior of a synth (i.e. the notes getting played and their duration are best kept outside of the synth module). or are you thinking of release time? so when the note releases, specify how long it fades out?

if you really did want to set a gate length in a synth, you could use something like this:

[r notesIn-$1]
|
[stripnote]
|
[makenote]

so note offs are ignored (filtered out by stripnote), and makenote will generate a note off after specified duration.

you could also make a simple module that you could place before any synth that would provide this behavior, so you could use any existing synth.

I think release time won’t achieve the results I’m looking for as my MPC 1000 doesn’t have a master gate length per track parameter that can be adjusted in real time :frowning:
I like having the notes cut off super short and being able adjust up from there (without having to change the original midi sequence’s note lengths). Thanks a lot for your suggestions, I’ll definitely give this a try!

Unrelated, this was such an embarrassingly simple mod that I almost hesitate to post it - allows one to use delay module as fx or aux send from a mixer - but maybe someone w 0 pd skills will happily find it some day: delayfxsend.zip (2.4 KB)