ok, so pure data is what I would call the ‘patchers interface’ into organelle…
but given your talking about C++/open source, I’m guessing your more a developer, so perhaps want the ‘less simplified view’
to understand the software layer, we first need to talk about hardware layers
pots, encoders ,keyboard switches and lcd are all connected to an MCU (STM32F0? , need to check that).
this MCU is then connected to a SOC (solid run , see other threads) via a serial link.
so the MCU encodes/decodes serial messages to communicate with the hardware and the SOC.
this software is open source, Organelle_Controller, but you would need to open the organelle to re-program it… this is no issues, since its very generic, so is not needed.
the SOC, has the Arm CPU, codec, usb etc… and runs an appropriate arch linux build for the SOC.
also on start up its runs the ‘mother host’ (aka Organelle_UI) written in C++,
its listens for OSC messages about the LCD, and coverts these, and sends then via serial line to the MCU. it also listens on the serial lines for msgs re pots/keys etc, and broadcasts these via OSC.
mother hosts, also provides the ‘user menu’ the users sees, and so also launches pure data when the user selects a patch.
on the pure data side, as Patrick said, there is a mother.pd patch loaded alongside the user patch which converts to/from OSC messages to pure data ‘send/recieve’
(for audio , the SOC provides a standard audio interface which is interfaced directly via alsa)
phews… so back to the original question.
yes, all the software above is open source, and available on the C&G GitHub repo.
which is great, because it means Ive been able to contribute to development of the ‘mother host’
as I mentioned, you could reprogram the MCU, but really there is nothing to be gained there, and other users would not be able to do it.
you could entirely replace the ‘mother host’ with your own dedicated process, written in C++, or whatever. which would talk to the MCU (and so hardware) via the serial line.
the mother host, can launch arbitrary scripts, which could of course include applications written in C++, so again no pure data involved.
has anyone done it, not to my knowledge… but I think that’s as much to do with ‘target audience’ as anything else.
Personally, I’ve got a lot of plans/projects , one does include native synths/fx native that don’t use pure data (so I can avoid the PD overhead) … but its one of many projects Ive got underway, so might be a little while yet before it sees the light of day.
I think organelle is a great platform… I think it excels, when things are written specifically for it… which can be optimised for its hardware. (rather than ports of things designed for PCs - which will tend to be a compromise)
some might read the above and think, all seems simple enough, they could implement this on a rPI, and they would be right , theoretically, if they have the skill set .
but are also missing some key elements
- its quite a bit of work, to actually create the above, and make it work seamlessly together
- a common form factor (# encoders, lcd) etc, whilst provides limits, it also provides a target platform, so patchers can target this… i.e. we can share patches
without this commonality, everyone has to write their own ‘instrument’, which is exactly what you see on the rPI… a few hackers build great things, but not something a community can be built around.
sorry, that went probably a bit off-topic.
I’m an enthusiastic developer in this area, I also build things with Axoloti, Bela and rPI (each has its pros/cons)
so was really intrigued with Organelle, and even though I could build a similar system (on any of the aforementioned platforms) - I’m ever more certain, Organelle is ‘more than a sum of its parts’… which I guess is why when I describe its part, I feel the need to express how great the ‘sum’ is
you could build supercollider for it… or any of the others that run on the linux
(look for something that runs on a PI, to guage if there is enough processing power etc)
not sure of the answer for that, C&G would need to say.
my guess would be either due to physical space, or perhaps due to the number of GPIO on the MCU.
I guess things will be muxed, but still there’s a limit of gpio on the mcu, and also more mux = more circuitry/complexity … id need to check the organelle_controller code to see how its arranged.