All are limited to just 4 knobs for control and buttons for on/off ease of use i think they would fit into nicely into this if i have understood it properly
more than Id admit too … but its a continuation from Kontrol, so been going on a while.
no-one noticed, but the reason the ‘Patch’ name was in the main menu, was because it was there to select a new module
(the modules actually didnt take that long, mainly the infrastructure work took most time)
(I’ll give a brief answer, if anyone seriously wants to go this way then we can do this on a dev thread)
a very good question, which I have thrown around my head a bit …
I think it could done quite easily…
basically every module is a patch, so basically these would become pd~ , so that handles the audio routing.
the second part is parameter routing which is done via send/receive.
this actually is easy to solve, as its part of the design to allow ‘remote control’, so we could already ‘proxy’ the send/receives via that OSC comms (as a first stab) , however, the C++ code is well structured, such that it would be simple enough to move this over to use shared memory (or similar) to make it a bit quicker if required.
so yeah, I think very possible for multi core platforms.
can sound sources have their own input midi channels?
when I press the rotary coder’s button to access a patches menu (Elements, for example), it always displays the default menu first, and then switches back to the relevant screen. Am I doing something wrong?
yes, planned for 1.1, already in my dev version - i need to finalise the UI, and also create a few modulation source modules.
basically the way I have it so far is:
there are a number of ‘modulation buses’
you can attach something like an LFO/sequencer etc too a modulation bus
then there is a ‘modulation learn’ function that operates similar to midi learn, so you wiggle a parameter, then learn which modulation bus will feed it.
(and like midi learn, a modulation bus, can modulate multiple parameters)
again it has to be simple, and also i want module developers to be able to create weird and wonderful modulation modules, as well as the stock lfo/env… so byte beat, or gravity modulators
well that’s the way i have it at the moment, but as its development, it may change before release.
probably for the stock modulator, i’ll probably have multiple source modulators in one module, just to keep the module count down.
btw: Orac doesn’t care if its 10 or 30 module slots, it could be lots more… but we have to be realistic on what the hardware will support, and also so the routing modules are 'managable in your head ’
each chain, can have an individual midi channel.
e.g. if you have 3x3+1, that’s 3 chains, each can be fed from a different midi channel.
(I think this is coved in my video)
advanced tip: Router modules can be written in PD, so the ones I provided are not the only possible configurations… i had a few to start, just to keep things sane
im not sure what you mean…
so to switch modules you use ENC+AUX, (or enc+key1-10), this then displays the parameters. if the module has multiple pages (like elements) you turn the encoder to get to other pages.
the menu is brought up by pressing the encoder (and let go) then turn the encoder to select a menu item ,then press… if you don’t press or turn for a while, it will return back to the parameters for that module.
I guess what your referring to as the patches menu is the module select menu?
you use this to change the module type in a particular slot, and yes, that’s a sub menu of the modules main menu, so you always see that first…
so you select it from the menu, then scroll thru the modules types to find the one you want and the click the encoder to select.
(if you don’t click anything, or turn, it will return to the parameter page after a short while)
(all a lot harder to describe, than see/use I think )
to great ideas and achievements, (oh so much more then just modules and post-it 
