This looks like a potentially interesting platform:
Awaiting details on the Eurocrack development platform. Looks promising!
I am also very excited for this. Wish the development eurorack module had some kind of screen but I guess it is out of the scope for such board. BTW I see that someone was bored while standing at the booth
I agree about the screen. Might be that it can connect to one easily but it didnt seem to be part of the prototype pedal board.
Seeing the words eurorack and STEM in the same context gave me a full body cringe.
Kickstarter is up: https://www.kickstarter.com/projects/electro-smith/daisy-an-embedded-platform-for-music
Does anyone more experienced with the Bela have an opinion on how this compares? It’s cheaper by a fair amount, so I’m wondering what the downsides are (other than having to connect audio in/out jacks.
Not sure how they compare tech spec wise, but being able to run max/pure data patches without a single board computer is what’s appealing to me.
Can it really run Max patches? I’m skeptical on that claim.
It can run gen~ objects, but not full Max patches I don’t think
That seems more feasible
yeah…
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.
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 agen~
object. this produces a.cpp
file, a.h
file, an agen_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 aperform
function that accepts aState
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 virtualupdate
function which operates on a block of samples. - you subclass
AudioStream
, use theperform
function defined ingen_exported.cpp
within yourAudioStreamSubclass::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?