I thought this was interesting…
“You will also find a Cross compilation SDK and a JUCE fork for straightforward porting of plugins to Elk.”
1 Like
Hi,
Ilias from Elk here!
The JUCE fork is quite minimal, and serves the purpose of removing the dependencies on graphics libraries, since plugins compiled for Elk need to be headless - i.e., have no GUI.
We are exploring avenues of removing the need for a fork entirely - meanwhile if you’re curious, here you can read the steps currently needed to build a JUCE plugin for Elk.
Do ask if there’s anything you’d like us to clarify!
Best,
Ilias B.
It says Raspberry Pi 3 compatible, but the Pi 4 seems a lot more powerful, so just curious if that hat is compatible with the newer version as well.
1 Like
If it’s not compatible with 4 then I can’t take it seriously, sorry.
The PI compute module would be an interesting one to support too.
On their website they confirm Pi 4 compatibility is planned. I think it’s a bit unfair to make such a dismissive statement in your previous post. Many of these types of initiatives are run by extremely small teams or just one guy. I say kudos to elk. I’ve purchased mine already. Keep up the great work elk.
2 Likes
Hi!
The Elk Pi Board is definitely compatible with the Pi 4 physically, but due to the need to develop additional drivers to support the altered hardware, we do not officially support it yet.
Supporting the Pi 4 is of highest priority for us however, given that it is so much more powerful than the 3, and we expect to be able to release such support soon, even though I cannot promise an exact date at the time of writing.
Best,
Ilias
4 Likes
Ok sorry, it seems I posted your existence too early. 
It looks incredibly well designed, and I wish you guys all the encouragement and luck for such a fantastic product.
It’s been a while since I used a Pi, but I was a proud receiver of one of the very first Pi 1 boards from the very first batch that went up for sale. (Which I considered a bit of an achievement, as did the client we bought it for at the time). Although that’s irrelevant to my question, it’s a part of illustrating that I am out of a loop that I was once in quite deep into.
Anyway, thinking about using this plus a Pi 3/4 for the central part of a dedicated audio effects device, I’m curious to know how quickly the new Pi boards boot. Suppose one created a stand-alone audio application on a Pi and had it launch into it from cold boot, what’s the time between turn-on, getting through the OS boot, and the first usable audio cycle in a product with whatever the most sensible OS is to use for this sort of application?
Eagerly awaiting 
I just ordered a DevKit today and am hoping to pair with a Pi4
Hi,
Our current boot time without loading a plugin is in the 5-6 second range, and then it depends on what load times your plugin has.
Obviously this can vary wildly depending on what initialization your plugin(s) need to do - plural since the Elk headless DAW can load several plugins, you are not restricted to running one at a time.
With a simple plugin it is less than a second for the host and plugin to load, so still within the 5-6 second range.
Best,
Ilias.
1 Like
Do you have any rough comparisons for the kind of performance you’re seeing on the Pi 3 compared to implementations on Intel machines for audio? Of course that’s a very wide target, maybe too wide to answer, but for instance if you could create similar patches for Retrologue (which I believe you have implemented on Pi) would there be any sensible way to get a feel for a comparison against that running on Intel?
Hi!
The Retrologue was made using Elk, but using the Intel-based UpCore Rocket board, not the Raspberry Pi 3. Elk supports several boards, listed here.
One of our concept instruments made with the Pi 3, is the Eurorack module hosting the Korg Polysix Rack Extension plugin.
It is obviously as you say a very broad comparison depending on several factors, but very roughly, the UpCore we used is 3-4 times faster than the Pi 3B.
It is important to note that due to our dual-kernel configuration, you can get extremely high CPU utilization without audible artifacts, where on a desktop computer you would have gotten clicks much earlier.
We regularly run the boards with 90% or more of CPU utilization being dedicated to audio without audible clicks, when on a desktop computer you may well start hearing clicks at 50% or less.
The only limit is how many of the cycles you want to leave to non-audio tasks, since we always give the audio kernel the highest priority. In other words if your CPU utilization is very high, first your non-audio logic will start lagging, long before you hear clicks.
Best,
Ilias (of Elk)
5 Likes