I have disassembled mine once before yeah, wasn’t complicated, not sure about posting pictures of the inside workings of a product on a public forum though - C&G have pictures of the inside of the organelle, you should ask them for them.
if you want a non-graphical music language, you could easily install supercollider…
with a bit more effort, you could probably get sonicPI to work too.
as an embedded programmer, once you have an Organelle, it will take max 30 minutes to determine the hardware via linux logs, and opening it up … that’s what I did, but like @Wannop, I’m uncomfortable with the idea of publishing internal photos/details, that’s for C&G to decide to do or not.
honestly, if your trying to build a diy ‘clone’ (which I have no issue with), these details are not required. Organelle uses SOC interfaced to a custom PCB - its not something like generic rPI, and a DIY clone would be better off using off the shelf components… there are lots of open sourced designs for rPI which you could use as a jumping off point.
I’m not really interested in making a clone. I like everything packaged together like they’ve done with the Organelle. I just like to understand what’s inside the boxes I buy!
Most of this info is kicking around, but basically the hardware is:
hardware (keys, knobs, screen) --> STM32F051 MCU --> i.MX6 SOM (via serial) --> SGTL5000 Audio Codec (via I2S) --> audio jacks
USB / SD / HDMI wired to SOM
Thanks for your reply! You mention that you use the i.MX6 SOM. I assume you’re using the single core variant. Is it possible for a customer to upgrade the Organelle to one of the other variants with multiple cores?
Yes, it is a single core inside. I booted a dual core and it worked, never tried the quad. matters little for running Pd patches, unless the patch is designed specifically for multiple cores.
Thanks again. The Organelle seems like a very interesting device! Time to check the piggy bank to see if I have the funds to join the fun.
when I looked inside, it looked like the SOM was on a separate pcb mounted via a header.
are these headers compatible across single/dual/quad boards?
also do you know if the wifi option requires extra hardware support, or is it all on the same board?
do you know if id have to rebuild the kernel? or is the support already in the current build?
as you say, for PD its not needed, but my MEC process is separate and is also multi-threaded, so it could make use of the other cores, whilst leaving PD with its own
edit: hmm, a thought, I could get one of their SBC that use the microSOM, then rip it out to test with the organelle. if it doesn’t work, use in the SBC, if it does, keep in organelle, then order another microSOM to put back in the SBC…
This sounds like an interesting project. Let us know if you are successful in getting a quad-core module to work.
They all have same connector. The WiFi is built onto the SOM for WiFi version, and the driver is built into kernel that we use (I think). BUT I think their SOMs are now on a new rev from the ones in the Organelle. They are physically identical / drop in replacement, but may require new kernel.
Swapping out SOM for more cores + WiFi
I am not sure if I really need more cores for PD, but this sounds great.
yeah, I noticed they are on 1.5 vs 1.3 - in 1.5 they replaced the wifi chip, so the wifi is going to need a new u-boot/kernel
Id suspect the non-wifi wont… (I assume you have some 1.3 still in your store room, so not had to switch to the 1.5 yet)
looking on the linux side, I can see the dtb are there for the all 4 uSOM
Id say probably the dual core (imx6dl) is the going to be the most likely to succeed as a drop in replacement, as it will use exactly the same dtb -
also Im wondering if the quad core without heatsink mine get too hot, as I dont think there is room for the heatsink.
I guess if at some point I can get the kernel to rebuild, then the dual lite wifi might be the sweet spot (price too)
Ive found suppliers in Europe, but need to confirm with the exactly what they are offering, bizarrely the Hummingboards they sell, seem to be with the uSOM… and are often the same price/cheaper than the uSOM on its own. … so I need to confirm, there websites have not got it wrong, and actually the hummingboards just carrier board!
EDIT: ok, supplier has told me the hummingboard does come with the SOM.
PD by default only uses one core, even on a multicore system. But there are ways to uses more then one core, from what I read you can use pd~ to do that. But it is important to know that it by default only uses 1 core and you actively have to do something to make PD use more than 1.
@Jaffasplaffa that’s what I think owen meant by "unless the patch is designed specifically for multiple cores"
that said, pd~ creates a new process, so its a bit heavy for many uses (e.g. synth voices), but it has it uses in some problem domains.
also it should be noted, multi cores are routinely used anyway on a Linux system by system processes, and many PD externals will create threads and so use other cores (my latest external does this), also the mother host would also be pushed on to the second core.
so it all depends how much of this is going on, but its probably fair to say, when running most organelle patches … a second core would not be utilised that much…
however, as I said, I’m running another process which consumes 15-25% cpu ,so a second core along with other misc processes, would probably run at about 30-40%, not too shabby
if I use processor affinity, I might get even better performance.
anyway, had my questions answered by supplier, now just have to decide if I pay more, and take the risk of a quad core, or go for a the low risk (and lower price) strategy of dual core…
(I’m tempted to get the wifi, even though I don’t think it’ll work… as then when I can finally get a new kernel to bulld, I can add the wifi support)
… the question about heat dissipation is a bit concerning, ive read the solid run thermal notes, and reference guide, and cant find any recommendations on when the heat sink is required, or ‘normal operating temps’ … as far I can see, all uSOM come with a heat sink, so I think they assume you use it. not sure, if this is going to become a necessity with more cores, though perhaps if heat is an issue, I could underclock.the cpu.
hmmm, a question I guess of “you pay your money, and takes your choice”, quite tempted with the quad…
Isn’t the case of the Organelle metal? Won’t that block the wi-fi radio signals. I would think you’d need an antenna that goes outside of the metal case.
no, the top and long edges are aluminium , the base and sides are plastic.
fortunately, the microsom is mounted facing the (plastic) base plate.
I think it’ll be fine, though ideally, id put the wifi antenna to one side, but its unlikely long enough, so would have to be replaced/extended.
(wifi will probably be a mid term project though, given kernel building issues… though I have another idea for that )
I also realised yesterday:
if this works, then I’ll be able to reuse the organelle uSOM, as it can be placed in the carrier, so I potentially get an upgraded organelle, and a pocket Linux box
if it doesn’t work, I still have a working organelle with original uSOM, and a pocket Linux box.
anyway, I’ve just ordered something… I’ll report back, about what it is and initial testing results are, probably in a couple of weeks… this’ll give me time to do some more work on my software project for organelle
Yeah, I didnt even know that it only uses one core. If Organelle has more cores than one, I would definitely like to use more of them, 2 would be great, 4 would be uber awesome
Especially when I get to the point where I want to try running it at 48khz. Then the extra cores would come in real handy
I’d love to hear your thoughts on these different platforms. I have an axoloti but haven’t gelled super with it, don’t love the whole fixed point thing and the interface is also not as familiar to me like PD. Still prefer Max but I’d be happy with PD. So I am tempted to get one of these things… but running on a pi, I wonder about latency…
I read a post by @oweno that shows this little soc is quite powerful but I assume that was done using normal filters from PD, which as far as I know, not as nice as the latest implementations of digital filters using 0-delay methods. Are there high quality implementations of these in PD we could use with critter?
honestly, the answer to this is ‘it depends’, ‘what are you doing?’, ‘do you appreciate the limitations?’
none of these platforms are laptop replacements, they are all ‘low powered’ devices , and all (except the rPI) are dedicated music devices… each then has a different take on the problem space.
Axoloti - least powerful, but has a proper real time OS, so all the power is going to DSP, if you write your patches/objects correctly , it will perform to its ‘breaking point’ pretty seamlessly/reliably. it also has a specific ‘musical’ patching environment, which frankly i think is better than PD. BUT its not as common, so is obviously more specialised/less stuff to 'borrow’
yes, the int maths is a pain, and is partly only necessary due to a lack of an FPU … BUT its the same processor as used by MI in Clouds/Elements which does all its computations in float, so you can use floats, if you are willing to spend the cpu cycles!
Organelle - this is about a proper finished form factor, so users can share patches (as you’ll see on patchstorage), its a musical instrument first and foremost - its powerful enough to do great things, and PD is popular. but like all these platforms, you have to work within constraints .
the OS used (arch Linux) has been nicely trimmed back to not having lots of ‘stuff’ you don’t need running.
rPI3 - sure more powerful than the Organelle, but does not have a musical focus, efforts of devs/users are distributed.
you can make it a musical device, but you need to spend a lot of time doing this, adding hardware (an audio interface is a necessity!) , slimming down a distro, writing a PD (or equivalent) launcher. you will find countless 1 off projects doing this… but even for a developer, its a time consuming task…
is it cheaper? well… look at GR1, its a PI + knobs+ stm controller + display = $800, so no, once someone does all the legwork… its not cheap…
if you do it DIY, sure , expect to add about $100-150 to the PI price, for enclosure, audio interface… then another $100-150 for control (midi) + an lcd display… its surprising how it adds up.
Bela - is somewhere between Axoloti and Organelle, its using a real time OS, so like Axoloti can guarantee latency, but has 1ghz processor, and is Linux based, but the software support is no where near Organelle/Axoloti (though it will run libPD) , so leans towards the DIY/rPI.
but arguably for building a diy hardware instrument, which needs more grunt than Axoloti can offer… its a great offering. (but its not cheap)
as for software/filters… well Organelle is no more tied to PD than a rPI or Bela…
you can run the same software as these.
then bare in mind the DAC used is going to play a part, seems nice on the Organelle, the Bela is ok, and the rPI needs to be supplemented with something else, the built-in is dreadful, so depends what you replace it with… and what latency this introduces.
p.s. i don’t think usb soundcards on the rPI are a good idea, its USB is not fantastic anyway… so id be concerned about latency/jitter - however, Ive both a HiFi Berry and a Blokas board, the latter I think is pretty good, and has ‘made’ the PI for me… but it does steal a lot of gpio!
in short, Ive all the above, and I don’t think any is better or worst than the others …
for hardware hacking, fx or quick patching , I still love and use the Axoloti, everyday.
for playing/enjoying/experimenting, I use the Organelle daily.
Blokas have made my rPI more attractive but along with Bela, they are sitting there in the wings waiting for development… the irony being, that development is taking place on the Organelle, and then will be pushed to the rPI/Bela. I guess I kind of see the rPI/Bela as headless DSP boxes, so basically, I can do the musical dev on the Organelle, where I can easily ‘play’ with its form, play with the fx/sound generators, and then when happy with them, farm them out to a faceless black box
yeah, i chose to go with the piSound and i am getting 96khz crystal clear audio running insanely complex pd patches with Gem on Raspi. I chose two FW audio devices for my ES eurorack rigs as USB and audio just never made me feel secure
Have you done anything with the python Button or knobs on the Bloka/pisound yet?