Orac : open source instrument thing ;)

Odd , i was assigning button actions without issue the other day :confused:

(But perhaps may be a small bug , in fairness they rushed out the new module feature for Orac)

As you say follow up with Blokas they are really helpful/responsive.

@AlessandroBonino cool stuff :slight_smile:


ok, final release day :slight_smile:

Orac 2.0 on Eurorack , specifically for the Bela Salt and Qubit Nebulae

video contains install instructions and how to use cv modulation, and description has the all important download links :slight_smile:

this is quite an exciting area for me, as its a bit different given the CV modulation and input.
the idea is it makes your module a kind of multi-purpose module, but one that you define.
Ive found it a lot of fun, and Im looking forward to exploring this with some specific CV modules.

as I said earlier, Im going try to make some time to put together a ‘getting started’ video to cover more general usage - but for now take a look at my Orac playlist for other videos which do a good job for 1.0, for which most is still applicable.


very curious about this!

1 Like

This is one of the coolest and most exciting open source music software projects IMO.

1 Like

this is awsome! well done the technobear again. :upside_down_face:

1 Like

beta 2.0 up at Patchstorage.com
(should make things a bit easier for newcomers)

eleased a ‘Getting Started Guide’ , which covers what to do one you have it installed :slight_smile:


This is really interesting to me! Pardon my ignorance because I’m a complete noob at this but I’ve been doing some research the past few days for a project I have in mind.

I’m hoping to make a small “rings” box for live performances where I don’t want to take out my entire modular system. Just a small box with midi input (for playing notes and midi CC modulation ideally) running a single instance of Mutable Instrument’s Rings with 5 knobs on the front. It looks like you have a port of rings up and running on PD and then in Orac as well.

What do you think would be the best platform to run Orac on, given I’m hoping for enough I/O for 5 potentiometers, DIN midi input and audio out. From the research I’ve done so far I’m looking at Raspberry Pi w/ Pisound and Bela as options. I’ve also read good things about Axoloti but haven’t had the time to look into it yet. Of those three options I’m not sure what would have the required I/O and give me the best experience from a latency / audio quality perspective. And for that simple of an implementation would Orac even be necessary or would it be better to run Pure Data directly?

Basically I want to make something not too different from an Organelle, but with controls that are mapped for my specific purpose and without the screen / key buttons. The plan would be to control it via midi from my Digitone or Digitakt.

these things are all a matter of what you want to do exactly…

if you just need rings, then you don’t really need to use Orac , which is more aimed at combining things - you could just use my PD wrapper/patch for rings - but you’ll need to do midi mapping etc if you want that… but that doesn’t take that long in PD.
(or yes, you coudl just use axoloti which I also put rings on.)

rPI w/ pisound is more powerful than bela, both cpu and fpu.
(but a single rings is not going to require much cpu) - but IO is not as easy as bela, but perhaps MIDI is enough?

bela’s advantage is its got (8) analog inputs for your pots, so thats easy, just a small tweak to the rings patch and your done. its also much lower latency than rPI based solutions. bela doesnt have midi din, but you can add it simply enough, or use USB din cables.

axoloti, if it does what you want, is cheap and is instant on (unlike bela/rpi solutions which take a few seconds to boot), its like bela very low latency - but its less powerful, but its completely dedicated to the task - so its surprising how much it can do!
(axoloti does not run PD, it uses its own patcher, which is ‘similar’ )

if you want something general purpose, and might need more cpu, then rPI is probably best (but you need to think about IO for pots)
if you really want to build a custom instrument, so need more io, and want lowest latency , then I tend to go more towards Bela/Axoloti - they are both really designed for this.

(bare in mind this is all comparitive, any of the above would probably be fine!)

Thank you for the very thorough reply! I guess the two use cases I envision are 1) having it hooked up to Digitone / Digitakt for fun parameter locking / sequencing stuff, in which case I really wouldn’t need on-board controls but also 2) hooking it up to my keystep and just using it as a stand alone voice. I’d like to be able to do both those things so I think I’m going to lean towards Bela / Axoloti.

Thanks for all the feedback, I’ll have to look more into Axoloti and decide from there. If that’s the way I go, where is your Rings for Axoloti patch stored? I originally found the MiforPD just on google before I realized you were an active participant here at lines :slight_smile:

Also, any eta on when marbles for PD / Orac might be available? I want to start with a little rings box since I’m new to all of this but my dream project is to make a fully hands on generative machine with like 20 knobs based on an Orac patch running Marbles + a couple of instances of rings and some effects. (Hopefully something like this would run stably on Bela? Assuming that’d be too much for Axoloti).

hmm, actually, just remembered Id only ported the fx parts of rings to axoloti - so they may not be suitable for you.
(these are in last firmware, and I’d planned to add the rest of rings, but the firmware for axoloti is under going an extensive rewrite - so its on hold for now)

marbles, not sure - I really need push out the final release of Orac 2.0, and then there are a few other projects I’m working on that need to be progressed a bit, then I can take a look at marbles - but no idea when this will be.
the main issue with orac and marbles is working out how to feed the modulation around orac in a useful way (*) … just doing the PD external is not that difficult.

(*) one of the things about Orac is you don’t want to be doing individual patching of ‘wires’ on a small device with a limited UI - and marbles kind of wants this, due to its t1-3 and x1-3 outputs.

Ahh well that at least narrows down my options for now. I’ll probably go with Bela for this first project.

As far as the Marbles idea, the thing I had in mind would have t1 and x1 “hardwired” to 1 instance of rings strum and v/o inputs, and then a second instance of rings on t3, x3. So really just using it as a sequencer, not a modulation source for anything else. I do see that you have a few interesting sounding sequencers already up in running in Orac. I’ll check those out to see if any combination of them gets me close enough to what I’m envisioning.

Orac news

a little bit of news…


One of our fellow orac users, Ben Norland has kindly designed a logo for Orac, which I’ll be rolling out over next few days :raised_hands:


he has also designed a number of variations, which will be being used in other places… which Im also looking forward to using.


the guys at Patchstorage have given Orac its own ‘platform’ , which we will be migrating all things Orac over to … this will make it easier for users to find new modules etc.



Also, 2.0 is out of beta, and has been for a while.
(I don’t think that’s actually been mentioned here yet.)


Hey everyone! I have released a web client for the ORAC 2.0 - it runs on the Pi, so you can just open it up in your browser and you’re good to go. Installation instructions and more information is here on GitHub. I will appreciate any comments/suggestions/bug reports, hope this is useful!


this might also interest some :wink:


note: the orac support half way down the page…


What’s better than a virtual modular? a hybrid modular :slight_smile:

Ive been working on a new set of modules for Orac, called (un-imaginatively) cvtools
more details here:

basically what you’d expect, support for cv clock in/out, note in/out, modulation

its a lot of fun linking up the Organelle to the modular… lots of possibilities.

oh, this also works on the rPI too :slight_smile:


looking these over, it appears that the cv tools will work on any computer using vanilla and a dc coupled interface?

Well they are orac modules , so that’s how parameters are controlled - but for sure, orac is cross platform too :slight_smile:


I’m also looking at building a custom ORAC “instrument” based on the rPi platform, but I’m a bit stumped on the right way to implement it.

I want to have keys, 5 encoders, potentially multiple displays and a bank of potentiometers (pre-mapped to the Px slots?) and I’ll use an Arduino or similar for most of the IO, with a serial to midi/OSC running on the rPi.

Is Midi or OSC or a combination the best option? Can you control ORAC menus via Midi? And the Aux button?

Should I modify the ORAC mother.pd (pi or organelle) or MEC? I’ve looked at MEC and it’s a bit daunting as to where to start?

Also, I created a quick script to update an oled i2c display via MEC display OSC and had issues with the menu overwriting the file list. It’s also a bit slow but that’s likely an implementation issue (update on every text message)

there are a few options :wink:

first, I recommend you get used to Orac using the the remote display options Ive provided for the rPI,
as its important before you do any kind of implementation that you understand Orac from a user perspective quite well…

once you have done that, you will understand MIDI is used for notes, and also midi learn of parameters - this is a ‘user level’ function, there are also some extras for mapping things like Aux key and expression input etc. (see router)

the principle idea being you can control Orac ‘headless’

then we move on to ‘providing a UI’ , this covers everything from controlling parameters, to selecting new modules, saving presets etc etc etc.

here there are currently 2 options…

a) quick n’ simple - OscDisplay
this is the interface the Lemur and PD client patch use, its very simple to use, since basically you can send and receive OSC messages to just control the ‘menu’ and parameters.
but its kind of like a ‘dumb’ client - the workflow is already dictated, you dont have to be concerned really with how Orac work, or providing a UI for browsing modules - its all done for you.

I’d recommend you start with this one, to just get you going…
(it’ll also means it feels very similar to organelle etc)

so the limitation of OscDisplay , is it makes lots of assumptions about how Orac is going to work, and how the workflow is… e.g. a central menu - this is what makes it so quick to build new clients,
you only need to deal with a few messages and bang you have all the functionality of Orac

b) full OSC control
Orac itself has a full OSC implementation to do pretty much everything, this is actually what MEC uses to talk to Orac and then is able to implement OscDisplay, and also a Push 2 interface.
this OSC interface makes very few assumptions on how you are using Orac, so you could do things like have multiple displays - or make use of dedicated buttons… have a display of arbitrary size.
(if you look at my Push2 demo, you will see that the UI on the Push2 looks nothing like the Organelle UI)

the downside is there are a lot of messages, and currently as Im the only one using it… its not documented that well… so you pretty much have to grok the code, or use something like oscdump to see what messages are flying.
also… your ‘app’ will need to be able to handle state e.g. meta data is sent about what parameters there are on a module, and what modules are available - you need to be able to keep that, for display purposes. (whereas OscDisplay is ‘stateless’ so much easier to use)

if you are going to use this OSC interface, you’ll also need to have a much better grasp of how Orac is used, and also a little more about how it works.

do you need to put your extra code in MEC? no not really, but if you know C++ it might be easier… as you could potentially reuse some of the existing code there - e.g. you might find some of the ‘state’ handling useful.

as with all programming, lots of different ways to do it, depends on your skills, and time available and how ‘integrated you want it’ on which way is best for you.

a couple of small notes:

  • I’m going to be adding supports for Fates shortly, so the implementation of that may give you some ideas.
  • I plan to reorganise the MEC device code (OscDisplay/Push2/Organelle) a little bit in the future, to make them a little more consistent, and allow them to either live in MEC or PD directly (in KontrolRack)
  • I don’t have much time for support of this till about Mid Sept due to other projects
  • I know I should write up the OSC messages, and I plan too - but its not happening for a while, due to my other commitments.