Orac 2.0

followed these to the T a few times and still, after “d” - when I go back to the lfo (m1) and take the values back up the parameter that’s supposed to have been unlearned still modulates…
In any case having a lot of fun and in the meantime just being careful to assign LFOs to parameters I want to commit to :wink:

I’ll admit I’m still getting comfortable with how 2.0 works generally so again, I may be missing something. I’m going to explore some other areas of it next few days to see if I find anything else that might be helpful for beta 3

edit: just now trying out some of the fx - these sound amazing! maybe it’s the stereo or just how I’m using them since I’m just playing around rather than working on music, but I’ll second @Wannop that sonically some things sound better/fuller here than 1.0 - really nice :smiley:

EDIT2 - my notes on fx modules:
SpecDelay - feedback pram does nothing (that I can tell)
Tremolo - Freq knob range is too big (imo). Think it would be more dynamite if the most “musical” range (1-15hz) could be the default, and then for those wanting more experimental sounds there could be a “multiplier” knob, that increases the range to be much wider.
Warps - Shape: make whole #s not percentage as it’s not incremental pram. Envelope: prams don’t work in real time, require a reset of “gate” to take effect - not sure if this is normal for warps as I’m not that familiar with, but seems like real real time changes (or at least the option of) would be useful.

Not sure if this is possible/feasible but what if there is a way to have the keys by default control two modules at a time (the s1 and the “assigned” module specified in mainctrl) and the aux key when pressed from within s1 disables the “assigned” module. This way someone could stay in s1, still use organelle keys to play another module, but have the shortcut w aux button to quickly switch pages and adjust gain etc. Even if possible, not sure if it’s more trouble than it’s worth, but just wanted to put the idea out there!

Hi Mark,

I’ve had the chance to check this a little more in depth and the scenario is as follows:

(please correct me if I’m missing out something clear here)

I have two separate audio signals, hard panned L/R in my mixer and going into C1. The parallel system recognises both signals but once I add an effect to P2 (e.g. reverb) one of the hard panned channels goes mute. If I pan it into the centre (or the opposite direction) it becomes audible but the overall signal gets summed. I took a picture of the screen illustrating what I mean, if you look at the I/O level bars you see that the input signal is clearly stereo and the output a mono sum. Hope I made it clear?


Having had a few days playing on it, it’s impressive how much more solid orac 2.0 is. The previous version would struggle to have multiple sequencers on separate chains triggering a number of respective external midi synths, and now it’s as smooth as you like! Can’t wait for the patch library to grow close to what we have on 1.0. Note Filter would be a great utility add to the new release by the way ;–)


1 Like

Just had some time to check out beta 2, mod learn is working better for me now.
Oh and lmnts is now making sound for me, not sure what was going on before.

One thing I noticed is that in both router modules the keys don’t seem to change pages for me anymore.

I’ve also started porting over some 1.0 modules. Going well so far, I like the changes to streamline module creation :slight_smile:

1 Like

@vasco ok, i’ll take a look, perhaps ive just not connected a wire somewhere…
(surprisingly easy to do :wink: though its better in pd 49)

yeah, a bug in beta2 - its already fixed for beta 3

a couple of things, that may not be obvious…
you’ll see now that modules do not pass audio or midi thru, this is so that the router can control this (which make things like bypass possible)

but this created a bit of a ‘dilemma’ for fx modules, which usually have a a wet/dry knob,
theoretically, this would have meant, just have a gain on the fx module and no dry…
so that the user would control wet in fx module, and they dry via thru-gain in the router.
but thats obviously really ‘awkward’ and not user friendly…

so what I did was add a ‘special’ parameter, which does not get displayed(*), to FX modules, called ‘thru_gain’, if this is zero, this means audio will be passed thru on the router regardless of the thru gain on the module.
so that means the wet/dry knob can be used without fear of audio also being passed thru the router and so duplicating dry signal.

also if you doing something with graphics, you might want to check latest fixes i made to a couple of the graphics modules

its nothing big, just i noticed if you switched modules from the remote interface, then things weren’t 100%, due to the delay re-displaying the screen even though the user had just switched away from the module. (ie. switching modules quickly might lead to a ‘ghost image’ on graphics pages)
I think with the latest changes, this will be a pretty good template for all modules with graphics.

(*) it simply doesn’t get displayed because its not on a page - a neat trick if you ever want to store ‘constants’ on a module , or hidden parameters :wink:

1 Like

It happens in a few effects by the way (can’t remember all I tried). I guess most organelle/orac effects have always been mono, or summed the stereo input signal somehow, maybe that’s why?

Bit lost in the mod learn chat – will there be a way or unlearning a mod without removing the modulated module?

Also, tiny tiny thing (more of a usability one) but I noticed on the latest beta version, when you’re on S1, you can’t select a specific module settings simply by clicking on it, as you had in the first beta. So you can only access it using the ‘system’ knob, which is not an issue but a little trickier to reach a module at the end of the line (or the chain settings). Is that because of some midi conflicts? Was a great feature to be able to quickly reach a module/chain settings simply by clicking on it.


firstly firstly thanks so very much for developing this… I’m on the road playing percussion and have little space to spare for electronic stuff (since I’m not using it onstage on this tour,) but with a keystep and orac I’ve got a whole world to work on in my hotel room.

I am not sure if this is an orac thing or an original patch thing, but since the pitch bend options are only found in the orac version, I just wanted to submit this as food for thought (you’re doing all this out of the spirit of generosity and adventure, I would not be so bold as to call it a request…)

Often when using a patch like analog style, or really any polyphonic pad (or any synth voice with sustain, honestly,) my usual instinct is to play it like I would an organ, where the volume (or filter frequency) is controlled by a knob or a pedal. It’s cool that we have the ability to use velocity to control the VCA in the orac version, but when trying to play smooth pads, it can be hard to get all the voices the same volume, or to avoid big jumps in volume from one chord to the next… especially on something little with pretty blah velocity response like a keystep.

If at some point velocity response were toggle-able on the same page as the pitch bend range, that would certainly be welcome, really on any kind of pad synth. Justa thought. Thanks again for all the fine work.

Yes… this has been reported before :wink:
@thetechnobear :

1 Like

Im not sure its most, but for sure , many of the original effects were mono…

does this account for everything your seeing? if is its not a bug, its more like a feature request for specific modules (as each needs to be made stereo individually)
… and you let me know, as I dont want to waste time hunting for a non existent bug :wink:

mono effects

so the choice was simple… did I only apply the effect to the LEFT channel , and then send to LEFT, or sum out to L/R.

theoretically, now with split stereo handling, I could make it LEFT->LEFT and then then user could easily centre it if they wanted to… and this was partly the idea of split stereo.

the only slight issue with this is, for performance reasons, I only do panning at chain head , and chain tail - not every module - not an issue if your only using mono effects in the chain, but not ideal if your mixing stereo and mono - which is why I left ‘as is’

I could go thru and make each effect stereo, but this obviously increases CPU ( doubling!),
also I think it would be more fun/useful, for this stereo handling to be a be smarter.
i.e. to not just mirror L/R exactly, but to perhaps have some kind of modulation e.g. imagine a L/R ping pong delay, rather than just a stereo delay.
but of course this is more effort…

also as I mentioned previously some of the MI modules (brds and wrps) are actually mono, but they have variations in thier two channels - so those need to be done a bit different too…

@jshipp, hmm, yeah, bit torn on velocity handling…
its a bit of a slippery slope trying to manage controller difference in individual controllers.

an alternative, might just be to fix the velocity at source (on midi input), so modules just see a fixed value.
but then thats close to other discussions about velocity/response curves - which can get complex, and that leads to lots of settings/configuration options - which gets really off-putting to new users.
something to think about…

pitch bend is a bit different, since often its consider specific to a sound e.g. pianos don’t usually have pitchbend, or some synth presets might have wild ranges, others have fairly tame ones)
then again, I guess that argument is true as you say of velocity, some synth sounds are more organ like, so dont need velocity response…

btw: I thought the keystep was suppose to have a pretty good/even velocity response… so this may be more a velocity response curve issue…

really needs to be thought through… so we have options, but not so many its overwhelming, and or competing (eg. someone putting the midi to fixed velocity, and forgetting and wondering why a synth patch that has a velocity curve is not responding correctly!)

Thanks a lot for the v2. Not sure why, but it seems the hanging notes in V1 resulting from “all not off” midi messages are not a problem anymore, at least with basic poly. I couldn’t be happier, rocks even more with the pyramid now.

1 Like

Thank you @thetechnobear - Orac 2.0 is awesome! 100% Next Level!

We put this printable template set together so users can map out serial/parallel chains before/after they build them: https://cdn.shopify.com/s/files/1/0159/3944/files/Orac_2_Templates.pdf

Here’s a demo video of Orac 2.0 in action. We had a lot of fun with this!

Happy Chaining Everyone!


That piece at the end is so nice, glad you played it out so long.

1 Like

I made a midifile player and looper for Orac 2.0, its very functional but still a work in progress and actually pretty fun I think!


A few questions when you have the time @thetechnobear:

I assume that the reason you cant have, say, an array of strings in a MEC rack/parameter definition is because MEC cant actually check a contents of a directory and it needs to be kept as adaptable as possible? What if we wanted to have a parameter definition that had a hardcoded string:value? Like when the knob goes past 0 it turns “Off”? Would this be easy to implement? I definitely recognize that it must be hard/not possible because of how C&G adapted patches in Orac change from strings/symbols to numbers.

What are your thoughts on pd-lua and using it with some orac things (or organelle things in general)? I actually have a different, equally functional version of my module above using a pdlua “external” I scripted and the Lua midi library. I scrapped it because at the time I thought it was severely hurting performance, but I suspect now I was simply overloading with poly synths in testing… But I think it has some great possible implementations (one thought is making a lua wrapper for graphics). The script I wrote actually uses the pd logical clock to calculate ticks relative to orac global bpm, and creates an array of makenote events that can easily be manipulated in a way mrpeach’s midifile external cant.

an ‘array of strings’ doesn’t actually make much sense in DSP…

what you are really after is enumerated values with a display function.
e.g. 0, 1 ,2 3 = saw, sine, triangle - where we use the latter to display to the user.

(the 0 = off, is kind of a special case, and could be just a special type, like I have for bool = on/off, which are really just 0 and 1)

this really is just a matter of programming , that Ive not quite got around to…
basically for remote clients, ,we need to send back all the various enumeration types so they are available in the client, so that they can be rendered appropriately.

for MEC I just haven’t decided if this can be done as a resources , which I already have in place, or need another set of messages, so its linked closer to the type.

I definitely do not want lua as part of Orac, its performance is shaky at best… :wink:
also the the road of ‘scripting UI’ means you end up with non-portable graphics/ux, something the whole parameter system of Orac/MEC is designed to avoid…

also adding another technology layer, just makes it more complex for others to understand,
which very little gain as far as i can see…

but thats just me, of course, you’re welcome to use whatever you want to implement your own orac modules :slight_smile:

1 Like

Hi thanks for your thoughts.

Yes, enumerated values with a display function is exactly what I meant. I think implementing something like this would be a good feature one day (totally recognizing that this is no small task, and you have done so much already.

And yes, I totally recognize the instability of lua and the extra complication it entails. Mostly this just comes from me being sometimes frustrated by the circuitous things you have to do in pd to get what you want, recognizing how certain problems can be very tidely and clearly done in scripting, but feeling daunted by actual external development in C :upside_down_face:. I might one day in the future do some patches/modules that has lua,pdlua bundled in them, to do simple things like list/array management… but I am always still finding clever ways to use pd and finding scripting unnecessary.

One more quick question:
The process of converting patch to Orac module is well documented, but what about the other way around? I remember you mentioning that mec can be used outside of orac. It would be nice to release modules as general purpose patches sometimes and keep my module.json system when doing so.

1 Like

I’ve just made two modulation modules people can try out.

‘drift’ will generate smooth random fluctuations between the min and max parameters, the ‘Speed’ parameter effects how fast the value changes.

‘randomsync’ will generate random values between the min and max parameters, synced to the current tempo.
Page 2 lets you change the division of the beat from 1-4 , and how many beat divisions there are between randomizations.
There are 3 additional random parameter generators on pages 3-5 you can turn on, randomized at the same time as the first one.

modulate.zip (3.8 KB)
The two folders in the archive should be placed in


yeah this is pretty simple, my older ‘Kontrol’ modules are an example of this.
though really I need to update these to the newer stuff in Orac… as I can do it a bit differently now.

it really depends what you are trying to achieve though…
at one level you could argue that you could just distribute your module and a preset to load in Orac.
what do you actually get from remove the other Orac options?

e.g. if your doing a synth module, before you know it, someone will want a reverb or chorus…
but then why would want to fix which reverb they use - the whole point of Orac, as to allow the user to switch things out?

and really, Orac’s empty slots have very little overhead so your not gaining much by removing them!

not that i dont understand why you would want to simplify, so its definitely an option.
just be aware, that from my side, its probably a bit of ‘all/nothing’ i.e. just use Kontrol or use Orac,
im not going to actively support something like a synth, with swappable FX modules - this could be done with Orac/Kontrol infra, but id likely just say at that point use orac.

of course you are welcome to do this yourself, MEC/Orac is completely open source, so others can take in any direction they choose - its just down to what do I have time to help support really.

Thanks for this @thetechnobear it looks like an amazing v2!

1 Like

this should be

1 Like