Orac 2.0

yeah graphics modules I want to be careful with, I need to do a couple more to show developers how I want them to work. (the current ones just show the mechanics, not how to interact with parameters)

its REALLY important that developers use the graphics to render what the parameters are doing, and that they change the underlying parameters to follow any changes they are making . (this is like the VST model for those that know such things) - and also make the underlying parameters available to the user.
(for this reason, its now possible for module code to set a parameters value, and also do an adhoc query for it current value)

if they don’t do this it will become a complete mess…because end-users will then start finding that they load presets and they don’t sound the same, and things like modulation won’t work, and also users on platforms wont be able to use the modules.

this would upset me, as Ive worked hard to make sure that the architecture, ensures that modules act pretty consistently to the user.

but Im sure with some good examples, this should all become clear, and developers will understand the benefits of the ‘right way’ :slight_smile:

2.0 is proving to be such a joy for me go use. It’s remarkable how intuitive of a modular system you’ve created using only a keyboard, 4 knobs and a tiny screen. My partner(who has no interest in music making or synths) remarked last night “wow, all that sound is coming from that one little thing?”

Bravo and thank you!

3 Likes

That’s probably subjective.

I had some luck reverse engineering the PD app by wiring [r oscIn] and [r oscOut] into [print] objects, but couldn’t otherwise identify the “P1”-“P8” prefixes. (I think they’re fed into the ctrl.pd subpatches through abstraction arguments, but right-clicking for properties doesn’t reveal those, and Google isn’t terribly helpful on that front, either)

So, at my current skill level with pd (I’m really more of a max guy), the Lemur template was far more intuitive for me to reverse engineer than the pd one.

…but that probably won’t be true for other members on this particular forum.

so my pd client issues were indeed firewall related. so thats fixed and its a handy thing, although I do echo a lot said here and in the blokas forum about the usability of the client as the standalone interface.

I definitely think there is potential to lay things out differently for the client, but I understand totally what you did here.

here is something I am having trouble with. say I want to have my organelle midi connected with my mpc so I can make midi loops. what is the proper way to do this if I just want to use the organelle keyboard? first of all with one chain, and second of all with three pointing to different tracks on the mpc? is the midiout module necessary?

If I have just a synth on module one, and I try setting, say, Chain 1: Midi Out to channel 1 (the mpc is picking up all midi channels either way), as well as Midi In ON, set channel 2. but I can never seem to get midi out signal this way if I am just playing the synth on the organelle keyboard (this is like the opposite problem than above). I also make sure and set the Main Ctl to channel one and Note is ON.

I guess the main thing for me right now is the “active input” doesnt seem to be working (this is like the opposite problem than above). playing mpc pads does feed midi in like its supposed to.

I can play the orgnelle keys within the ‘midiout’ module and get midi out!

As far as I know, there is no issue with active input - just some can’t get their head around it!

The only midi bug, which I’ve fixed but not released, is that channels 2-16 are monophonic - this is not specific to active input.

Sorry the rest i don’t understand what your trying to achieve.

Please re-read my various explanations of chain midi vs active input - I really cannot think of a way to make it clearer than I’ve already stated multiple times.

( once you’ve read them, hopefully you’ll understand why have midi ch 1 for both a
Chain channel and active input makes no sense )

btw: @miker2049 if your not getting midi outputs, make sure you are using ‘note-thru’ on modules if you are using midi output module (which you probably dont need) , or chain midi output (which is probably what you want) - modules no longer pass notes thru - this is now a function of the router and is off by default. (as its not what most users need/want, and consumes resources)


changes for next beta (b2)

speak now, if you disagree - and have a very good reason :wink:

so Im going to be changing the init (and demo) presets for the next beta
(if you have created presets you may want to consider similar changes)

(where applicable, the following will also default in the appropriate module)

a) Im going to switch to the parallel router as the default for Init
as 3/4 modules in a chain + post process is probably enough for most,
(so generally more useful that serial)

b) midi chain input is going to be ON,
for chain A it will be midi ch 1
for chain B it will be midi ch 2
for chain C it will be midi ch 3

c) active MIDI input , is still be active, but will be moved to midi channel 16

the idea is simply, that a new user can chuck a synth in a1, b1, c1, and just play with midi ch 1, 2, 3
and it will always play regardless of which module they are have selected.
this I think is simplest for most to understand, and then ‘active input’ is more of an ‘advanced’ feature.

Im NOT going to change the Organelle keys active input, it will still follow the selected modules by default, as this IS usually what you want, for a whole range or reasons - and is not generally confusing since its fairly obvious to associate the display with the keys underneath them.

Ive fixed, any (reproducible) bugs that have been reported so far (not many as it happens),
changed a few things from feedback (thank you)
added a few improvements,
and Ive got a couple more little things I want to do (like demo presets),
then I plan to make another beta release.

so IF you have any bugs, that you can reliably reproduce, please speak now!
(its a lot of effort for me to release on all platforms so Im not going to be releasing that frequently!)

2 Likes

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?