on patchstorage we can ‘tag’ , organelle-m specific patches.
ones that also work on organelle-1 will not generally need a tag, since all work on organelle-m.
that said, I will be adding tags and adding ‘protection’ to a few organelle-1 specific utilities, Ive made for the organelle-1. (these are things that change the OS, not general pd patches)
also its possible for patches (etc) to detect if its an organelle-m or organelle-1, and so alter its behaviour where necessary.
let’s talk a little about what would make a patch incompatible…
(this is a personal perspective and just how I think it will play out )
TLDR; I think most patches will happily still run on an organelle-1, and many patches (not all) can be made to utilise the improved hardware on the organelle-m in compatible way.
from the patch perspective the organelle-m and organelle-1 are the same, because PD and Linux hide the hardware differences (memory, cpu, additional midi, speaker, mic).
b) many users and patch developers will still have an organelle-1
so there is motivation to make things work on the organelle-1 where possible, so you have the widest user base/community.
I’d also suspect many that get an organelle-m will keep their organelle-1 as its really run having two organelles e.g. perhaps use OTC on organelle-1 to generate visuals for your organelle-m
c) increase in memory (doubles to 1gb)
this is probably the first area we will see incompatiblities arise, mainly because the extra memory means we can allocate larger buffers for sample memory etc.
however, this can be done sympathetically, such that the patch can just use ‘whats available’ i.e. you just get less sample time on an organelle-1, but it still works
d) increase in CPU (single core 1.0 ghz to quad core 1.2ghz)
initially this seems like a huge increase, and it is IF patches are developed to use it - but it’s not that simple…
Ive detailed this before on other threads including supercharged organelle thread , but to recap…
the main gain here is the quad core, but basically PD is single threaded, you need to start using poly~ to make it utilise more cores, and whilst thats not hard - it has limitations, and is a little more complex - so I suspect it’ll take a short while for this to leveraged by most/lots of patches
until patches start using this, the main benefits for simple patch performance are:
the 20% cpu gain, some minor improvements due to internal threading, improvement due to OS and mother host being able to run on a separate core to PD, so they do not compete.
again… here patch developers have the option to programmatically ensure that the patch works on the organelle-1, but is improved on the organelle-m
(theres a number of simple ways to achieve this)
looking at Orac is, perhaps, a good example of this in practice.
the current Orac runs smoother on quad cores, because its got a bit more headroom due to processor bump, and the fact that the OS, and mother (and MEC) are running on different cores, and also my ‘kontrol’ infrastructure is already multi threaded (so works on multiple cores)
the main DSP is done on a single core, but the extra processing/memory can be used already, since you can use more modules, or more complex modules.
so we have 100% compatibility, but organelle-m is just a bit better.
moving forwards of course I want to leverage those extra cores, and Ive been playing in development with (optionally) having separate chains running on different cores.
this would yield a huge increase in whats possible on an organelle-m - whilst retaining 100% compatibility with the organelle-1.
what’s cool is that retaining this compatibility is not ‘extra work’ , its just a matter of design… a modular design almost by definition is scaleable.
overall, I’m excited…
we can get the best of both worlds…
- we now have a much more powerful organelle, that more portable, more compatible with other hardware etc
- our organelle-1s are far from obsolete, future patches can still be run on it, and many will attest to, having 2 organelles is really fun - they are small enough to not take up to much space, and you get the opportunity to run 2 of your favourite patches. e.g. use one as a synth, other as an fx.
tip: if you want to link together via midi, you can either use a usb midi host to host adapter, or get a usb->midi din cable (cheap ) then use the organelle-m new midi din (trs)
tip2: you can clock sync via ableton link
I think there’s going to be some interesting opportunities here for combining organelles