Organelle software open source?

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 :open_mouth:
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 :slight_smile:
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… :wink:

1 Like

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 :wink:

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 :slight_smile:

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 :slight_smile:

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 :wink:


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?

I bought the PiSound too and it seems like a nice product. I’m still lusting for a Organelle though. Just have to save up my pennies…

There’s a USED one for Sale @ Control BTW

What is “Control”?

nope, Im not really a fan of Python, especially on low powered devices.

my first iteration is using my Push2 as a control surface using my own C++ code directly talking to it.
I might add a small Juce/C++ app, if I decide I want to have control via the 7" touchscreen Ive got connected to it, but its a lower priority at the moment.
(the only thing that might bump it, is it might be useful for testing some of the current dev work I’m doing)

yeah, thats kind of the direction I went, Ive DIY solutions (bela, pisound,axoloti) , but I wanted to add something for more immediate patching/music making … so added an Organelle (and then promptly started doing a whole lot of development for it :wink: )

Another reason I like the idea of PiSound is that I had this idea that I could make a small box with a number of controls like the Organelle but no built-in keyboard. I’d then use a small USB-MIDI keyboard plugged into the box to have a full 2-3 octaves and better keys. In fact, it might be nice if the box included a small speaker so you could play the unit with just the box and the MIDI keyboard. However, there is still a lot of appeal in the Organelle for presenting an all-in-one solution (minus the speaker).

Has anyone tried the quad core SOM in the Organelle?

yes, I’ve got the quad core, WiFi in one of my organelle

Thanks! I had missed that post. Do you have to break any seals to open the Organelle to plug in the quad core module?

no… though of course, if you break it , its your own problem. - its easy to do though, so unlikely.

one small issue, I found after the other post… was when its ‘cold’ , you have to plug in the power, then unplug it, then plug it in again… this is a known issue with the build we are using, if I ever manage to build the kernel, then I will be able to fix it.

also… bare in mind , just like a rPI, this is using passive cooling, so if you crank up all 4 cores its going to get warm,… so you need to be careful, and ensure you allow cpu scaling when hitting the processors hard for long periods, other wise you can damage the cores.
(cpu scaling is disabled by default, so I turn it on when im going to do things like compiling, which are high cpu loads for long periods of time)