this might also interest some
note: the orac support half way down the page…
this might also interest some
note: the orac support half way down the page…
What’s better than a virtual modular? a hybrid modular
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
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
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
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:
Thanks for yet another very detailed reply. I have been tied up with work the last few days, so hopefully I have a chance to sit down and investigate Orac and MEC some more later this week.
I should get my rPi sound HAT in the next day or two (a respeaker pi hat) looks like a promising “budget” option thats not the internal sound and it is also a similar chipset to the one used for fates.
To answer pfigs question in the fates thread, is a RPi 3 b+ Sufficient to run Orac or do you need a piSound pihat?
You can run Orac just fine on the RPi alone, but the onboard headphone out is 48khz 11bits (at max alsa volume) which is “passable” at best.
So any usb or audio piHat will be a benefit and piSound while it’s twice the price of the RPi, it is a good choice feature wise. I can’t recommend this option due to these shortcomings.
Personally, I’ve opted for a budget respeaker 2.0 piHat, it has on board mics, but sadly the line in is not connected. And there is also no midi.
In short, most piHats and any RPi supported USB audio devices should work fine with Orac and be far superior to the default headphone connector.
Is there a place to see what kinds of patches or example projects people have built with Orac? I would like to use it to create a synth style computer (preferably on a FATES board eventually) to built a sound making synthesis machine that is malleable and plays well with others.
Is there somewhere I could see/hear some stuff folks have put together?
Maybe this thread on Critter & Guitari’s forum:
Or even just browsing through patchstorage.com, many patches from the organelle have been ported for use with orac.
Orac is a framework to use multiple pd patches in tandem as if each pd patch is a module in eurorack or an effect pedal in a guitar setup.
Loopop’s youtube review may also shed more light
Thank you VERY much! This paints a much more clear picture for me. These tools are incredibly flexible, but their greatest strength of flexibility becomes the biggest hurdle to on-boarding. This really helps tho!
Great! Glad to help.
It can be overwhelming and exciting to discover all this amazing new music tech and community full of lovely, amazing, inspiring people here; just don’t forget to stop and smell the roses of the gear and tools you already have in front of you.
Or am I just projecting?
I know exactly what you mean. I actually only had a computer, maschine and a grid for 10 years. Have upgraded to an OP-Z and home made norns and realize that my limited pallet prevented me from ever really pursuing this hobby. I can see why buying gear can feel both liberating and eventually paralyzing. I think Orac will be a fantastic noise maker for me, something I can use with the OPZ and Norns/grid. But damn if I’m not already thinking “what about an OP1? Or a Digitone? Or a modular???” Haha
this is very much my personal experience too…I find it very easy to get distracted by exploring all the wonderful options we have today. not only do we have so many great individual pieces of kit, but having more than one instrument means we have a bewildering array of combinations.
its definitely something I’m trying to be more aware of, as in some ways this was a trap i fell into with software - so many VSTs being released/updated/extended on a daily basis - i found i only ever scrapped the surface of a ‘choice few’
thats not to say its bad to explore new options - it’s something I really enjoy doing (and enjoyment is my main goal!) - but something i personally i try to keep an eye on… that im not just continually chasing the next thing
yeah, im with @JaggedNZ on this … the internal soundcard is ‘problematic’, so its best to use something else… be it a ‘hat’ or a usb soundcard, your choice.
the PiSound is a good, since its well supported(*), has midi din and is ‘reasonably’ priced, but there are lots of other options - that depending on your needs may suit you better.
orac doesn’t care, all its needs is a properly configured soundcard on the rPI.
(*) many people turning to rPI , are not ‘into’ linux, and this can be a bit daunting at times - so having something working out of the box , with someone you can turn to if you have issues is important - and blokas (pisound) are excellent for this … imo, i think a few extra $ for that is worth it
e.g.bare in mind, they are also behind patchstorage.com and the patchboxOS.
Indeed, loved it as a kid
Okay, so, I just found out that Orac 2.0 running on a FATES board would incorporate the Norns system as part of its whole.
I am, frankly, gobsmacked and trying to wrap my feeble mind around this concept. I guess the best way to do it is ask some questions about how it has functioned for @TheTechnobear in his time developing/using it…
Have you tried running all of these on an early FATES board?
When running Norns with Orac 2.0, where in the chain does Norns fit? Is it top level and ORAC runs like any other script on Norns (albeit one that allows multiple scripts to run)? Or does the Norns environment run much like a single patch environment on an Orac 1.0 setup would (basically one link in the script chains)? Can one run multiple Norns patches under one blanket environment and one instance of softcut?
what’s the difference in performance of Orac 2.0 running Norns between RPi models? Is there examples of the 3b and 3b+ not keeping up? I remember there being a discussion about possible fan placement in between a FATES and a Pi4 not really being a viable option at the moment.
this might be answered by question 1, but, where does softcut end up landing in all of this? How does audio get routed around internally? With the complexity of Norns being so much higher than an organelle, I could see this getting complicated but extremely mind bendy and fun!
I totally assumed that Norns and Orac on a FATES would be an ‘either/or’ kinda deal and now my head’s spinning!! I have a million and 1 more questions, but I feel those might get answered when my hands are on it.
Sorry I think you misunderstood me…
In fates there will be a menu that will allow you to run orac or norns ( or potentially other apps) so you can start and stop each - but you won’t be able to run them at the same time.
Perhaps fates will encourage me to look into deeper integration within norns , but I’m not sure at this stage - so many different ideas and projects, all competing for time and attention
Okay. This makes much more sense. Wow, for a second I could barely see straight! It was a pretty shocking potential revelation. Haha. This is far more understandable. In this case, potentially building 2 FATES, one dedicated to Orac, one to Norns seems like my course of action.
is there a list of existing orac modules (or compatible organelle patches)? cant seem to find it here or on patchstorage
There used to be one on the C&G forum, but not sure if it has been kept up.