Surprisingly my favorite feature is having access to TV’s metadata, so far I’ve spent more time experimenting with the .el* files than playing the damn thing
2 Likes
I would love this!
1 Like
unfortunately you’d probably have to open the case and attach to the uart 
Thought so. I probably won’t risk that lol. I wonder if the first firmware update will have any interesting stuff to poke around with inside the package… as it’ll be more like a regular system update than a bin maybe
How? And could you supply the original log?
1 Like
Pipewire all the way! It’s the de facto standard on all major distributions by now.
4 Likes
I second this!
2 Likes
I might be misinterpreting but why do you find pipewire disappointing?
I mean, pipewire still not very stable, and has a lot of problems. I prefer good old jackd. Usin it at my rpi boxes for audio midi routing. With elektron boxes too, with overwitch and jackd.
1 Like
My new impressions and considerations:
I’m convinced that the platform change has significantly reduced the hardware costs, specifically the logic board. Just think about the transition from a 68k architecture and side-by-side DSPs to a unified architecture, where the very powerful SoC must handle all the processing, including UI, audio, and so on. For example, one core could be dedicated to managing the UI and IO, while the other three are dedicated to audio processing, again supported by the internal DSPs. This logic requires significant software refinement. This may explain the sync issues and the UI not always being responsive, in addition to the frequent, for me, system crashes.
I also believe this is a huge effort for Elektron engineer, where everything essentially needs to be ported to a Real-Time Linux environment. Regardless, I’m much more tolerant of early bugs.
Returning to the hardware power, the SoC also integrates a GPU and an NPU! I think this could be a blast if integrated correctly. I’m very confident.
For the power we’re seeing, integrating time stretching or a synthesis engine might be a no-brainer (unless Elektron intentionally wants to differentiate hypothetical new products).
4 Likes
That’s all good, but Linux is multi-purpose OS, and additional layers between audio hardware, IO, disks, software components. So Linux based products requiring a lot optimisation. And in some cases will not ever be stable and fast as barebone.
Will see. Hope elektron will pass this way
I disagree. The linux kernel has more eyes on it, more hours of dev time, and more years of continuous evolution than perhaps any other piece of software on the planet. Linux powers some of the most performance critical applications in the world. I think it will be good enough for a sampler 
6 Likes
I agree Linux is perfect platform in many ways. But I’m talking about that it is “modular” multipurpose OS. With additional layers between applications, applications and hardware. So you got lot of overhead.
For example - you got to use standard framework to connect your app with audio-midi IO, if you want to get all benefits of Linux and reduce dev casts.
As we can see from logs pipewire used in tonverk.
That’s cool, but it’s additional layer with its own latencies.
And so on.
It’s not a problem for me personally, but maybe someone waiting “RT” with 2ms or something.
And etc
As it says Linux Kernel: 6.12.34, PREEMPT_RT build it is actually a realtime build of the linux kernel.
When I worked on imx8 platform, I did not use preempt_rt, but used the microcontroller on it for realtime stuff, and the whole system was still really responsive and fast.
Yes, but Linux is not only kernel.
If your app not working directly with “audio interface” kernel driver, data(sound) flow looking like something this:
Application → PipeWire → Linux Kernel (ALSA) → Sound Card Hardware
Same for midi.
So, you got many layers for delays and jitters appears.
If you don’t use standard tools, you need to develop those for yourself and that’s usually a very time consuming job. Besides, who guarentees that the self-built solution is actually better than pipewire for example?
I think Elektron would have switched to a multipurpose OS much sooner if the hardware would have allowed for that. And apart from that, pipewire is really helpful if you want to route your sounds from A to B. You can have multiple programs running and just wire them up with WirePlumber or another session manager. No need to program all the audio routing stuff on your own. And let’s be honest, the whole audio routing flexibility is the main appeal of Tonverk. Heck, I don’t know how they really implemented all the features but I can see why they chose Linux.
1 Like
Sure, but if you switch those components with the graphics equivalents and think of the last time you played a video game with good graphics on linux, then you know there can be very low latency with many components.
Not saying the imx8 is a gaming platform or anything, but audio is not as heavy as graphics, and you also have the M7(or something) microcontroller to help out with stuff.
I don’t have the tonverk, and might never get one, and have read that it’s a bit slow. But it definitely doesn’t have to be with this hardware and linux.
I don’t mean at all that it’s impossible to implement near real-time audio applications on Linux.
What I mean is that there are many factors, pitfalls, and implementation approaches,
which affect sync stability, latency, and much more.
Sure, and you are not wrong about that.
But implementing their own thing from scratch on baremetal also has many factors, pitfalls and implementation approaches, and if they have a serious bug with it, they are on their own to fix it. If PipeWire suddenly had a weird bug, there are many people who would try to contribute to fix it. Of course, Elektron could still have bugs in their use of PipeWire, but I think you understand what I mean.
2 Likes