Hi,
I’m waiting for my Organelle M to arrive. Meanwhile, I started a project on Pure Data with the hope of making it run on the Organelle M.
It’s basically a rework of the famous MLR monome app.
Grid control (+ Arc maybe), and should be able to load 56 stereo audio loops at the same time. Maximum time for a loop would be 10 seconds, so the total time of stereo material to be loaded in arrays would be 560 seconds.
Is it realistic in terms of memory and CPU ?
that’s 340mb … M has 1gb, which obviously needs to cover the OS, apps, drivers running and of course the rest of your patch etc. - but seems ok
(bare in mind, you only need to load the ‘loop’ if you are managing it, ie. you can stream if its just playback)
cpu, hard to say - entirely depends on functionality of your patch, and also how intensive your driver is going to be for the grid.
(if cpu is an issue, then you can make it multi-threaded , and so make use of all 4 cores)
generally, id always advise… give it a go… (or LMNC - dont be scared to try it)
prototype the bits you’re not sure about first, so you can refine/optimise these before putting too much work in the higher level stuff … at least thats way i work(*).
make sure you report back, always good to hear what everyones up too…
and esp. as the organelle-m is new, little has been reported on where the limits are, beyond technical specs.
(*) perhaps thats because i enjoy the tech challenges the most 
Ive been very pleased with the performance of the Organelle-M,
Im busy working on an Organelle-M setup, which uses MEC/Orac - that has an Eigenharp Alpha controlling synths in Orac and over CV.
The Alpha produces a ridiculous amount of data over USB, sampling is at 2000 sample (10bit) per second (!), I did need to optimise some of my threading and other code - but its working fine now.
so I think performance of both CPU and USB is excellent for this type of device, so I think if you have the will, its amazing what you can achieve on it.
Thanks for the encouraging answer !
The patch will need to have instantaneous access to the 56 audiofiles, as the main goal is to mash up records, accessing different points within the files. So I guess I have to pre-load all of them ?
At least I suppose this is how all MLR versions work.
Depends.
If you’re able to load a file into memory without disrupting playback, it seems like conceptually, you only need the four files that are currently playing, and maybe another four buffers “on deck” to transition into. Once you’ve done so, the first four become your next space to load into. Swap back and forth as needed.
Not sure that’s even needed, though.
How do you envision changing loops? And how often do you expect to? (Will it happen mid-song?)
I guess theoretically, if four of your buttons (either top row or on the Organelle) represent the four playheads, you could hold one of those to turn the entire grid into a loop selector for that slot. At that point, you could have more than 200 sound files at your fingertips. (56 or 64 for each slot. It’d be a beast to keep track of, though)
Thanks for the answer !
In fact, each song is split into 14 loops, so 2 pages of 7.
The app is run on a 256, split in two halves each organized like below :
-1 tow row (stop button, 2 patterns, song files scrolling down, song files scrolling up, song loading, and 2 page buttons)
-7 mlr rows (loaded with the 14 loops, across 2 pages).
So to say, I need real instant access on 28 loops.
And I guess I need to double this to 56 arrays, because I want to preload the next song in a deck, being able to cut and replace the currently playing song. I don’t aim to DJ in a classical way at all with typical transitions where only one song remains playing while I’ve got the time to load the next one on the other deck.
Actually, I’ve had this DJMLR app already tailor-made running in Max MSP for years already, but I don’t try to replicate the patch as it’s also a way for me to learn PD.