I just commited a new version to github. Plus added instructions on how to build on Rasbian. I just recorded about 1 minute, all 12 tracks of course with my Raspberry. Sound/timing is top, but there are 5 secs or so in the middle of the recording where it is heavily distorted, need to investigate … The Raspberry has absolutely no problem handling the data, storage as well (2.3MB/s, was using a class 10 SD card/16Gig).
I did some testing on a B+ model, there’s a lot of weird artefacts in the recording. Reminds of the early OB drivers. I hope I’m wrong, but it might be needed to have something handle the data and buffer stuff or something. Sort of like a driver
It might have to do that the Pi simply doesn’t have enough power though I must say the system load while recording is next to nothing. I haven’t tested it on a normal desktop system so not sure if its something as simple as processing power.
Is there a way to modify the code so it only records the master l/r channels and drops the rest? Just to see if that frees up overhead and makes the recording without glitches and artefacts?
Going to release a new version soon. The file writing is the current problem, esp. on SD cards, not because of throughput, but the blocking from time to time during burst writes. Moving the writer to a separate process or thread should solve the issue.
Maybe this explains why I had less issues on arm dev boards with emmc onboard. Yesterday I had both glitches on sd card and a network disk. I tested the sustained speeds on B+ wifi and it’s about 6-8mb/s. Should be enough on paper. Looking forward testing the new code
I pushed a new version! Major changes:
Moved the USB transfer handling in a separate thread, running at highest (real time) priority. Data is then written to disk in a lower prio thread, with lots of buffers in between (queue). Also, disk writes are forced at a constant frequency to avoid massive caching/“bursty” writes esp. on SD cards. Some stats are displayed during a run:
283775 kB - buff: 8192 - xrun: 0
287508 kB - buff: 8192 - xrun: 0
291682 kB - buff: 8192 - xrun: 0
^CShutting down …
Total stats: Buffers low: 7741 - Xruns: 0
“Buffers” is the current number oft free units in the queue (units: One USB transfer = 8kByte). The default length is set to 8096 items, but can be changed in the source if needed (overbridge.c line 20). Additionally, the time stamp in the sound data from the DT is checked an compared between packets, if some data got lost, the xrun counter is increased by one.
I recorded a few minutes on my raspberry without any xruns and checked each track for glitches … there are none
- Record to 12 single mono files
Start it with ./dtdump -s
Note: In the old version of the README, I forgot to add the cmake parameter for passing the optimization flag -O3 to the compiler, so remember to run it with
cmake …/ -DCMAKE_BUILD_TYPE=Release
Have fun …
Not all heros wear capes!
Will give the new version a go tonight. Thanks for your hard work
It might be helpful for others when there’s a documentation of your insights about the protocol. Maybe others are able to contribute to that. I’m thinking about a breakout-box to get the live audio of the single tracks out of my Digitone into a analog mixer.
The protocol spec, or more what is known of it so far, is already in the source comments I just updated it (number of blocks per USB transfer was wrong, added some details).
Duh. I didn’t looked at the headers
Thanks again for this awesome work!
Thanks @droelf it’s amazing and it works on the DIGITONE too !!!
I can have a dump of each track of the digitone and a track with the mix.
Just change this in the overbridge.c file
// we support only the Digitakt for now …
#define DT_VID 0x1935
#define DT_PID 0x0014
//#define DT_PID 0x000c
Then mkdir build cd build cmake ../ -DCMAKE_BUILD_TYPE=Release make and launch sudo ./dtdump GREAT !!!
Thanks koorenay, I modified the current code to simply try both PIDs (first digitakt, then digitone) during USB init and use the first available one. So it should work now on both devices. I do not have a tone unfortunately, so everyone is welcome to test (and send pull requests ).
Also, in partly related news, I created a kernel driver for overbridge
(should better be renamed to snd-overbridge now …) with both audio AND midi working, plus a modified version of the raspbian image build system
to integrate it in raspbian image builds. The idea is then to have something like Supercollider or PureData running on a Pi (or similar) which could then add some nice features, e.g. routing digit*s external inputs through some effects and mixing them down with the internal channels.
I really hope your work brings someone closer to making the device I crave.
My vision is a simple stand alone multi-out box that connects to the the Digi-x via usb and includes some kind of header that makes sense of the digital audio stream and spits each channel of audio out with a DAC and 1/4" jack per channel.
Thanks for your work!
This sounds like a pretty ideal for Elektron to produce at some point. It must be a consideration or have been discussed by them at some point… Reckon a lot of 'nauts would insta-buy!
I’d insta-buy two
don’t have a digitakt but your effort is really cool! <3 <3 <3
(and it didn’t take 6 months to get a release )
Just connect an audio interface with at least 8 outs to any decent laptop, install the OB2 beta version, and you’ve got that ideal device.
Yeah, I get that that’s the point of Overbridge and I’m sure that would be great for some people - but I don’t want to use a computer - especially when a small, simple dedicated break-out box could do the same job.
With things as they are in the world of computing, I wonder if Overbridge will even have a lifespan as long as Elektron’s hardware devices; it’s conceivable that it won’t. Regardless, a dedicated breakout box is exactly what some of us want, and it would ensure that the insane amount of time and resources Elektron have put into OB, could never become a completely wasted effort.
Furthermore, as Elektron customers, we’re all subsidizing Overbridge whether it’s something we’ll eventually use or not - a dedicated box would nicely share some of the benefits of that cost and labour to a broader user base.
For some of us there’s just something counter intuitive about Overbridge - a lot of people buy dedicated hardware to avoid non-dedicated computational devices; and I’m one of them. I didn’t buy either of the Digis in the hope that Elektron would make a break-out box (I bought them because they’re dope) but I sure as hell wouldn’t say no to (relatively) cheap, hassle free multi-outs.
IMHO it’s definitely not about “how the things are in the world of computing”. It’s about how you use/treat them. With some simple rules like:
- never connect it to the internet
- use it only for audio production
- don’t upgrade/update just for the sake of updating
your computer setup will last equally long as a dedicated hardware box. Of course you need to make sure to stay away from software which requires an online connection (license verifications or different stuff).
But other than that: it’s all about discipline. Just because a computer can do all kinds of stuff and you can install and run a zillion different apps, doesn’t mean you should when you want a stable system which may last a while.
You can definitely build a small form factor box which runs OB (and nothing else). Configure it to autostart everything needed and the usability isn’t far of what you would get (or pay) for a dedicated box.
Exactly what I thought about typing but was too lazy to actually do