Oh - I actually thought this was part of the router module, since I navigated to it via the router page… in any case I was hoping to avoid using up extra module slots, but I agree it’s not good idea to post something that modifies the underlying code.
Afa making this work for me personally, I’m trying things like, sending delayed 0 0 messages to the noteout object (triggered when the mute engages), but this doesn’t seem to work. Maybe what I’m trying to do isn’t possible, or at least by modifying things at this particular location in the code…
The [poly] object does what you want,
It tracks notes, so if you tell it to stop/clear (?) , it will automatically generate a bunch of note offs for any notes that are still active.
( it’ll also do note stealing if you want it to eg to limit polyphony)
If your synth/module supports it, another brute force method is to send ‘all notes off’ cc
Wow thanks! I actually got it working (I think anyway), but will definitely experiment with those methods as well. I’m really enjoying learning about this stuff and appreciate your feedback more than you know
Here it is for anyone who has a similar use case and wants to try it (could obviously be cleaned up a bit, I had all the extra number boxes troubleshooting one final problem):
One (hopefully last) hiccup here - when I go to save the chain out subpatch, it saves all of the chainout sub patches exactly the same, and I was hoping to have [ctlin 48] [ctlin 49] [ctlin 50] etc. Any easy way to solve this? Thanks again
edit: I moved it out of the sub-module as a workaround, it’s a bit messier, especially once I’ll have 5 or 6 chains, but in the end, this makes it part of the router module which is probably best anyway!
yeah, things like chainout are a ‘helper’ abstraction, that are used across multiple routers etc.
if you want specific functionality for your own router, you should copy (and rename) into your own router directory, and change your router to use it.
thats the thing , in Orac, routers are ‘just another’ module, which has a ‘side-effect’ to route messages around Orac. this approach, allows a huge amount of flexibility, but can be a bit tricky to ‘get your head around’
I copied and renamed the chainouts to have separate ones, put them in the module directory but getting “send to r-chout” failed for all chains’ midi, gain, and pan. Any tips? Sorry for all the questions!
edit: never mind sorry! I had deleted the “1”, “2”, “3” etc. in the chainout’s new object (between the spaces) in the object - definitely need these
I have the need to use one of the Orac slots as a simple Midi Keyboard module. Right now, MIDI gets sent without issue but I would like to be able to change octaves so that I can reach lower notes on the external synth I’m using. I guess what I am looking or is an empty module with octave selection. Any simple way to achieve this ? Thanks a lot !
If you look in the “modules for the orac” thread, I posted a MidioutOct module in Nov 2019 - it does have one issue with stuck notes if you happen to change octaves between a note on and a note off message, but it might work for your purposes. I never posted it on patch storage because of this issue.
If you need a solution, I did recently post a router module recently “nkMutePar6” which has a solution for stuck notes. I’m not certain but I bet it would be possible to take that solution and apply it to this module.
Help me out here: My Organelle 1 (OS 3.1) freezes immediately when using modules like Cassette and Samplement (and one or two others that I can’t exactly remember now). Even If I start a blank patch and only load Samplement for example, my organelle instantly freezes. I just reinstalled orac and all my other patches to a brand new USB stick but problem persists. I’m going to get a new SD card so I can upgrade to the latest OS, but wondering if anyone had any thoughts on this… I wonder if only M is able to deal with these apparently heavy modules.
Love ORAC so thank you Mark for all the incredible work. I have so much damn fun with it.
I really like the orac 2.0 but I wish there was a “zip to zop” converter for organelle patches to orac patches. I bought the organelle m (mainly because of the cinematic piano) and really wanted to put the cinematic piano into orac. But after some research, I´ve found out, that it´s not that easy …
the issue is not to do with zip vs zop… zop are just zip files (optionally with a deployment script) , these are applicable to add organelle patches, not just orac modules.
the ‘issue’ is standalone patches will not work as orac modules (with the exception of my ‘easter egg’ for orac )
the reason is simple, and one I’ve discussed many times - the standalone patches are simply not designed to be modular.
I’ve pretty clearly setup out, how a patch can be turned into a module - but I don’t have the bandwidth to do this for every organelle patch, so its up to others to do this, if they are interested.
its a bit like a korg volca fm cannot fit into a eurorack, it can’t since its not the correct size, doesn’t accept the power cable, or cv inputs/outputs.
of course, thats not to say korg, couldn’t make a volca fm module, and it might even share a lot of the circuitry, but its cannot be ‘automated’
I wonder why the UV meters in Orac 2.0 are not active. I’m using it in Organelle M with 4.0 firmware. In the video presentation of Orac by @thetechnobear I can clearly see them being active. Thank you for your help.
I recently did an Orac port of the very nice Koto Organelle patch.
As you can see in the comments on the patchstorage upload, some encountered performance issues as the cpu of their device couldn’t handle this heavy module in parallel with other modules.
That’s why I thought I could move the synthesis part of the Orac-Koto to a Pd subprocess in order to make use of the multiple cores present on some devices and therefore make it usable for more people.
This second version seemed to work nicely when I tested it, I also have to say that I run Orac on a rpi 4 and so never really could test the case of performance issues.
Nevertheless @alanca still encountered the same issues (crakling noise, more when playing a lot of notes or with other hungry modules) on his Organelle-M. When looking into the output of htop he got this:
You can see how the subprocess running Koto is split away from the Orac process onto another cpu and leaves them at around 50%
Does anybody has any idea why the issues could be present in this case? Could it be something with Pd and not the hardware? They still come up the most when playing polyphonically so it must be the cpu right?
ps: In this post they show that the original organelle can still play smoothly at much higher cpu % use I think
I’d not have thought 50% cpu on two cores was an issue…
I assume you used poly~ to do this?
I assume you are then redirecting the orac parameters from a proxy module into the poly~ version,
as it would not be thread safe to access kontrol messages from another poly~ instance.
if crackling is occurring when you get more voices, then Id assume that means you are doing more processing when you use more voices
… this is not the normal case, usually you allocated resources for max number of voices.
does the htop show this peak demand situation…
also running wifi and vnc when doing performance testing is probably not very indicative.
especially since as far as i can see, the pd gui looks to be running … as there is no -nogui option on command line. yet for some reason… its still be launched with -audiobuf 10 … which I thought is increased usually when the gui is active… so a bit confused why this is the case if this is running on an Organelle.
Hi Technobear! Like you said, since i don`t have an hdmi cable, i was doing performance testing running wifi and vnc on my organelle-m (thoght it could help a bit).
but just to be more specific about the issue, the cracking occurred even though i’ve played one note at a time, waiting for each note to completely fade before playing another.
I think that poly only lets you generate the voice numbers for a polyphonic midi input, or is there a poly~ Pd external that I am missing?
I used the pd~ object in order to create another pd process that runs the cpu-heavy synthesis patch.
Indeed I fetch the orac parameters via a little proxy sub-patch that reformats them and sends them into the inlets of the pd~ object which handles them in a non-blocking way I assume.
It’s true that when I look at my htop output through ssh, I don’t see much variation of cpu usage when I play polyphonically or not!
I start the pd~ object with the arguments -ninsig 0 -noutsig 2 -fifo 1 -nogui, these must be in the -extraflags argument of the subprocess that is present in both of our htop output.
Yet the mother.pd orac process is launched without a gui and with a lower audiobuf in my case, it’s indeed weird that it is different in your case @alanca, maybe pd goes into graphical mode because of the Vnc session? That would also be weird
nope not weird this is what the mother host does - it detects the presence of any X session, and if present it launched the patch with the gui enabled, and a larger audio buffer to compensate for the extra load the GUI will introduce
as i said, really you cannot do any kind of performance testing when wifi and X are present - its just not the same as when running it headless standalone.
hard to say whats going on without really looking at the patch in detail.
( e.g. I also cannot see all the parameters than are being passed to pd~ in htop)
I guess the first thing i would try is increasing the fifo see if more blocks reduces the issue, which would point to cpu.
as I said, doesn’t look like the average cpu usage is higher than can be handled, so if its cpu related it looks like its caused by the PD patch ‘peaking’ e.g. doing something periodically, or related to voice count.
also are you sure its cpu crackles, and its not digital distortion…
if you have voices with high dynamic range, and you play too many voices you will start clipping.
