Orac : release 1.0


#223

Already done :slight_smile:

I’m using an approach sometimes called split stereo on input and output per chain. This provides a lot of flexibility on not only panning but also procesessing

Theses a couple of other ideas I’ve got around mono vs stereo processing but those are not fully formed yet , and are potentially problematic due to the increased processing overhead, so I need to test and think about these before discussing/make any decisions on them


#224

Nice! That sounds great, actually a lot more potential in there.

I wasn’t thinking that far, I would be happy with a standard scenario where if you connect a mono signal into the left input socket it defaults to dual mono (out) and if you plug a stereo one it modulates and outputs the signal in real stereo… but think your suggestion is going to raise the bar well high, can’t wait.


#225

I investigated a bit further into the grds module. I am not sure what exactly happens, but I confirmed that the clock is fine. The problem is that “grids” itself somehow interprets an input of “16” as the start of a measure. I checked the output of “pg 32nds” and when it says 16, “grids” produces a beat. I quickfixed this by offsetting the output of “pg 32nds” by 16… Of course this fixes the problem only sometimes in my specific configuration. I think syncing the “grids” modules with master-beats would solve the problem.

The reason the standalone module does not have this issue is probably, that the clock is initialized at the same same time as the grids itself, so it starts at 0. But I am not sure of that.

Edit: I am building a master-beat synchronized version right now.
Also, U-clock says that it send master-beats, but it doesn’t.


#226

hmm, yeah, as i said i’m going to review the whole sync’ing thing.
basically, whilst sequencers keep the clock in sync, they dont sync at more appropriate boundaries (like bars/phrases)

Id like to at least have a global start/stop , so everything can at least start at the same time :slight_smile:
(this could be your issue, if you are loading grids, into an existing rack, and the clock is already running)

Ive been considering the concept of beats n bars, and using these to sync modules, but many of the sequencers are built in a way that would make them tricky and time-consuming to do that.
but, the thing is this is where ableton and link have it right, using clock pulses, and having individual things count doesn’t work well with multiple sequencers (the only hack fix , is global transport start/stop)

anyway, its a big area, which is why Im reviewing it, I want to make some headway on it on 1.1, then hopefully keep improving each release… (which might involve rewriting the sequencers one at a time :frowning: )


#227

I’ve prepared a branch (of course basing on your 1.0 because that’s what I currently work with):


I have exported master-beats and patched the 32nd submodule in grds. The Ableton Link module is pretty awesome and I just export master-beats right from there in U-clock. The down side is, it doesn’t work with just midi clock and I don’t know midi stuff well enough to know if that would be even possible. Maybe we need midi time codes for that or something like that. A quick workaround would be a configurable offset in U-clock.

Anyway, if Ableton Link is active and then U-grds is loaded, the measures are synced.

U-grds%20patch

Also, I think I’ll try to do a beat synced sequencer next. I want at least the start and stop commands to by synced to beats. That should be pretty easy to patch.

Pure Data is weird, but fun.

Edit: Seq2 is not very suitable for that conversion. I may try to build a new clip-launching sequencer that records midi clips and plays them synced to the beat. This however is a daunting task for a pure data beginner like me, so I do not expect usable results for quite a while. Maybe I can bend the Midi File Player to my will.


#228

I realize I’m late to the party but it has to be said again! Thanks @thetechnobear you’ve really outdone yourself. Really well done sir!


#229

First; HUGUE Thanks for ORAC. It was my final drop to order an Organelle!

It’s perfect (for what I do;) with the Arturia minilab mkii. Lot’s off fun!

However, I cannot get the midi sync (as master or slave) with my disaster area smart clock gen3 at the same time than my minilab controller. I have to choose between the 2 in the setting menu. I use a usb hub and both device are recognize and work well independently but can only use 1 at a time. Any idea how to make it work?


#230

if you want two midi devices you need to configure these ‘manually’ , as covered in my video, see here


#231

Thanks. saw the video after posting. I’m stuck to opening the .sh file in my windows 10. I guess I’ll get it out somehow… Spend hours but I’m totally new to the linux stuff…

People with Windows 10 how you do?


#232

You can edit it with notepad.
( or any other editor that will save it as plain text)


#233

THANKS, KIITOS, MERCI!!! Notepad did it! Now I have the minilab for keys, knobs and pads all that while the smart clock is giving tap tempo and midi sync! Wonder how I miss the notepad app…

Again thanks!


#234

First, I’m a very new Organelle user and I’m so impressed with Orac. This is everything that is so great about Open Source and I really appreciate the time and effort you already have and are continuing to put into this @thetechnobear, also everyone else who is converting and making new modules too. Orac definitely pushed me to finally make the purchase.

I’m definitely a noob when it comes to using the Organelle, synthesisers and of course Orac, I’m also very aware that this is version 1.0 and the focus was and is on creating a stable set of features. So I hope I don’t get flamed for suggesting something UI related. I think it’s always good to get the opinions of less technical users on UI though. So that’s me and here goes…

Yesterday I made a chain of modules and made some nice musical sounds, I had 4 or 5 modules in which I’d spent some time adjusting parameters etc. I wanted to remove one of the modules, clicked the encoder, clicked “Default” and clicked “Default” again. Of course, this reset everything and I lost an hour of adjustments I hadn’t saved.

Now I know this was a mistake from me (I watched the videos, that’s not how it works) but I’m wondering if it’s possible to design this interaction slightly differently or simply change the wording to make this part more user friendly:

  1. If the text “Default” that resets all modules instead read “Reset Orac” or “Reset all modules” or “Empty all modules”. This would make it very clear to the user what this interaction does.
  2. Add a dialog that requires user confirmation. Could clicking “Reset all modules” lead to a dialog that read “Are you sure? This will empty Orac. Yes/No.” This extra step and user interaction would act as a safety net and remove the possibility of deleting a project by accident.
  3. Lastly, and this one could probably make me sound dumb as I bet there is a good reason for this terminology. But instead of the term “Default” with regards to empty modules, couldn’t they instead just say “m2:Empty, m3:Empty.” etc? :confused:

I’m hoping all this doesn’t only highlight my lack of understanding of how to use Orac. :wink: I know what a complicated technical project this is but I do think if as Orac progresses, you/we are able to make the user experience as enjoyable as possible it’ll make Orac even more of a pleasure to use. Maybe this can make it onto a spreadsheet of UI ideas for a future update.

What do you think? :see_no_evil:


#235

thanks for the feedback, and really glad your enjoying it :slight_smile:

ok, the ‘default’ preset is not at all a reset !
its just the default preset that orac uses when it initially loads, you are actually free to change this, and save another setup as your ‘default’

and so yeah, I know if you don’t know its a bit of a pain,
but on the flip side, I think most would find it pretty annoying, if every time you flipped presets you had to confirm the change.

bare in mind, a preset might just change some of the settings of the modules, not necessarily start switching modules.

‘ah, but what about asking to confirm loading a preset if you’ve not saved it’
unfortunately that’s also going to be pretty annoying, since as soon as you touch one parameter value, it’ll mean, you’ll end up having to confirm on preset switch again (i.e you’ll be back to having to confirm every preset change)

‘what about doing it if you have made a significant change (e.g. change modules)’
unfortunately, I think that’ll be feel inconsistent, as users wont know when they will be asked to confirm and when not… and someone will complain to me that I didn’t confirm when they wanted it to… and we will be back to , confirming on every preset change again.

that’s the problem with UI design, its tricky to make it feel fast/fluid for users that know the product well, yet at the same time, not trip new users up - who might not understand the workflow yet.
(and on the organelles tiny screen, im pretty limited on what can be displayed)


#236

Whoops! :upside_down_face:

So that makes 1 & 2 irrelevant, you’re right, a dialog would irritate most users.

But 3:

I think that’s why I found this slightly confusing, isn’t the term “Default” being used to describe two different things within Orac? Empty modules and the Default preset that initially loads?

If the modules instead displayed;

m0:Polybeats
m1:Basic Poly
m2:Empty
m3:Empty
m4:Empty

Wouldn’t that be a clearer UI? It would clear up this screen:

If I’m still getting this all wrong feel free to just tell me to watch the introduction video again :sweat_smile:


#237

Yeah, the default module, basically does pass thru audio and midi.
I’ve changed this in Orac 1.1, so pass thru is down by the router, so was already considering have an empty slot.
A few things are changing in this area, so I’ve not totally finalized my ideas, but will be different :slight_smile:


#238

How much upheaval will be involved when it comes to the time of re-writing patches for 1.1? I’d imagine not much but I am curious. Have 4 modules ready and working on a couple more before uploading to patch storage. Orac is crazy fun!


#239

as its not finalised I can’t say definitively yet…
so far, not too much at all… and hopefully it will stay that way.

on the other hand, I think the next release is a good time to ‘get things right’ , so that there do not need to be changes later when they are even more modules.

(bare in mind, changes that have to be made, I have to do for over 50 modules :wink: )


#240

hey @thetechnobear

quick midi routing question - say I had a module that generated 4 separate channels of midi? could I easily route those to different chains? or would I need something like a 1 x 4 chains x 1 module? (and how are those chain modules to build?)


#241

modules don’t output midi, they output a single steam of notes (aux,fs,exp)
so currently you have to create a separate router for this, and then define a way for modules to communicate the extra info (e.g. using a s/r pair)

you can use another router module as an example.

future orac 1.1 notes:

  • router modules are changing quite significantly, and are much easier to understand (better abstraction)
  • I’m considering moving away from (or supplementing) the notes channel, to a more generic control channel. id really like it so that MPE modules can be supported.

#242

yeah cool thank you - had a poke around and it all makes sense.

I’m guessing from the language you use about 1.1 it’s not about to change overnight?