I’ve started this topic in order to keep track of all the work done regarding new ORAC patches with multicore support via pd~ or existing patches modified to work with multicore.
Multicore is key for taking advantage of the new organelle m & s processor, so I’m really excited to take part of this project.
So far I’m aware of only 3 amazing patches working with multicore:
Also @T8R said in another post he is working on a multicore porting of brds (braids), which is awesome!
I would have loved to work personally on ‘macrosynth’ (polyphonic plaits by @WyrdAl) but looks like it will be out of my reach as it looks like the polyphonic voicing is handled by the external module…
But I’ve figured maybe I could work on a multicore ‘Fusion’ (6 voice plaits drum module by @electrafa with @WyrdAl plaits porting) since it’s a module I’m using very often and it’s relatively CPU hungry.
To anyone still active in this community and willing to give any sort of help or suggestion regarding new multicore patches or porting existing patches to work with multicore, please share your ideas and suggestions here!
Fusion is a great idea for a patch to port! I’ve actually finished my Brds port so I’ll get that uploaded today!
Luckily, I have found a method for conversion that is fairly repeatable (however not completely fool proof). The least painful way to port patches is to rename the existing module.pd file to something like pd~-fusion.pd (the name isn’t really important but that’s what I’ve been doing) and then using a new module.pd (which I will provide a template for) to launch the entire old module file/new pd~ file as the sub process rather trying to relegate certain aspects to other CPUS like how Koto does which gets a lot more complicated (maybe has better results but I honestly don’t know but your approach will also differ depending on the patch if you go this way)
It is kind of annoying because you will have to repass all the knob parameters into the new pd~ subprocess so if you have a lot of parameters, its quite the tedious process. If you are interested, I’ll see if I can do a video tutorial of porting something easy like basicpoly to multicore.
There is some work that also has to be done in the old module/new pd~ file and the first thing is getting rid of any audio inlets and outlets and changing them to adc~ for inlets and dac~ for outlets. You’ll also have to get rid of all the $1’s at the end of parameters being received and loadbangs. The BIGGEST thing is in the new pd~ file, make sure you have a loadbang banging a message box with ‘; pd dsp 1’. By default, the new PD~ subprocess has dsp disabled so it wont work unless you have the dsp turn on with this message. I also found there’s some parameters that don’t always initialize correctly so in some cases, you may want to pass the values again through a message box off the loadbang. One other thing to note is to change any sending of screenline 5 to stdout. Stdout sends all messages to the left most outlet but the handling of that is taken care of in the module.pd
The last thing I can think of is when you are done with your patch, make sure to add a -nogui flag into the open module message. I noticed that if you don’t have this flag, it will only work if you have a VNC client or the X server running
The above mentioned way is how Oracloops, Samplement, and the new Brds port function and even though @electrafa is not active in the community anymore, he is the one I was able to steal this technique from and have learned many things from his patches
I could also be missing a couple steps but thats the gist of it. Another thing that I found is not every patch benefits from multi core. I recently tried converting a patch I made Delaverb but saw no benefits but I’m sure macrosynth and fusion would see cpu usage improve
I’m a bit familiar with all the pd~ porting procedure by looking at your patch Oracloops and also Koto, the only thing I’m still trying to wrap my head around is messages, parameters and midi in/out, still not 100% clear to me.
I really like the idea of using a template to run the entire patch as subprocess, this would in theory spread the load to multiple cores as you add more and more patches.
If it works then I think it should become the norm for orac patches going further as it can make a huge difference without getting overly complicated.
While other patches like complex poly synths might still benefit more from an approach where each voice has it’s own dedicated subprocess.
Hopefully it can be utilized easily but I guess we’ll see if I can explain my process well enough that it can be of use
So the general idea behind the use of messages is as follows. When a new sub process gets initialized, it forgets how to talk to the Orac parameters, knobs, pages, notes, expression, aux, and MIDI control so we have to convert these from the objects that Orac normally uses to interface with these and pass them to the new PD~ process via messages because that is really the only way to talk to the process.
Also with the notesIn and ctrlIn processes that are typical in a normal Orac patch they contain multiple values. notesIn contain not only the note value but also a velocity setting and ctrlIn contains the value, CC#, and what channel its being received on. Each of those aspects has to be unpacked and passed into the PD~ process separately and recombined later in the subprocess.
I’ve also uploaded my Brds-Pd patch and I’ve done my best to markup the changes I’ve made. Brds-PD | Patchstorage If there’s still confusion surrounding the process, I’ll see about doing a video walkthrough of converting a basic patch but let me know if you think that would help at all! Here is a template you can use as a starting point.
Thanks a lot and great job with the template!
It makes much more sense now!
I’m gonna try to familiarize with this process porting a few patches then I’ll be more than happy to help you create some in depth content (tutorial ecc.) for the community!
Thats awesome! I can’t wait to get this into my rack. I’m glad I could be of help! It’s very exciting to finally see the multi core aspect being used to tap into all the unused power of the Organelle
This is a beautiful thing. I never thought I would see the day where I could have a completely full rack with all my favorite plugins, no under runs, AND have CPU to spare without even having to over clock my Organelle All hail the power of multi core
AMAZING! I’ve been wanting to develop something like this! I’ve been in dire need of a good compressor and this seems exactly like what I was looking for! And multi core no less!
I’ve been using a compressor that I developed but I haven’t been able to get it sound right. Maybe I’ll try to go in and tweak it but I don’t know much about compressor design. It seems like it’s doing something weird phase wise
This sounds pretty good IMHO, I own an hardware ssl style bus compressor and this holds very well against it, while it’s missing the auto-release and the ratio/knee curves of the hardware it’s super flexible and the sidechain input it’s what I desperately needed for Orac!
I would have to agree! I’m very impressed with the sound of it! I will definitely take a look at the guts of this patch! Hopefully I can glean a few things. Even without the inclusion of the auto release, this to my knowledge is still the most capable compressor for Orac to date
Marvelous! I need to get on and convert some more modules but I feel like there’s been a lot of ground covered. Maybe I can see about doing a multi core Capture module
I’m not really sure but I want to see if I can take out SuperCompress and fit your new buss compressor I don’t think I’ve heard of Spiral Delay so ill check that out but plateverb could definitely use a different core. I’ll see about converting some regular patches to Orac and then giving them the treatment
All hail the power of multi core
I’ve been in dire need of a good compressor and this seems exactly like what I was looking for! And multi core no less!
but well worth the effort!