ORAC multicore patches

I’m running a very customized Orac, but one thing I did was to put Capture inside the last master module (in your case postmodule.pd) in my custom router patch, taking the outputs from there.

This way it is still controlled by the master module aux button but you can load a different patch on top (usually master fxs do not require a free aux button), if I remember correctly it required very little modification to make it work displaying the recording time when enabled etc. (I could check that in case), and I’ve also enabled 32bit mode on the recorded material.

Thats a great idea! I’m just running my router module Parallel3+ but adjusting it via postmodule.pd is something I havent thought of before. Now I’m curious though and want to take a look at your router patch haha

My router patch it’s still very much of a work in progress, but I’ve made it to better fit with my workflow and that’s why I love Orac! It’s so flexible you can shape it to fit your style!

1 Like

That’s understandable, I just like looking at as many Orac patches I can get my hands on :slight_smile: Also I just was playing around with Macrosynth and I must say you’ve done a really good job! It runs like a dream and I love having it be polyphonic with all the modulation built into the patch! There was one issue that I ran into with it however and that issue is by default it plays a very flat B right now but I was able to get it to C by transposing it up 1 step and 41 cents on the fine tuner. Another painful thing is this tuning has to be redone every time you change the model :confused: I’ll see if I can take a crack at it and map out what the tuning changes need to be for every model

I think the tuning issue was already present in macrosynth, maybe with time we can figure it out!

However having to finetune it’s not a big deal to me for now, It’s pretty common with analog instruments too…

On a side note be sure to check if you’re running the last revision of macrosynth-pd on patchstorage, there was a bug with the LFO modulation introduced by a typo during the porting procedure that I’ve fixed recently. :slightly_smiling_face:

1 Like

I had 3 chains of brds-pd going without a glitch on my Organelle M! Thank you so much for this. It’s very exciting to think about what’s possible now. My M isn’t modded or overclocked and I usually can’t even do 2 chains of brds. Amazing work :pray:t3:

2 Likes

Thanks @JoseQuervo :pray:
I’ts amazing how much extra power we can unleash with this method!

By the way I’ve just pushed Clds-PD on patchstorage :slightly_smiling_face:

4 Likes

Thank you! You guys are very appreciated for what you are doing. I’m checking patchstorage every day now. There wasn’t too much activity happening with Orac for a while so it almost feels like you guys are reviving it with new life. I’m loving it a lot so thank you many times!

3 Likes

Thanks everybody for the work here, great to see so much happening with ORAC. I’ve been thinking there could be a way to simplify/automate the process of porting modules to use pd~, I took a shot of building on the work from T8R and Audivit.

Using pd~ is actually a bit slower on the organelle OG and it adds some latency, so I don’t want to add it to the modules I’m releasing but I think it is very useful to people on multicore platforms, so I’d like people to be able to use it without changing the original modules (so any changes/fixes are easy to port between them).

I set it up so the pd~ loads a generic wrapper that instantiates the original module without modifying it.
I also tried to automate the forwarding of the messages with a script that can generate a pd file based on the module.json to forward the messages.

I’ve tried it with a couple modules and they seems to work (thanks Audivit for the testing).

monocle-multicore.zip (187.1 KB)
plateverb-multicore.zip (11.3 KB)

You can grab the wrapper code from the modules above, or get it here:

If you want to try porting using this method, the basic process is:

  • Copy the original module into the /module subfolder.
  • Replace module.json in the main folder with the one from the original module
  • Run ‘python wrapper.py’, and replace params.pd with the newly generated params.new.pd (I think the python on the organelle will work)

It currently has some limitations (doesn’t support graphics or note out), but I think they could be supported with a bit of work.

2 Likes

Amazing work! Many thanks! Ill still probably go about it like how I have been for modules that use noteout but this works like magic!

Hi there, maybe it’s a stupid question but being not able to make these amazing patches on my organelle M working…wondering if there’s something I missed regarding basic setup in order to use the multicore? is there a sort of intructions thread somewhere ?
thanks guys

For the ones me and and Audivit have created you should just be able to plop them in and use them as you would any other orac user modules. WyrdAl’s wrapper takes a couple extra steps. Do they not boot up at all or do you not see any cpu advantages?

I’ve been only trying brds-PD and koto
putted in a slot as usual but I’ve got no sound

Thats odd. Can you give me as many details about your setup as possible? What router are you using? They should function just the same as normal modules

well not such a particular setup
started from scratch putting brds-PD using paralle3 as router and nothing happened, also tried changing the router using parallel and serial again no results, then to check if something was wrong I used brds mono and it works well as usual…

Firmware?
I’m running version 4.1

have you loaded the patches on sdcard/media/orac/usermodules ?

ok ok ok now works like a charme!!!
I didn’t upload the module in the usermodules folder but in patches/orac/modules…that was the issue
I tried three brds-PD driven by three arper at once and the CPU is still at 32%!!!
while earlier only one brds was using 56%
it’s amazing!
thanks guys for the great job you did!
gonna try all the multicore patches you’ve done

1 Like

Perfect!

Remember the best way to watch cpu load is by running “htop” from the terminal via ssh or vnc.
The other readings included in the organelle menu or orac patches aren’t correct for multicore.

However by testing I’ve noticed that it’s much less susceptible to xruns using multicore patches, before xruns appeared from 85% load on a single core, now a single core can reach up to 90% or even 95% without xruns even while all the other cores are running over 70%! :smiley:

On my overclocked Organelle S I’m never getting xruns regardless of load, but the UI starts being sluggish when all the cores are slammed hard!

that’s great!
ye until now I never used the terminal to check the CPU maybe it’s time to start
thanks again for your support