Hi Darenager,
Have you tried this?
It’s a long shot, but worth a try.
2 Likes
Another good one.
Win7 SP1, no hub, computer is a Asus laptop, has 1x USB2.0, 1x USB3.0 tried both with same results, using Elektron USB cable, on Rytm and Digitakt both are set to midi over USB only for in and out.
Also sometimes this happens, after it had previously been connected just fine.
It’s possible transfer doesn’t mesh with windows 7. C6 should work though. Is the cpu AMD or Intel cause AMD has issues with audio equipment.
I hadn’t tried it, but I just did try and unfortunately it hasn’t cured the issue, thanks for the suggestion though it was worth a shot 
1 Like
Make sure Autochannel is not set to 1. Make sure nothing else is open that might be using Digitakt.
It is a intel cpu.
Transfer and C6 both work for single files or under certain conditions with multiple files, it is for reasons like this why I try to avoid wherever possible using a computer, it just takes far too long to troubleshoot or wait for fixes.
Obviously a moot point but if the Rytm and Digitakt just had a card slot or usb drive mode like the OT transferring samples would be 1000 times better, guess how many problems I had transferring files to my Octatracks? Not ever a single one in 7 years.
2 Likes
Auto Channel is set to 14, nothing else open. But thanks anyway.
Because it’s completely different. You’re mounting the OT as a drive on your computer, not streaming files.
Yes I know it is completely different, that is why I said moot point, just lamenting.
Correction though, transfer and C6 are not streaming files, they are sending/recieving packets of midi sample dump data. Overbridge is streaming though.
1 Like
That’s intriguing, is this confirmed anywhere or verifiable by rate comparisons - because C6 can handle Turbo MIDI and I can’t see how they can up the ante without further bespoke MIDI handling stuff on the OS side - it’d be possible to sniff the output of transfer on a Mac with MIDI Monitor to check it’s still being done via MIDI with Transfer, but unless I’m missing something that’d potentially make things theoretically slower than other protocols … I suppose there’s the distinction of 'as midi and ‘by midi’ if that line of thought makes sense - is it definitely not just data via USB ?
I’m also curious for real-world feedback on how Transfer feels - is it just quick/stable/flexible enough to be fun to use or is it no better than C6 in Turbo(usb only) on a sample by sample basis ?
Also, curious to know, does Transfer allow you to extract any factory samples from the machine ?
1 Like
You cannot grab the factory samples off the DT. The do not even show up in the file list when transfer is open.
In my experience transfer is pretty stable.
I’ve transferred groups of 30mb files to my DT with no failures. I’m running a windows 8.1 with a 1.8ghz quad core atom processor with 2gb ram.
2 Likes
Actually I might be making an incorrect assumption about transfer using SDS, data rate is around 0.25mbps.
1 Like
Some tech. notes:
Transfer Errors
C6 uses a different protocol to transfer than the one Transfer and crunch use. If C6 behaves differently than the others, than this points to possible bugs in the protocol implementation on the instrument. If Transfer and crunch behave differently, then this points to a problem in the computer software side - and I’d love to know about it (PM bugs to me, submit support requests to Elek.).
If all three programs have similar problems (as @darenager is experiencing) … then the likely culprit is somewhere in the transport: MIDI drivers, computer’s USB, physical USB HW, instrument’s USB & MIDI.
USB
Both Rythm mkII and Digitakt are USB 2.0 devices. Using USB 3.0 hardware will not alter anything, nor will MTT hubs (like Overhub, since MTT is a feature to help USB 1 devices). But, yes, different USB chipsets might handle 2.0 differently. All that said, none of transfer software puts much stress on the USB subsystem, so hardware would be the last place I’d look.
On OS X there are usually no drivers to install, and the system supplied ones seem very stable for this kind of use. On Windows there is great variability, and I really have little advice to offer.
MIDI
On Windows, MIDI functionality may be governed by drivers installed with your audio interface… even if you are connecting over USB (as I understand it). On extremely annoying aspect of this is that Windows leaves it to the driver to decide if a MIDI port can be shared between two applications or not. What’s worse, such drivers often let a second application choose a MIDI port, while only letting the first application exclusively use it. Application writers in turn have various strategies for gaining and releasing MIDI ports… and these are standard.
What this means practically is that even just switching between apps while transferring may have adverse effects: The port could be switched between apps in the middle of transfer, leading to “Connection failed” or other errors in Transfer.
The “doesn’t support Transfer” error (or for crunch “no compatible device found”) is indication that no MIDI messages are making to and back from the device, and likely to be a culprit of the MIDI driver’s exclusive policy: Let the app see the port, but don’t let the app use it.
“Turbo” is a method of overclocking the MIDI serial protocol on DIN jacks. It doesn’t have any bearing on MIDI over USB. As a transport,“Turbo” is still much slower than MIDI over USB. However, transfer speed in all these cases is limited by the instrument, and is, as @darenager reports, about 0.25Mbps.
Duplicate file errors
Transfer 1.1 checks if another sample on the +Drive already has exactly the same length and hash value. The hash values not all that huge: With 3k samples of exactly the same length, you have a 1-in-a-1000 probability of a hash collision. So, large single cycle waveform collections might hit this.
crunch currently doesn’t do duplicate detection, so you’ll be able to transfer the samples. This might help if you want the same file in two places on the +Drive. If they really are exactly the same, this is fine. (A pure 512 sample single-cycle sawtooth will likely be identical in all collections!) If they are different, this might cause the instrument to randomly use one or the other when a project is loaded that uses one.
16 Likes
Thanks @mzero for the comprehensive information and thanks for Crunch, I first tried it today but I will be using it again for sure
5 Likes
Could you provide further information about the hashing algorithm and the hash length? 1-in-a-1000 chance for a hash collision seems ridiculously high for an off-the-shelf cryptography algorithm.
Bye the way, I thought that would just make you laugh, my jokes don’t always work the way I want, but I try, probably too much… 
Anyway, Transfer App, just wanted to transfer that notion to Mr. D…
1 Like
i was a little surprised how often transfer 1.1 fell over on my mac.
considering its a tiny part of usb transfer using new overbridge (presumably) which might be near release/delays.
i assume file transfer is one of the simplest bits of overbridge although it’s sustained data xfer and not little cc’s and parameters.
i do know its very different to test in the office and release into the public realm though.
nothing to do with overbridge afaict
in terms of data xfer , usb drivers , protocols etc.
not specifically the end result of displaying paramters .