Orac 2.0

Still trying to figure this out: Open an empty init patch. Set to parallel, put BasicPoly (or whatever) in A1. Set chain 1 midi out to channel 1, set all A modules with note-thru, and Main Ctl has main midi channel 1 and note and control ON.

Expected behavior is that when playing organelle keys on A1, I will hear sounds as well as getting midiout.

I hear sounds but my Mio2 will not light up that it is receiving midi messages like this (while working fine in regular Organelle patches as well as within a Midiout module). But even if I put a midiout module on A2 in this same setup, and then play organelle keys on A1 basic poly, I get no midi out even with midi-thru activated everywhere.

In general, it does totally make sense to me to be more focused on Midi-in for external control than midi-out with organelle keys (considering that we are now cross platform).

yeah this won’t work…

so note-thru is about passing from the previous module to the next module.
so a1 has no ‘thru’ to pass the notes on when using the active input. , it can only pass thru from the chain input.(*)

on the organelle keys, you’d have to put the synth on a2, and then have something like seq2 in a1.

for midi , you would use the chain midi in, ch = 1, = on , and then set main ctrl, ch =16 (to get it 'out of the way, to avoid confusion.


(*) im changing this in the next beta so the active input, is merged into the thru line.

1 Like

mod learn on
macro 1 to 100% , go change one or more parameters,
mod learn off
sel macro 1 to 0%
mod learn on
macro 2 to 100% , go change one or more parameters,
mod learn off

Hmm I don’t think it’s working like this for me right now, if I do this the only mapping creating is from the macro param to itself. From taking a look at the source it looks like the assignment is created when the modulation bus is sent a value, not when a parameter is tweaked, so no mapping are created unless the macro value is being changed.

If I do turn mod learn on, tweak a parameter on a module, then move the macro I want to learn, the mapping that gets created is for the right param, but it’s on the macro module ( which doesn’t have that a parameter), rather than the one with param I want to modulate. Ie a mapping for ‘as_cuttoff’ param from analog style is created on the macro module as i tha params.json below:

“m1”: {
“moduleType”: “modulate/macro”,
“params”: {

},
“mod-mapping”: {
“bus”: {
“10”: [“m_p1”, “as_cutoff”]
}
}
},

I think this is happening because the mapping is using the currentModuleID (which changes when you switch to the macro module), but the lastParamID is from the parameter from the previous module.

Just my opinion, but that sound much easier to use to me :slight_smile:
If you made the menu option default to the last bus modulated I think it might end up with fewer clicks needed!

Yeah, I forgot I had seen this - the issue is learn uses last parameter touched , and the macro is a parameter, so as soon as its touched, it becomes last param :slight_smile:

I only added at the last minute the source of the modulation so that’s not properly integrated yet - it’s primary purpose mid term is so that you can mix modulation sources
but i’ll see if I can use it to ‘patch’ this for now…

as for ‘future’ direction,
so for a while, ive been thinking to move to a mod matrix, as I wanted to do things like mixing modulations from different source on one parameter, and also depth.
(e.g. take 10% mod from an lfo, with 5 % from cv/midi)
and whilst possible with learn, it was always going to be too confusing…
but it requires quite a bit of UI work, and I wanted this version out in the wild (due to so many other changes)
so, mod learn was simple, and no UI … so the least amount of ‘throw away’, whilst allow me to see how modulation works in practice - not only lfos, but also cv.

so my current plan is, get this release done - and then look at how Id implement a mod matrix - current idea is that it be kind of a mixture of manual entry and learn/context…
i.e. when entering a new modulation, it would know what you touched last, and it would see what was being currently modulation (e.g. cc, cv, lfo) and offer these as suggestions

but its quite a bit of work, not only UI but some fundamentals, as the to mix modulations of different rates, requires the last mod value from each source to be stored - not terribly difficult but disruptive.
(this is also why currently mod learn is always ‘absolute’ rather than a relative modulation)

at this point I will also stop the modulation being visible on the screen!
this is useful for 2 reason.
a) fast modulation can increase cpu a lot
b) if the UIs parameters is a base, it becomes impossible for the user to alter if its moving!

that does mean I probably need midi to have 2 modes though - since its useful for it to be a full mapping (as it is currently) - but its also potentially useful as modulation!
anyway, that I will flesh out once I start working on it.

4 Likes

Sorry for being spotty in getting back to this work! Turned into not an ideal week for me to have time… But, yes, playing in the seq2 module with a synth going out produces midi out from the organelle keys as I wanted! I definitely like the change for the next beta where this could be a little easier (although again I recognize that this use case (midi out on organelle keys/ctl) is not really as high of a priority than the other way around (midi in to the organelle)).

I second the counter-intuitiveness with modulation, but I just want to say that otherwise the interface you have made is wonderful, truly. Changing gain/midi/whatever on a given module is so quick and I love how easy it is to remember a module on a given parallel chain with the way you have it spread out over the scale (knowing that C1 is always the middle C, B1 is always lower F, etc). One thing I have wished is maybe a separating out of the module specific controls and the “main” ones. Everything fits so nicely right now that I am somewhat hesitant to offer this, but just that if I am in parallel mode and want to go to main ctl, I have to use the Oknob to get all the way over, and this is slightly annoying. It would be nicer, maybe, to consolidate the clock module control (the D# key) with all the global controls, and leave the module gain/ctls in the C# serial/parallel key.

This is a small suggestion, because really otherwise its great interface wise.

I have made some small attempts to try and see the lower-level mec osc data with oscdump to just see whats going on, but haven’t to be able to connect (I should be able to see osc data on port 6000 right?, thats what it says in system log for mec).

Edit: also I dont if this has always been a thing, but Brds-Mono seems to have strange behavior with legato-ey notes? Like playing a new key while still holding an old one will nicely go to the new note, but when I lift off the old note all the sound cuts out even if I am still holding down the new note.

edit edit: I will also try and make some presets like you mentioned earlier technobear! Just saying I heard you there.

Biggest thanks @thetechnobear for this!!!

Apologies so late to the party - excited to get this running.

One question, is the pd49 update on patchstorage working without issue now?
Wasn’t sure if that’s what this meant, or if still need to do Terminal fiddling.

edit: from comments on patch storage looks like it - guess I’ll give it a go!

Rly excited to try out orac 2.0 :slight_smile:

1 Like

yeah, its hopefully a bit better (at least more consistent) in next beta,
but as i said really theres not a ‘quick fix’, i have to go ‘next level’ to make any real headway on this - and im not committing to this during this phase.

using the keyboard is just a shortcut thru the pages, so you can just press the last key on the keyboard, and you will get all the way to the end, so its only a couple of clicks at worst to get to main ctrl


but I like to take an opportunity to explain a bit why this is, as its a really important concept of Orac - yet i recognise its tricky to see/grasp.

so from the outside, it looks like orac is an app, which has a bunch of slots, and a couple of routing options to select how to pass the audio/midi around - but this is not at all true.

the router is ‘just another’ module, like all the others it just happens to control routing of audio, keyboard and midi.
(this means cannot move a parameter which is intrinsic to its function (where the ‘active input’ goes) to another arbitrary module. in the same way I cannot move (e.g.) e.g. braids pitch transpose parameter to the reverb module :wink: )

that may seem like an odd statement… but its true , you can happily not have a routing module in orac - it won’t care its, just the other modules won’t get any notes, and if if they create sound you won’t be able to hear it, because it won’t leave the module!

but why is this important?

well, if Id hard coded it, it be like soldering the cables into the jacks of a modular synth,
you could adjust all the parameters, but apart that it’d be fixed.

… and the deal is, there are actually quite a lot of reasons why you might want to create your own special route.
some ideas, (some of which users have asked about)

  • you have an audio interface, with > 2 input or >2 outputs.
    you can create a router, that allows you to use these, e.g. 4 inputs going to 4 chains, or chains having their own output channels
  • feedback loops
    you can create a router, that has a feedback path , e.g. from one chain, with module slots for the feedback loop.
  • send/return
    create a router which has send/return channels

all these are possible (and ones which are much more creative :wink: ) and you just need to know a little bit of pure data to make them… the sky’s (ok the cpu) the limit.

sure, I could (but im not going to!) , make it prettier , by hardcoding thing, making routing an intrinsic part the orac (c++) code - but it’d be a lot less flexible.
its a similar reason why eurorack module from the outside looks confusing, its power is linked to wearing its skeleton on the outside :wink:

6 Likes

We updated Sequencer3 to the new orac. Syncs the recorded time to the master tempo, overdub, and slot storage. ::))!!

https://patchstorage.com/u-seq3-odub-for-orac/

6 Likes

@thetechnobear Fantastic work! Orac 1.0 became my main tool on organelle and Orac 2.0 looks like a much more intuitive and even more flexible one. Thanks so much… crazy to think you did all this on your spare time.

Although I think I got myself into a bit of a pickle. I was playing with the modulators, trying out a few things as I’m not too familiar with the mod learning action and as I was trying to assign a second modulator to my set up it looks like it started to conflict with the first and my effect (reverb) went into a mad feedback and the organelle started to act really slowly which made it hard to fix. When I restarted the machine it was still acting the same way so I decided to trash the whole orac folder and install it again and what I got was a black screen. What would be your recommended way of removing it clean and re-installing orac?

I looked at the json file and removed the code that was referring to my old preset, but the only update on my situation was that I could now see the top bar on the screen although the buttons/knobs seemed completely unresponsive.

Organelle works fine, it’s just the orac 2.0 that’s acting this way. Any help would be greatly appreciated and sorry for the annoying question!

@technobear
Hey Mark,

I am having no success controlling ORAC with my iPad via lemur. The text file was not specifically clear about if i need both a PD client AND the lemur patch? Or is it one or the other?

Both the ipad and the organelle are on the same WIFI network. I start Orac and load a simple synth patch for testing. I run MEC enabling osckontrol. I have tried both host name (organelle.local) and the ip address with port 6100. The iPad Lemur is not refreshing with the orac information; it just displays the default 01234567890…etc.

Any help would be greatly appreciated.

I have updated to pd49 just for more info…

I am also attempting to control with my push2. I am able to input notes into the synth module but the device, browse and automate buttons do nothing and the screen shows no information what so ever. Perhaps there is more configuring I need to figure?

Eric

Id guess you’ve accidentally save the preset which is then being reloaded.

you can just re-install in the same way as you installed,
BUT beta 1 will not reset the default init preset, so if you saved over that it might not help
so to get a clean setup, you can remove the presets, which are all stored in
/data/orac - if you delete this folder, when you reinstall the default ones.

(beta 2, released tomorrow hopefully, will also reset the supplied presets when reinstalled)

you only need lemur to run the lemur patch

if its stays as 1234 , then it has not connected to you organelle…
(that or mec is not running, but you say it is )

did you reload the lemur project after making the change?
(lemur only resets osc targets on project load)

you need to start mec with pushkontrol.json
note: you do not want to select Push on the organelle midi settings, as this is done by mec. (for this reason, you want to start MEC after orac is running)
did the push2 pads light up as a scale?

@technobear

Hey Mark, Thanks so much for the speedy response. You’re the best!

So,
Re Lemur: With the proper start up protocol I got the OSC client working with my ORAC.

From a fresh restart of both lemur and organelle:

1&2) start wifi, Start Orac
3) Start MEC with osckontrol.json
4) open lemur app and launch orac-ipad.lemur on the ipad

It started up just fine with that order…

Re push 2: Yes, the pads are lighting up as a scale and the organelle is accepting notes and spitting out audio from the synth. I still cannot get the screen to display information. I tried from a fresh restart first opening Orac, then turning on push 2, then running mec with the push2kontrol.json. Am i missing something like I was with the OSC method?

Thanks a lot Mark

Best, Eric

Fixed it, thanks!

Actually this makes me wonder (so I don’t make the same mistake again) if you can assign two modulators to two different modules within the same chain? And once the modulators are ‘running’ you can change their settings but not the ones on the modules being modulated by, right?

I noticed a slight issue with the panning of chains and ‘post’ fx.

When you have the input signal on A1 panned hard left and on B1 hard right, if you apply an fx on the ‘post’ slot, most fx’s will sum the material (in the ‘centre’) or omit one of them. In this case, the incoming signal panned hard right goes mute. Perhaps this is to do with the fact the fx modules aren’t full stereo?

It’s works fine anyway if you bring both signals to the centre, but just sharing, since the whole system is now L/R assignable would be cool to keep it true stereo (or dual mono) all across.

Plus orac 2.0 sounds better to me, sounds crisper. Not sure what it is but feels like there’s less ‘hum/digital hiss’ coming out it all (am I dreaming? ;–). Top stuff!

no, should just work…
I need to check the udev rules are being installed correctly - if not, i’ll try to sort it out in beta 2

the modulators have no relation to the chains…so you use wherever

beta 2 fixes ‘unlearning’ of modulators.

i’d need more details… as im not quite sure what you mean.
so we are talking p2?
which fx? some fx, don’t really treat things as stereo at all - e.g. wrps, uses l/r for different purposes - this is actually pretty useful.

ok, beta 2 is up for both MEC and Orac 2.0

also a new getting started video
PLEASE watch this if you having issues setting up midi etc!

6 Likes

@technobear still no dice on the push 2 working like in your videos. I guess I’ll wait til beta 2. Keep up the amazing work man, it’s inspiring.

Best, E

k, Beta 2 is out - but I don’t think it’ll make a difference.(*)

Ive tried on both organelles I have here,
one running a beta 1 version of mec/orac, and one running the beta 2 version of mec/orac,
and both work fine :frowning:

I tried various things like having the P2 plugged in at boot time, or plugging later, running orac before mec (the best option), running mec first the orac - and didn’t make any difference.

did it about 10-20 times and worked fine, except once (see below)

so the procedure is so simple
start orac
start MEC - with pushkontrol.json
pads light up, then 5-10 seconds later - screen will show modules etc.

(make sure you have the latest MEC and Orac obviously)

ok, I had it once, not where it didn’t work the first time after booting …

now Ive seen this before, and when this happens, its seems to be a low level hardware kind of fault, basically, the underlying kernel, doesn’t seem to properly initialise it. to fix Ive found i either need to
a) MEC -> stop , MEC pushkontrol.json
(this fixed it this time)
b) reboot organelle…
(since I see the hardware failing every time - only seen this once before)
AND… im not 100% sure this is true of the ‘proper’ Organelle, as Ive only ever seen this on my ‘supercharged’ dev Organelle, so Im not sure its not due to that. the said, this is the one I use the most, so it maybe thats the reason i see it there.

so Im not quite sure what you are doing different :frowning:
what I can say is, my setup
I run on 2 different organelles, I always use mains power on both Organelle and Push 2 (when using push) , I rarely use a USB hub (but i tried with one and it worked, but Id recommend without for testing),
tests I did above were without wifi (but I also use wifi)
I use the USB cables that came with the Push2, as its a high quality cable - which is important.
I always run off the SD card
Push2 has latest firmware on it (installed by Live, at some point)

none of these really should make any difference, and as you’ve seen from my videos, Ive been using the same MEC software for ages now with the Push2 - the basic USB level stuff, is the same from the beginning…

what else to try?

Only thing I can think of is starting MEC from the command line

you can do this by going into the system folder,

cd /usbdrive/System/MEC
#or if using sdcard 
cd /sdcard/System/MEC

then typing

./mec-app pushkontrol.json 

then looking to see if there are any errors coming up


(*) I realised as I took at look at the b2 , that we don’t need udev rules on the Organelle since its running as root

actually can you try the following

cd /usbdrive/System/MEC
#or if using sdcard 
cd /sdcard/System/MEC

then typing

ldd ./mec-app 
ldd /usr/lib/libcairo.so.2

and post the results… I wonder if its not hardware, but your missing the graphics lib?!

if you are, then its going to take me a while to sort that out, as it means I need to determine all its dependancies, and release that as a package - and thats pretty time consuming :frowning: