Aleph, looking in from the outside

It’s been very exciting watching all the new work on the Aleph. As someone who has never touched an Aleph, I find myself curious about the motivations behind its design. How does it differ from something like Critter & Guitarri’s Organelle, or Qu-Bit’s Nebulae in intention/purpose? Why the bespoke system rather than something like Linux/Pd?

I can guess at some obvious answers, but I’m hoping by asking I can get some deeper insight into what makes the Aleph unique.

1 Like
  • timing. Realtime Linux is cool stuff, and I mean really cool - all my machines run the linux RT branch and I’m a long time fan & user of linux RT but I have yet to see a desktop system that can do single-sample latency, (other than soundcard onboard DSP mixer of course). Plus there is the whole hell of nvidia graphics cards screwing up timings, fettling interrupts etc. That aspect of linux sucks pretty bad!
  • simplicity (of implementation). You don’t have to be a kernel hacker to understand the whole stack running on aleph. (although now I know a little bare-metal C I’m seriously thinking about starting eudyptula challenge)
  • learning. This system bootstrapped me from very green embedded C programmer when I bought it (read K&R cover to cover ten years ago) to slightly less green embedded C programmer. C hacking is probably more of a life-skill than pure-data-ninjery. (not that you can’t just program an organelle in C I guess…)
  • There’s more than one way to do it. embedded linux on ARM is flavour-du-jour at the moment, but even the comparatively tiny amount of processing power available on aleph is enormous for performance-centric musical instrument control. Why aleph? Why not!

My only criticism of the platform is flash time of avr32 and tooling (lack of simulators, debuggers). The awesome thing is that because the stack is simple enough to hack on, improving our dev tools is within the grasp of mere mortals (even in spare time alongside full-time work).


since you’re asking about “design motivation” and not just user experience, i’ll add some (rather prosaic) points:

  • we started working on aleph design several years ago, and seriously on the hardware spec in like 2012. it was not so clear that ARM would so rapidly come to dominate the landscape. i know it seems strange but that’s how quickly things have changed.

  • as rick says, brian and I aren’t linux kernel hackers and (in my case) have no particular desire to go there. we simply wanted a bare metal environment with a good open-source toolchain.

  • we did look at the TI ARM parts used in the beaglebone. but it was nuts trying to figure out a way forward using them in a bare-metal fashion with a free open-source toolchain.

between one thing and another, we went with AVR32 because it was straightforward, tried and true, and i had some familiarity with the platform already. doing otherwise would have added years to early development.

i still stand by the blackfin. it’s not the fastest DSP out there but it is beautifully engineered and has a mature and active open-source community behind it. you could absolutely run linux on the blackfin in the aleph if you were so inclined - it just wouldn’t be that useful for realtime audio.

as for utility - i’ll say that i really like the looks and fnuctionality of the Organelle; i want one, and i’m not someone who often suffers from gear-lust. it seems very useful. but it also occupies an odd space. i play music and develop software. i use PD on linux, but to me the most useful thing about PD is that it provides a nice C/C++ API for making your own DSP objects. i find visual programming itself to be a total waste of time.

so, with the organelle, my big question would be how hard it would be to compile my own objects and/or applications. and it looks to me like it would not be hard - the box is running a standard Arch system, comes with gcc and everything, so you don’t need to cross-compile new PD objects, just compile them on the box. hardware UI glue is via a separate app and serial OSC.

getting SuperCollider going would be my next goal if i had one of these. might be trickier.

so anyways, i think Organelle is a great thing if you are looking for a linux-based, portable performance computer.

but, the Aleph is something else. i don’t know if we did a good job setting the marketing tone, because it was written up as a PC replacement. it’s not that, doesn’t function much like a PC. (the organelle does.) the Aleph is a replacement for custom DSP hardware:

  • it has single-sample latency. that means that you can use its DSP in totally different ways. for example, you can build an IIR filter where the signal is passed through an analog component (like a saturation element) during the feedback loop. this makes it a fantastic development tool for prototyping mixed analog/digital circuits (i’ve been using it this way, on and off, for the last year or so.)

  • it has some more I/O hardware, obviously, for dealing with lots of audio channels and for interfacing with 10v control voltage. a lot of people don’t need these functions, but when you need them, you need them.

  • in the same vein, it has an i2c interface. this means you can talk to all kinds of embedded stuff that doesn’t even have UART - for example, you could hack the aleph to function like a buchla 200e preset manager, or listen for preset save/load commands from same.

  • clearly, it has less processing power. chalk this up to historical happenstance. if ARM development had been where it is now, three or four or five years ago, we would probably be running an ARM instead of an AVR32.

iin short, the aleph was developed with a much less clear idea of what specific functions it would be performing, but with an eye towards providing certain capabilities that you just can’t get with a NUC plus audio interface. (the organelle is basically that, in a nicer box.)


Thank you! Exactly what I was hoping to learn. Really appreciate your thorough answer.

From a user perspective I’d add that in comparison to the shnth, my main spark to get aleph, it is unparalleled in self-contained flexibility.

You have direct access to internal rerouting thru multiple access points (I/O pages, Op creation, “preset” system). This is repatching/bending is possible with a shnth but I was never good at it. If I wanted to change the app or functionality it seemed easier to just connect it to a pc rather than design interlocking shlisp bowls to cycle thru.

1 Like