Interesting DAW, too bad it’s subscription, guess I’ll build it from source 
You’re not trolling for sure. I’ll keep an eye on your repo and when you’ve pushed some changes I’ll try them. I’m not using a RPi at the moment. Just some “old” arm64 development boards.
I wonder if my recording is that short due to the race condition or due to Audacity. Will find out once Ardour is done compiling.
Very cool, this with a Pisound is basically a DIY OB in a box …
If anyone tried this with a raspberry pi please keep us posted
A raspbery with an Audio Injector Octo would be the perfect combination.
I don’t have any of those on hand, but whenever I do, I’ll try hacking something together.
That’s the coldfire link interface which is used for development (remote debugger/monitoring etc.pp.) with an link<->usb connector like this:
http://www.pemicro.com/products/product_viewDetails.cfm?product_id=163&productTab=1
Could this approach be used to creat Win / Linux drivers for other machines? Eg make roland Linux drivers?
Sniffing lets you potentially reverse-engineer anything - but the posted code is entirely specific on DT data package sizes: the OP worked on understanding those. For another machine, it will require further sniffing and testing.
(Really well done btw!)
I am ordering a raspie.
My plan is to use hostapd to open a WiFi where you can connect to a small website which is provided by a small Nodejs server which can control dtdump. Start and stop recording, maybe configuring recording settings and file download would be a stretchgoal.
I’m thinking of using udev rules. The Digitakt has distinct usb id’s depending which mode. Very easy to make it execute some commands when plugged in and removed. Start recording when plugged in if the Digitakt is in OB mode and stop recording once removed. And do some other stuff when it’s in midi mode. Start soft synths and connect up midi devices for usb host functions for example. The latter I already got working fine. Pretty easy to do. Connect Digitakt to USB port, connect midi device/keyboard to another and just connect the two with aconnect.
The possibilities are endless really. Once midi also works in OB mode we could run soft synths on the RPi and sequence them from the Digitakt and record the results directly. As for getting the recordings, that could as simple as setting up a vhost with directory listing enabled and its root set to the output folder of dtdump.
That are a lot of great Ideas. If we got midi working we also could start recording on start and stop (+tail) from the digitakt.
Midi in OB mode isn’t implemented yet. Thats not up to us for as far as I know. We can set the box in midi mode and it works for sequencing and usb-host-mode stuff just fine. Tested by me 
The harder task is finding out which ones of these sound good and which ones sound crap. And then there are some that aren’t listed like Zynthian. I got some great results with Yoshimi. Takes some tweaking but it can produce pretty nice sounds.
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 
Hi guys,
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 
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 
Nice 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).
https://github.com/droelfdroelf/dtdump/blob/master/header/overbridge.h
Duh. I didn’t looked at the headers
Thanks again for this awesome work!