Guys is it possibile to controll two midi devices via midi out and midi thru port simultaniously?
MIDI thru only echoes the Data arriving at the DIN MIDI In … so no
The port can be substituted to behave as a DIN Sync port (not MIDI) (but it won’t sequence that way either)
4 Likes
sure… if one of the target devices has a thru port.
[DT out] --> [device a in][dev a thru] --> [device b in]
thru port is not an active output, it just passes through whatever goes into the input, allowing the chaining of multiple devices. Next, you’ll want to configure your target devices to each use their own input channel.
4 Likes
Oh yeah!!! I forgot that hehe 
thanks!!!
1 Like
And if you have a device with USB midi host (Expert sleepers FH-1, Parva, softsynth in DAW…) you could use USB + din midi out and control two devices without a splitter or using a through port!
3 Likes
@Elektron …or people who knows that Midi business:
USB -Midi Out vs. Din-midi out:
For triggering modules from the DT over midi:
is there a better timing to expect over USB out ?
and at higher midi data load anyway better timing in the whole over USB out?
or would you say if there´s a difference it won´t be noticable ?
tl;dr: Clock timing will be more accurate over USB… but in almost all practical situations you won’t notice.
Consider sending out 100 note on commands, just before the device is trying to send a clock tick. MIDI is serial so the time it takes to send those is going to delay that clock tick. We’ll also assume that you’re at 240bpm: clocks are 24ppq, so that’s 10.4ms between clock ticks.
USB 2.0, at a theoretical 60MB/s max, could transmit 100 note on commands in 5µs! Practical situations get less, let’s say 1/20th that rate, it is still only 0.1ms. So, the tick could be delayed less than 1%. You’ll never notice.
MIDI on 5-pin DIN, on the other hand, operates at 31,250 k bps! Or just 1,302 note on messages per s. Those 100 note ons are going to take 77ms. Seven ticks are either going to be very late, or get interleaved in that stream. In any event, the notes will be late.
Makes you never want to use DIN MIDI, right? But…
This was worst case. In reality:
- How often are you sending 100 note on? I suppose on Digitakt, you could send 8 × 4 note ons + 8 x 8 ccs - so 96 messages - and µTime it just before the beat… so you could manage this…
- Mostly, music events happen on a division of the beat, and most sequencers will prioritize the clock ticks over the other events.
- Devices receiving MIDI clock have to handle clock jitter, and good implementations will glide right through these situations.
- Running status encoding in MIDI, depending on the channels used, could make the data up to â…” smaller.
So, unless you are doing extreme things with MIDI, there isn’t likely to be a noticeable difference in timing. On the other hand - large chords, even just 20 notes, will, for example, smear over 31ms when sent on MIDI on 5-pin DIN, which will be perceived as slight arpeggiation.
1 Like
clock is a midi realtime message and can be sent right in the middle of any other midi message. for example, sending a note on with three bytes:
[status/chan][note][velocity]
clock can be sent like this:
[status/chan][CLOCK][note][velocity]
or before, or after it, or anywhere really.
probably some MIDI parsers don’t handle this properly, but it’s in the spec!
so even with slow AF 5pin MIDI, clock ticks & start/stop etc. should be pretty much on time, no matter what else is being sent.
but yeah anything which isn’t a realtime message is first-in-first-out.
1 Like
Yup! However, in many MIDI implementations, if the notes have progressed into a lower level sending queue, the clock byte can’t interrupt. With USB this can happen as there is a fair bit of queuing below the application. But then it doesn’t matter as much. When the application is tightly integrated (like on a HW sequencer), the MIDI DIN issue isn’t as acute as the application can normally poke right into the hardware driver sending queue.
And yeah, my analysis was like “worst case in the worst situation you could ever see”
1 Like
interesting !
thanks for the input mzero !
THIS is what I needed to see, thanks!
1 Like