Midi Signalflow
- KVRAF
- 2491 posts since 8 Jun, 2010
- Roger Linn Design
I'm afraid it's a hardware limitation. There are many design decisions I made in trying to keep the price to a minimum while focusing on LinnStrument's core competancy as an expressive musical performance instrument. To me, this was one of those cases where I didn't feel the cost of implementing two simultaneous MIDI in/out streams at different speeds was justified.
-
- KVRist
- 171 posts since 10 May, 2018
Perfectly valid. My curiosity is satisfied and I thank you, sir.Roger_Linn wrote: ↑Fri Nov 08, 2019 10:34 pm I'm afraid it's a hardware limitation. There are many design decisions I made in trying to keep the price to a minimum while focusing on LinnStrument's core competancy as an expressive musical performance instrument. To me, this was one of those cases where I didn't feel the cost of implementing two simultaneous MIDI in/out streams at different speeds was justified.
Mike Metlay, PhD (nuclear physics -- no, seriously!)
listen to me: Mr. Spiral | join the fam: RadioSpiral | my gig: Atomic Words LLC (coming soon)
listen to me: Mr. Spiral | join the fam: RadioSpiral | my gig: Atomic Words LLC (coming soon)
-
- KVRer
- Topic Starter
- 23 posts since 19 Nov, 2018 from Germany
Yes, I tested both and switched the Midiport in the Global Settings accordingly.Roger_Linn wrote: ↑Fri Nov 08, 2019 6:50 pm Have you selected with the correct input/output-- USB MIDI or MIDI JACKS?
With the direct connection via DIN other devices recognize the external clock immediately - the Linnstrument unfortunately not. This is not a central element in my setup, but it would be perfect if I could synchronize the LinnStrument Appregiator via external midiclock.
There is no hidden setting for the midiclock and should be recognized directly?
- KVRAF
- 2491 posts since 8 Jun, 2010
- Roger Linn Design
Could you send a brief video demonstrating the problem to the support address?
-
- KVRer
- Topic Starter
- 23 posts since 19 Nov, 2018 from Germany
Yes, I will gladly do that, but only after the weekend when i'm back. Thank you very much Mr Linn for your attention!Roger_Linn wrote: ↑Sat Nov 09, 2019 4:47 pm Could you send a brief video demonstrating the problem to the support address?
-
- KVRer
- Topic Starter
- 23 posts since 19 Nov, 2018 from Germany
Today I got an e-rm multiclock which sends an extremely accurate stable midiclock to up to 4 devices. I first connected the LinnStrument and it immediately takes over the clock with all changes. The Global Settings LED flashes in time and you can even see the numeric value by pressing the Tap Tempo button.Roger_Linn wrote: ↑Sat Nov 09, 2019 4:47 pm Could you send a brief video demonstrating the problem to the support address?
So everything is fine - there is probably something wrong with the Midiclock specification of the Selah Quartz.
The Linnstrument does what it should - all clear, so I'm happy
I will integrate the multiclock into the setup and therefore have no need for an iConnectivity Device. It feels very good to have a sovereign synchronization. My recommendation if you need it.
-
- KVRist
- 82 posts since 5 Apr, 2011
Speaking of curiosity and MIDI:
I always wondered why sending MIDI-Information *to* the LinnStrument via USB is about *3 times slower* than via the DIN-MIDI ports? (its a while since I did check this, so I don't remember the exact numbers)
That was a surprise, I sure supposed it to be the other way around!??
Is there a technical reason for this, like limitations of the Windows-USB protocoll, or a hardware limitation or do I have a flaw in my programs??
Anyway,as said, no sweat, it is fast enough with USB too .... just curious.
- KVRAF
- 2491 posts since 8 Jun, 2010
- Roger Linn Design
I am not aware of any such problem. Are you saying that LinnStrument syncs to an external source at 1/3 the correct tempo? I don’t see how that’s possible.
-
- KVRist
- 82 posts since 5 Apr, 2011
... no, that's not what I mean. What I mean is, when I send a bunch of MIDI-messages say to make a pattern of lights then it takes 3 times as long via USB.
I.e. the *time measured* between the first message sent until the end of the last. Everything else is exactly the same, just the MIDI-port is different.
I don't understand much about the innards of the USB-protocol.
May it eventually be that, while with DIN-MIDI you have essentually not much of a protocol at all (you send your stuff, it's up to the receiving device whether it can handle it), with USB-MIDI there is some form of handshaking to prevent any overflow? Which of course needs time. Would that make sense?
Well, what I said, not a problem at all, just a little (imaginary) frustration that my program sits there twiddling thumbs while the next beat may be waiting.
But while everybody seems to be so upset with perfect timing, it does'nt really make any difference.
And if it does, I call it humanizing
I.e. the *time measured* between the first message sent until the end of the last. Everything else is exactly the same, just the MIDI-port is different.
I don't understand much about the innards of the USB-protocol.
May it eventually be that, while with DIN-MIDI you have essentually not much of a protocol at all (you send your stuff, it's up to the receiving device whether it can handle it), with USB-MIDI there is some form of handshaking to prevent any overflow? Which of course needs time. Would that make sense?
Well, what I said, not a problem at all, just a little (imaginary) frustration that my program sits there twiddling thumbs while the next beat may be waiting.
But while everybody seems to be so upset with perfect timing, it does'nt really make any difference.
And if it does, I call it humanizing
- KVRAF
- 2491 posts since 8 Jun, 2010
- Roger Linn Design
Thank you for the clarification. That's odd. There is a separate coprocessor for the USB port, but it simply passes MIDI messages from the USB jack to the main CPU, and a subsequent analog switch selects whether the received MIDI messages come from this co-processor or the round MIDI jack. The coprocessor does nothing more than decoding USB and passing along messages, so the only difference could be that when a dense stream is received, it's possibly queuing up the received messages. If so, I'm afraid it's not something that can be changed.
-
- KVRist
- 82 posts since 5 Apr, 2011
Thanks for your insight. Actualy I suspect that there's nothing the LinnStrument could ever do about it, as it is a consequence of the USB-protocol itself. But -alas- I don't know and don't really care.
I often was mildly amused about the vigor that some people claim the superiority of DIN-MIDI regarding timing accuracy.
But after all, they may have a point here.
P.S. eventualy if I have time I may do further checks. I would love to be proved wrong and this behaviour would be the result of my own errors. (for the time beeing I'm quite under pressure as our lovely city council has announced the want to 'upgrade' (i.e. tear down) our whole neighborhood )
I often was mildly amused about the vigor that some people claim the superiority of DIN-MIDI regarding timing accuracy.
But after all, they may have a point here.
P.S. eventualy if I have time I may do further checks. I would love to be proved wrong and this behaviour would be the result of my own errors. (for the time beeing I'm quite under pressure as our lovely city council has announced the want to 'upgrade' (i.e. tear down) our whole neighborhood )
- KVRAF
- 2491 posts since 8 Jun, 2010
- Roger Linn Design
I’m still not sure what the problem is. Exactly what is taking 3 times as long over USB? Delay in start of playback? Consistent time delay in response to MIDI Clock? And in comparing USB and DIN MIDI, is there anything else being sent over USB MIDI that is not being sent over DIN MIDI?
- KVRAF
- 8829 posts since 6 Jan, 2017 from Outer Space
@dr_loop: How do you send these messages? And how do you measure? A serial protocol is a serial protocol, meaning sending one byte after another. USB is way way faster than Midi. I rather suspect that on the sending part of your measurement setup is something strange...
-
- KVRist
- 82 posts since 5 Apr, 2011
... well, yes, thats what I thought too and that's why I'm somewhat perplexed.
And yes, I have been a programmer for long enough to (really, I mean really!) know by heart to be *never* too sure about what I'm doing. And I'm well aware of the german saying: 'Wer misst, misst Mist' (Who measures, measures garbage)
But not for the life of me I can figure out what I'm doing wrong.
Well, to be fair, for Sending/Receiving MIDI I don't use the standard Windows API but a very old and long abandoned MidiIO OCX Control, and ofcourse I have no control of what happens inside there.
For timeming measurements I use the proven and solid Windows 'PerformancCounter'-API, so I don't think the problem may be there.
And yes, to be fair, I changed the LinnStrument-firmware a little bit (just 2 lines) so that it is possible to set a LED with just *one* MIDI-message instead of *three*. (And yes, I know, DIN-MIDI is actually USB too, i.e. ->USB->DIN-MIDI)
But all of this is transparent and in the measurements absolutly constant:
So the results of a few dozen measurements:
____________________USB-MIDI_______DIN-MIDI________
Setting 192 Leds_____39.5 - 39.9 ms__10.5 -10.9ms
Setting 64 Leds_____16.7 - 16.9 ms___2.8 - 3.1ms
Setting first column___1.9 - 2.3 ms____0.6 - 0.7 ms
Astonishing! Is'nt it ?!?
(Well, to say it again, it is *not* a problem for me, USB-MIDI is still fast enough for practical applications)
And yes, I have been a programmer for long enough to (really, I mean really!) know by heart to be *never* too sure about what I'm doing. And I'm well aware of the german saying: 'Wer misst, misst Mist' (Who measures, measures garbage)
But not for the life of me I can figure out what I'm doing wrong.
Well, to be fair, for Sending/Receiving MIDI I don't use the standard Windows API but a very old and long abandoned MidiIO OCX Control, and ofcourse I have no control of what happens inside there.
For timeming measurements I use the proven and solid Windows 'PerformancCounter'-API, so I don't think the problem may be there.
And yes, to be fair, I changed the LinnStrument-firmware a little bit (just 2 lines) so that it is possible to set a LED with just *one* MIDI-message instead of *three*. (And yes, I know, DIN-MIDI is actually USB too, i.e. ->USB->DIN-MIDI)
But all of this is transparent and in the measurements absolutly constant:
So the results of a few dozen measurements:
____________________USB-MIDI_______DIN-MIDI________
Setting 192 Leds_____39.5 - 39.9 ms__10.5 -10.9ms
Setting 64 Leds_____16.7 - 16.9 ms___2.8 - 3.1ms
Setting first column___1.9 - 2.3 ms____0.6 - 0.7 ms
Astonishing! Is'nt it ?!?
(Well, to say it again, it is *not* a problem for me, USB-MIDI is still fast enough for practical applications)
-
- KVRist
- 82 posts since 5 Apr, 2011
...thinking about it, it dawned on me that just *because* USB-MIDI is much faster than DIN-MIDI the LinnStrument may be much slower *receiving* USB-MIDI.
According to the documentation, in USB-Mode it spits out data 3.7 times faster than in DIN-MIDI-Mode.
That may mean it has 3.7 times *less time* to handle incoming MIDI, just as my measurements indicate.
Makes sense! No?
.
I dunno, how could the DIN-MIDI-Interface even *know* about this??
.
(To clarify: my measured times are *not* the actual MIDI-transfertimes over the MIDI-cable, they obviously would be much higher (1 MIDI message = 1ms), but the time the Windows *MIDI-driver needs* to send them)
According to the documentation, in USB-Mode it spits out data 3.7 times faster than in DIN-MIDI-Mode.
That may mean it has 3.7 times *less time* to handle incoming MIDI, just as my measurements indicate.
Makes sense! No?
.
I dunno, how could the DIN-MIDI-Interface even *know* about this??
.
(To clarify: my measured times are *not* the actual MIDI-transfertimes over the MIDI-cable, they obviously would be much higher (1 MIDI message = 1ms), but the time the Windows *MIDI-driver needs* to send them)
Last edited by dr_loop on Thu Nov 14, 2019 6:52 pm, edited 1 time in total.