Electro-Smith Daisy Microcontroller Platform

That seems more feasible


first i should say that it looks like a cool thing and i am tempted to back for the pedal housing.

it is a cortex m7 with arduino-compatible bootloader (so v similar to teensy, but less juice than 3.6), plus a nice codec and RAM and a good amount of flash memory. and these pretty good looking housing / hardware interfaces. super neat, super convenient alternative to rolling your own version.

i’m a little disappointed in the vague copy about max and pd support.

max includes gen~ which generates clean and portable C++ code that runs most anywhere. it’s awesome but “running max” requires windows or macOS, full stop.

puredata is open source so there have been several transpiler projects over the years. the last contender i’m aware of is heavy, a python environment which emulates a decent subset of vanilla PD objects (mostly audio), analyzes patches, and uses templates to generate equivalent C++ code (maybe not the most efficient in the world.) pretty awesome (though no longer maintained and the company is kaput.) but “running PD” (or using libpd) requires a POSIX environment, full stop.

unless electro-smith has done an amazing amount of new tooling to emulate bigger subsets of those environemnts, their support for them is the same as other microcontrollers. (and if they had done that, i suspect they would be making a lot more noise about it.) bela in particular has done some good-looking tooling for the puredata case (it runs on xenomai, so can use heavy-generated code or use libpd directly), and gen~ code can run on basically anything with a C++ compiler and a floating point unit.

all the things i mentioned are awesome. but i hope that electro-smith puts a little more detail and transparency into their copy, because as is, they will have disappointed backers.


Bela is a Linux-based platform, with everything that enables (as @zebra has also outlined). Daisy is lower level - a microcontroller, not a computer; fewer ADC channels, and technically noticeably lower processor power (although Daisy doesn’t have to run an OS). A Teensy with an audio board or DAC is a good comparison, technology wise. A lot of what is promised is at the tools/software level, eg, code to wrap compiled Faust code is what they mean by “running Faust code”, or boilerplate to wrap compiled gen~ code is their Max integration.

1 Like

Wanted to answer a few questions here:
Regarding a screen on the evaluation boards, we are still considering this option before finalizing those prototypes but haven’t nailed anything down yet.

Just wanted to clarify, we are supporting Max/MSP through the Gen~ object, and Pure Data through Heavy export. On the Kickstarter and in the video linked above we state that code can be exported from Max using the Gen~ object, and that code can be exported from Pure Data.

I’d be happy to answer any other questions!


So…can i run gen~ code on a teensy microcontroller, and if so how?

well, it’s a bit off-topic but an excellent candidate for the new Questions category so maybe we should move your Q to a new thread and dig into it further there

but on the other hand, maybe a quick answer here is relevant:

  • up front, you need some moderate experience with c++ programming.
  • send the exportcode message to a gen~ object. this produces a .cpp file, a .h file, an a gen_dsp folder which contains some dependency headers.
  • the generated header and source files define a DSP State struct and some functions that operate on it. in particular there is a perform function that accepts a State and some arrays of sample I/O buffers.
  • the teensy audio library has a base class called AudioStream which embodies the interface to the teensy audio HAL. this class includes a virtual update function which operates on a block of samples.
  • you subclass AudioStream, use the perform function defined in gen_exported.cpp within your AudioStreamSubclass::update() function, and pull in the needed dependency headers that the gen export tool has “conveniently” consolidated for you.
  • then you decide WTF you wanna do to connect your hardware with your patch.

this process is a bit finicky and tedious, with some juggling of toolchains (maybe you use arduino, maybe not, &c). so when folks like the Bela or electro-smith developers put work into making that tooling nicer, we should definitely give them due credit. AFAIK no one has made a nice tool to just seamlessly take gen~ output and produce, say, a sketch folder for teensy that you can run right away.

it’s not as simple as it might look, because at some point you do need to make decisions about how to connect your patch to the host environment, or it’s not very useful.


So, I just found this thread. Not sure how I missed it. I’ve been playing around with the early prototypes for a while now, and can probably give my thoughts on it, from the perspective of someone who is more “technical” and comfortable writing C code in a Linux dev environment. I think I can also answer questions about the open source library they will be open sourcing at some point under the MIT license. I also am in touch with the core Daisy devs, and can forward stuff to them as well.

I’ve been involved with this project since it started about 3 years ago. My role has mostly been as enthusiastic cheerleader, though I have contributed small bits of code. I think the Daisy has amazing potential. It is a very open and hackable platform. With an enthusiastic community like lines, I could easily see the Daisy growing into a very rich ecosystem for music creation.

This has personally been a really exciting project for me to be a part of, as it seems to satisfy a niche that is hard to find: a board that gives you just a bit more low-level control than an arduino/teensy, without needing to solder anything. This fits my profile quite well: I’m mostly a software-oriented in-the-box fella who loves to write homebrew music software in C (usually on Linux), but I’ve always wanted to port stuff to self-contained bare-metal systems.

The core Daisy API has been quite lovely to work with. It is a very tightly written and clean codebase, small enough for person to dive into and study. It provides the perfect level of abstraction for my needs: a main loop, a callback interface for audio, and some functions for retrieving knob values. It feels just like writing a command line C application, so things feel very familiar. I’ve had a really easy time transitioning to Daisy from my usual workflow. Usually, I’m able to port code from projects of mine with little/no modification.

Built on top of the core libdaisy is DaisySP, a growing collection of audio DSP algorithms written in C++ designed to run well on the Daisy. Several of these algorithms have been ported from the Soundpipe DSP library (a project of mine). There are a lot of goodies that they’ve ported over, including the lovely Costello reverb that you hear in the kickstarter demo.


I saw this come up and was also excited about the “can run Max patches thing”, and had to dig through the kickstarter to see they actually meant gen~, which is a bit misleading.

The hardware breakout things do look nice. I wonder if they are designed in a way that you could (somewhat easily) use them with other platforms as breakout boxes and such.

oops - I really shouldn’t interact with the world till caffeine

To add to @PaulBatchelor’s praise: I’ve had an engineering sample of the Daisy Patch (the Euro dev board) for about three weeks and have been writing C++ code directly to it using Visual GDB. This is extremely easy to program for (from a C/C++ standpoint), and we (Unfiltered Audio) are already planning on putting a module based on the Daisy into production.


Well I’ve officially backed the Kickstarter! I went with the daisy + pod. Very excited to get to work. I’ve been wanting to build some microcontroller based synths for a while now but just never really committed to learning everything I need to learn. Now that I’ve put some money down maybe that will change.

Pardon the noob question, but does anyone know how straightforward it would be to port the mutable instruments open source code to daisy’s DaisySP platform? Or would using the pre-existing pure data patches still be the way to go?

I don’t think it would be too difficult to do, but it would it still take some work. From what little I’ve seen of the MI codebases, they seem to have decoupled the DSP bits from the hardware-specific bits, so this should make portability easier.

It’s a far more likely outcome that ES will port individual DSP components to their DaisySP library, rather than try to have one-to-one module compatibility.

1 Like

FYI, this just got posted on their kickstarter:

We’ve gotten a lot of requests for adding displays to the Patch and Field platforms, which we think is a great idea!

The downside is that we might have to remove some features in order to squeeze them in :frowning:

Here are some mockups that we’ve been working on. Let us know what you think in the comments!

Instead of a 4x4 led display, an OLED display. Resolution + size is not mentioned, though 128x64 would be a good guess (like the norns).

They don’t seem to explicitly mention which features they’d have to let go of, but judging from the mock-ups, the quadraphonic audio would be one of the things that would have to go.

1 Like

Interesting! So would the individual DSP elements be things like Cloud’s granular vs it’s reverb, or is it lower level than that? Another thing I’d be interested in is the wavefolder from one of the Warps modes.

Depends. It’s dictated by how the code is structured. Also, it’s at the discretion of the author porting the code how much granularity (no pun intended) is desired.

Jumping in blind here, but a quick glance at the at the Clouds code shows that there seems to be a handful of self-contained components including the granulator, a looper, a WSOLA sampler, a phase vocoder, a correlator, a reverberator, and a pitch shifter. All bits that could potentially be mixed and matched in new an interesting ways. Some rain and sunshine to go with your clouds.

Those components do break down into lower levels. The Reverb, for instance, breaks down into delay line components, which are then used as delays and allpass filters in the reverb topology. These come with the reverb code one way or another. You could also port these as well. BUT, from a creative audio-programming standpoint, it’s probably not really worth breaking the reverb algorithm up.


The latest Kickstarter update from daisy:

1 Like

is the Vin going to +5 volt?

1 Like

I believe they said it could be USB powered, which would mean there should be 5v on there somewhere…


Got another backer update today. Electrosmith is based in California and there is the full shelter in place order there so fulfillment will be delayed. According to their update they’re shooting for mid-May shipping at this point. I guess we’ll see what happens.

That is a completely understandable turnaround time but I can’t say I’m not bummed. I was hoping to get to mess with my Daisy during quarantine times. But then again given the truly awful federal response here in the states, and just the nature of this disease we may be in quarantine long past mid-May I suppose…

Has libdaisy gotten a release yet? I’m experimenting with some of the DaisySP examples. This GitHub issues from several weeks ago implied that libdaisy should be out soon, but I can’t find the code right now if it’s out there.