There have been some questions about the processing power of the Organelle, how complex a patch may be, and single versus multi-core processing. I made some basic tests / benchmarks, and the following are some notes that shed a little light on these sorts of questions.
First, the best way to get a feel for the kinds of patches that are possible is to download some of the default patches and start poking around. Each patch comes in a folder, and contains main.pd, the main entry point.
All of these patches run below 60% CPU load on the Organelle, and use less than half of the available RAM.
The operating system (Linux) takes very little CPU, especially if the Organelle is not in edit mode and connected to a monitor. Typically it is around 1%.
The software communicating with the hardware (keys / knobs) and running the Organelle menu interface takes around 3%.
Pd itself has a little overhead. With DSP running and the mother patch loaded (needed communicate with Organelle hardware) it is around 6%. So the total overhead is around 10%.
Here are specific numbers for 2 patches:
Analog Style
I modified for 8 voice polyphony, each voice is 2 sawtooth waves fed through a resonant filter and amplitude envelope.
Total CPU load 55%
Sampler Style
24 sample record / playback voices, 1 for each key. Each with amplitude envelope, and then the whole thing fed through a reverb.
Total CPU load 40%
For comparison these 2 patches consumed 17% and 12% respectively on my 3.2 GHz iMac.
We also created a patch with 448 oscillators which loads the CPU to about 90%. At this point both the GUI and Organelle menu interface become sluggish. We generally try to keep our patches below 80% so we know they’ll run smoothly.
The RAM is also a limiting factor, but we haven’t experienced any issues with this. Most of the RAM used is by the operating system, which consumes around 30% of the 512MB. Pd itself doesn’t use much, unless you start to load lots of long samples into arrays. This is a test for another day…
Another question is about CPU cores and if having more of them would help performance. In general, more is always better, but it is not totally strait forward when running Pd. Pd runs as a single process, so the OS will put it on 1 core even if it is a very demanding.
We were able to test the patches on a dual core version of the same CPU that is in the Organelle, and did notice some improvements because the GUI and interface stuff runs as separate processes. So where the 448 oscillator patch became sluggish on the single core, it operated more smoothly on the dual core. However the ultimate processing barrier (the number of oscillators) was still the same. As this pic shows, the first CPU (Cpu0) is running Pd and it is nearly maxed out (97.4%), while the second CPU (Cpu1) is basically idle.
There was an object introduced in Pd so that one patch may embed another patch as a separate process, allowing the OS to put it on another CPU, but this is definitely a more advanced feature. You can read about it (and Pd in general) in this paper..
So far we’ve been happy with the power of the Organelle, and haven’t yet wished it had a lot more processing ability. After all, 300 reconfigurable oscillators in a small box with keys sounds pretty good to me! (although 10,000 would admittedly also be cool…)