Smaller ADC board kits for existing guitars in 2022?

Hi Elk,

I am contemplating using your yet unreleased future products and have a few questions.
My use case is adding boards and controls to my existing guitars, hence, I have no interest in buying new “smart guitars”.

First and foremost, will smaller ADC boards sized to fit standard guitar cavities become available in 2022 ??
A larger pi-kit ADC board is fair enough.
Although, why wasn’t a smaller guitar cavity sized ADC board for Hex pickup connections added in the first place?
All the extra inputs and outputs are completely unnecessary for Hex use cases.
I have seen Elk’s demos of 2 “smart guitars” and believe small Hex ADC boards have long been available internally. Why are these boards not released to the public? Are they going to be released in 2022?

What are computational limitations of currently supported SOCs ?
Could Elk clearly articulate what a Pi4 can and cannot do, what i.MX7 or i.MX8 can and cannot do, what Atom X5 can and cannot do in terms of SIMD capabilities related to number of channels or number of dsp plugins or other useful metrics ?

Are there plans to use FPGA/CPLD based SOMs with own code?
Why not combine your existing CPLD into an SOC that integrates CPLD/FPGA with ARM cores?
Are you suggesting large FPGA/CPLD vendors have worse support for linux than Pi or NXP ?

Lastly, what is the difference in quality/latency/computational requirements between sidechaining raw audio into VSTi (i.e. driving VSTi with raw audio signal instead of with MIDI messages) and DSP code running on SIMD capable CPU?


Hi paisleybeans and thanks for your interest in Elk Audio OS. That was a bunch of questions, but let me try to unpack them one by one in order to answer your questions.

While we usually don’t comment unreleased future products, let me just say that even though I do believe Elk Audio OS would be a great fit for your needs, it’s highly unlikely that we’ll release what you’re after during 2022.

Though we have released the schematics and pcb designs for the elkpi and blackboard pcbs under a CC license. If you feel up to it it should be entirely possible to strip of all the things you don’t need (CV, midi, etc) and turn that into a compact board that could fit in a guitar.

Sorry to disappoint, but the prototype smart guitars we’ve demoed did not have 6 channel independent audio processing.

This is a question that is impossible to answer in terms of channels or dsp modules because it depends entirely on what you do with those channels and how computationally intensive the dsp modules are. Just like it’s impossible to say how many channels and plugins any DAW could run on say, the latest MacBook, without specifying what those plugins are.

There is also a number of other factors to take into consideration. Such as the sample rate and buffer size used, Elk Audio OS can run with a buffer as small as 8 samples, though that gives more overhead and less cpu overhead than using 32 or 64, which we would recommend. Then the SOCs themselves can also be over/underclocked which will affect processing performance.

The boards you mention are all (with the exception of the i.MX7) 4 core cpus. Elk Audio OS supports multithreaded audio processing, but there needs to be a way of parallelizing the computations in order to take advantage of multiple cores. Something like multiple tracks or a polyphonic synth with voices processes in parallel. A single fx chain is more difficult to compute in parallel over several cores.

What you could do is compare benchmarks for the different cpus (A72, A53, A7) to get a rough estimate of how Elk Audio OS would perform for instance on a RPi4 vs an iMX8.

The CPLD is only used with the elkpi and was used to overcome the limitations of the Pi:s I2S interface, which is limited to 2 channels. Basically it tricks the RPi to think that 8 channels @ 48kHz is 2 channels @ 196kHz. For other SOCs we don’t have this limitation, it’s that simple. We’re not suggesting anything regarding CPLD/FGA vendors.

Note that RPi is the only SOC that has full open source support with drivers and fw code. The i.MX7/8 drivers are not open source. If you’re planning a commercial project, feel free to get in touch at and we could discuss custom development or hw design.

Negligible I’d say. Midi could potentially give a hair lower latency as audio input needs to be buffered and the codec latency would be doubled compared to just outputting audio. But we’re talking fractions of a millisecond difference here.

Thanks Gustav,
Pardon my delayed reply.

Appreciate you unpacking my questions.
I am half way there with the understanding.
Hoping you won’t mind if I ask this next bunch of questions that should with any luck get me most of the way through.

  • I may be interested in stripping your board to a compact size. Where could I locate CPLD code?
  • If not in 2022, could a compact 6 channel ADC board be on the cards for 2023 ?
  • Muse demo guitar video says laptop received signal through a dongle. Would you be able to clarify which part was wireless i.e. MIDI or audio signal? Was processing done on guitar or on a laptop?
    Matt Bellamys Elk Powered synth guitar - YouTube
    What was the purpose of the small “sound card” as described in the video if pickup was connected with USB?
    Matt Bellamys Elk Powered synth guitar - YouTube
  • What was the motivation behind 1 channel guitar demos when 6 channel is a possibility?
  • What are pi4’s processing limitations for 6 independent channel processing??
    i.e. Is pi4 capable of keeping up with 6 independent midi 2.0 supporting VST3 Instruments with 1-2 additional effects per channel??
  • When could Sushi support for MIDI 2.0 and MIDI 2.0 capable VST3 Instruments be expected?
    Does Sushi support MPE Instruments?
    Does Sushi support DAW to DAW connection via ethernet for external control and processing?
    What is the difference in latency on stock linux compared to RTOS ?
  • Slightly off topic, but is Wireless MIDI 2.0 possible?? i.e. searching does not turn up much
  • And finally, Which closed source drivers are required in the case of audio processing for non-Pi4 SOCs?
    What business implications does a commercial license entail including extra costs?

Much Thanks

No worries paisleybeans. In order, I hope this should answer most of your questions.

The CPLD code has not be published yet, even though we’ve been meaning to. You can PM @Stefano for it if you need it in the meanwhile.

While I can’t really comment unreleased products, it’s unlikely that we’ll release exactly what you’re after even in 2023.

This link should give you a better idea of the technical details regarding Matt Bellamys guitar. What Chris refers to as the dongle is probaby the wireless audio transmitter. The guitar has a Fishman TriplePlay Midi pickup installed, and the Elk system on board only receives Midi, not audio from the hex pickup. The synth is a Vst3 plugin running in the guitar and the audio is then sent using a normal guitar wireless system (also built into the guitar iirc) Elk Powered guitar on tour with MUSE! - Elk Audio OS

Previously they would run the synth on a laptop and a usb cable from the guitar to the laptop. With our help they were able to integrate everything in the guitar, make it wireless and get better latency.

Mostly time and effort. Also our current development focus is Elk Live and Elk Audio OS, not the smart guitar unfortunately.

The RPi4 is definitely capable of running 6 channels with a Vst instrument on each one, but as said, it all depends on how heavy the plugins are.

Sushi does not yet support Midi 2.0 or MPE. It’s something we would like to add, but we can’t say when it will be avaliable.

I don’t really know what you mean with daw-to-daw connection. Sushi can be controller remotely via gRPC, which could be a plugin in a Daw, but that plugins needs to be written. Though there are examples available to get you started. There is no support for something like rewire atm.

For another SOC you would as a minimum require a realtime audio driver and possibly a driver to interface with low level peripherals such as GPIOs, SPI, etc. Send an email to if you’re interested in talking more about a commercial license. We’re not looking to usury anyone, for small commercial projects we’re def open to work something out that can be beneficial to both parties.

Thanks for being patient with me Gustav

Appreciate clarifying points on commercial license. As i now understand, Elk made a decision to keep own custom audio driver for pi4 open source and to leave this same custom driver closed for other platforms.

If I understand this correctly, TriplePlay Connect uses the 64kb ROM on the DSP(from teardown and dsp datasheet) for custom code to convert 6 channels into USB MIDI 1.0.
Rather than spend time on an ADC to I2S board, wouldn’t it be better to create a DSP to MPE and MIDI 2.0 board similar to TriplePlay ?
Is RTOS even necessary for a 6 channel USB MIDI use case ??
Does TriplePlay support MPE ?
Does Elk have plans for this kind of board?

A couple more harmless questions below.
In the case of TriplePlay - does Sushi create 6 instances of VST Instruments( i.e. one per channel) or is there only one instance of VST Instrument?
Daw to daw question clarification - objective is to pipe 6 channels of i2s audio through the ethernet port to a daw on pc/mac. What is the best way to accomplish this with pi4? At a guess Sushi will not need to be involved or will it?


1 Like

No worries, you’ve understood our open source licence correctly.

That was specific enough that I can say that we don’t have any plans for that kind of board :slight_smile: . It depends fully on what you want to do. If you want to play a synthesizer from your guitar, with separate instruments on each string. Then I think something like the triple play + ELK would be perfect. Though if you want full 6-channel audio processing of the guitar signal in elk/sushi - hexafuzz style, then you do need a 6 channel codec, something like the blackboard.

Bellamys guitar was only a single vst instance iirc, but there’s nothing preventing us using more instances. I don’t know if tripleplay supports mpe, you’d need to check with Fishman.

Then I understand your use case better. For some of our supported SOC/SOMs the device can be used as a class-compliant usb audio interface. It’s currently not possible to use the open source version in this way though.

Though if you are planning to stream multichannel audio into your studio computer, maybe you’re better of getting something like and a multichannel audio interface and skipping Elk altogether. Adding a computer would add more latency and kinda negate the benefits of Elk.

I am nearly there Gustav
Much thanks for your help so far :+1:

To clarify, overall goal is to have an all in one 6 channel guitar with:

  • Hexafuzz style per channel plugin capability
  • MIDI capability to drive synth instruments
  • a MIDI controller
  • Ethernet for external processing when necessary
    Mentioning Ethernet to optionally engage pc processing without using audio interfaces i.e. ordinary network ports can be utilised with lower latency than USB. May even power and charge guitar through POE.

Inflection point may come for synth use case(no hexafuzz) once TriplePlay becomes MIDI 2.0 compliant and supports MPE at a minimum or more through MIDI-CI.
Although, since TriplePlay is connected via USB, nothing is stopping Fishman from feeding raw audio through to pc in addition to MIDI conversion. With some luck this could be their next step.

The following question may finally bring some clarity into SOC/SOM choice.
Keeping code proprietary with increase in price are developer side or oem benefits.
What are the benefits of using SOCs/SOMs other than Pi4 from consumer perspective??
i.e. Is confining I2S channels to 48kHz with Pi4 CPLD solution inferior in quality to other SOCs?
Which capabilities do other SOCs bring over Pi4?
I am sure there are other benefits for consumers over Pi4 I am not aware of.

I can understand that a Hex ADC board is a niche application that does not justify development costs.
However, a compact 2 Channel/Stereo ADC board that fits into guitars with built-in SOC or gold finger SOM port would qualify for broad adoption.
Are there plans for such a board?
From what I can see HiFiBerry does not fit into guitars or does it?
Going back to Hex, does anyone else supply 6 channel “on guitar processing” kits?

Without going further into “public release” product development, how much would a commercial license cost for a single prototype board?


Hi again. Hope that you’ve gotten a better understanding of the Elk system.

It sounds to me that a good starting point could be to use a hifiberry (with a high impedance preamp) for the guitar audio + a Fishman TriplePlay. That would give to option of both audio processing and playing midi instruments. Possibly at the same time and layering processed guitar with synth sounds. Albeit not with individual string processing. But it’s something that can be build from of the shelf components. Maybe you could expand with a 6 channel interface eventually?

Depending on the thickness of your guitar, I think you should be able to fit a RPi4 and a HifiBerry hat. Though you need to measure the height of it.

The CPLD does not affect the sound in any way, and the codecs used in the HifiBerry as well as in the elkpi are good quality codecs. The choice of SOC/SOM has more to do with component cost and processing power than audio quality.

For commercial inquires, drop us an email at

Thanks Gustav
At this stage I am contemplating a commercial enquiry subject to last few clarifications.

Regarding HiFiBerry and TriplePlay, it does appear that a combination of 1 Channel Wireless with Jam Origin’s MIDI Guitar 2 is currently a superior solution for Mono setups.
Upcoming MIDI Guitar 3 will be a significant upgrade with MPE and MIDI 2.0 instrument support.
Hex board scenario, unfortunately, remains unaddressed for the time being.
Would it make sense for Elk to release a compact ADC+SOC board(closed source driver) marketed to Mono users with a paid driver or ADC upgrade to 6 channels ?
Or a compact ADC+DSP board that converts to MIDI 2.0/MPE i.e. without SOC?

In terms of further clarification, I am looking for compelling reasons to choose a faster SOC than Pi4.
Based on what I gathered so far, USB Audio Interface capability is a major benefit for Hex and Mono consumers(i.e. ability to experiment on PC/Mac before loading onto guitar).
To the questions:
Will Sushi support for MPE and MIDI 2.0 increase computational requirements and edge out Pi4 suitability for Hex? (Mono may still be ok)
Are there any compelling examples of increased processing power benefits of other SOCs for Hex use case?
In plain terms, what can imx8 do that pi4 cannot in terms of Hex?
Does component cost of standalone iMX8 work out to be approximately equal to Pi4 combined with CPLD ?
Will 5m USB cable ok for power and data or will it be limited to 3-4m?

Appreciate your time

Come to think of it, is Sushi capable of polyphonic Audio to MIDI ?
or is it Monophonic i.e. one string at a time ?
How would Sushi’s Audio to MIDI capability compare to Jam Origin’s MIDI Guitar ?


A clarification on this point: Sushi does not contain any pitch to MIDI functionality, nor am I aware of any plugin which we may have tested that does this.

When we’ve needed pitch to MIDI, we’ve used e.g. Fishman pickups, which output MIDI directly, and which we drive software synths with, that Sushi hosts as plugins.

It certainly is a theoretical possibility that a pitch-to-MIDI plugin can run in Sushi however, but that would need to be developed, and I cannot guess really how many instances of it an RPi4 may run in parallel, since that depends entirely on the algorithmic complexity of the plugin.

Ilias of Elk

Hi Ilias,

Thank you for bringing essential constraints to my attention.
Fishman unfortunately is not there just yet with Audio to MIDI depth of conversion. Their next iteration with MPE support may be the way to go once released.

Would it be possible for Elk to compile and test the performance of Jam Origin’s VST as it is just about the only one with good quality Audio to MIDI conversion?
I believe Jam Origin is Danish.
SOC choice in my case would largely depend on the outcome of this test.

In terms of USB Interfaces, is Elk’s implementation done using an external controller e.g. XMOS or a codec chip with a “USB Gadget” driver that turns USB port into device mode?



Unfortunately helping open-source license users with building and testing specific plugins is too resource intensive to make business sense for Elk.

From what I understand Jam Origin is a closed-source commercial product as well, meaning we cannot run it without access to the source-code anyway.

With that said, you are of course more than welcome to either x-compile and test yourself, assuming you have access to the source code, or alternatively to contact us with any commercial enquiry you may have!

Re: USB interfaces, I am not the right person to ask, but IIRC we use an XMOS, not a code chip with USB support. Note that this is for our closed-source platforms, not the dev-boards.

Ilias of Elk

Hi @paisleybeans,

we are not in contact with Jam Origin’s developers, so it won’t be possible to run their product.

For the rest: SUSHI doesn’t support MPE directly, but it’s possible to somehow recreate the functionalities by assigning one MIDI channel per-track - at the increased expense of multiple plugin instances.

There is no pitch tracking inside SUSHI as Ilias said. but some users were able to use integrate the aubio library (which is not as good as other proprietary solutions, though).

For the USB audio gadget functionality, it will be available on a plain RPi4 for the next release without an additional MCU like an XMOS, although the software-only implementation will have a significant latency when transfering audio to/from the host.

Thank you Gentlemen
Admittedly, current state of affairs is pushing me towards external processing with an XMOS based
6 channel wireless board.

That said, I may not be aware of what’s to come. Hence, my questions are:
Are there any plans for DSP or Software based Monophonic Audio to MPE conversion ? (not mentioning Polyphonic as it may take too long)
Next step is closed source Synths and VSTs from proven vendors.
Does Elk have plans to reconsider its Wine strategy despite copy protection and go the route of Muse Receptor?
Or perhaps plans to gain official backing for running plugins with Wine through partnerships with big players including Jam Origin?
Partnerships may even bring in ARM compiled versions as Mac equivalent of Wine is not quite there yet with arm binaries unfortunately.

Last but not least, how does lack of big player plugins affect Elk Live?
Does running VSTs and Synths externally negate advantages of low latency and put Elk Live into the same category with Steinberg’s VST Connect or VST Live?


These issues may not be as bad as they sound.

After all, each makes their own decisions on how to use plugins and its not up to Elk to decide this.
Everyone should be free to choose running plugins through Wine.

Do commercial plugins compiled for Windows on ARM perform well through Wine?
What is the real reason why Sushi does not support Wine if all legal responsibility is on the user?

Hi @paisleybeans,

You’re absolutely free to modify SUSHI / Elk as you please (obv, respecting the licensing terms), including adding Wine support for the plugins.

But sorry, I think it is totally our decision to decide if want to support this or not. The reason n. 1 why we don’t is that it’s impossible to fix things if they are wrong in the plugin (e.g. non-RT safe operation that causes Xenomai mode switches).

The MUSE receptor went this way and, in the end, the plugins that were working well were mostly those that were optimized for the receptor. So, if you need the original plugin developer’s involvement, you might as well ask them to cross-compile which also produces a better-optimized binary.

Moreover, most commercial plugins would be difficult to run in a system like Elk even if we did have WINE due to their copy protection mechanisms.

Thank you for illuminating RT kernel issues with plugin emulation @Stefano

Before proceeding I should give you guys props for Elk Live as a product.
Elk Live looks great for pedals, pedal boards and for raw voice.
After all, limited plugin support may not be as essential for remote rehearsals.
I can also appreciate that streaming over the internet justifies using RT kernels.
As feedback for version 2, would be great if the box was more like a pedal designed for floors rather than tables.

A LAN based Guitar Synth use case, however, does not have the limitations imposed by internet streaming requirements.
ARM native plugins are a couple of years early, unfortunately. Windows on ARM is still niche. MacOS emulation is not ready.
Asking vendors to cross compile plugins may be a bit much but command line activation and configuration is pretty reasonable.
Having said that, plugins can definitely be run externally and wirelessly for all 6 channels.
It may be possible over Wifi 6E, though Wifi 7 is where paradigm shift for guitar synths is set to occur.
This is the kind of board I would be aiming to create.

At this point Raspberry Pi 5 is just around the corner.
I imagine it should resolve most performance issues.
On the other hand, I believe XMOS has network output. Is an SOC really necessary if plugins are run externally?
Is RT kernel of much value(doubt it) for running plugins on guitar and listening over headphones?