problem with midi clock accuracy

Liquid Len · Post by **Liquid Len** » Sat Mar 24, 2007 5:56 pm

I'd love to be proved wrong, but I highly doubt Creamware is in a position to make major changes to the platform drivers for existing cards. (I would have said this BEFORE their current situation). I don't deny these defects exist in the software. They really suck! And it might help to detail exactly what these problems are, not for the sake of complaining, but to map out what does work and what doesn't, more clearly. Griping at Creamware might help getting rid of some negative, pent-up emotions but it won't in any way bring about changes to the economic reality.

valis · Post by **valis** » Sun Mar 25, 2007 12:58 pm

ARCADIOS wrote:valis you do not understand what i mean.
i said that it ALSO happens when using only synths WITHOUT hardware controller.
1st just try to put a 404 in whatever tempo you like internally syned.
lets say 100.
now put a second 404 connected with the 1st 404 and if you set the second 404 to sync externally from the 1st 404 then you will see the same bad accuracy happen to the second 404.
this is nonsense. it should defenatlly not happen.
no hardware sync. just creamware synths.
BIG BIG BUG

I have to admit I've never tried clocking one device off of another. Years ago when I started using my cards I recall discovering that the clock exhibited this behaviour when I attempted external sync and then figured I'd just internal sync instead and forgot about it.

So I see what you're looking at, that the timing of midi even inside scope fluctuates just as it does when coming from a hardware input or from a sequencer (through the OS's buffers). I wasn't completely understanding your former examples and thought you were merely repeating yourself out of frustration. I suspect that language barrier issues were complicating things so I apologize.

Now given that, let's look at the MIDI spec for a second: MIDI clock is 3 bytes that are sent at a rate related to the musical tempo but do not actually specify the tempo. Instead, there are 24 MIDI Clocks bytes in every quarter note. MIDI Clock (time between each MIDI Clock byte) is the microsecond tempo divided by 24. A microsecond is 1 / 1,000,000 of a second, so 60,000,000 microseconds equates to 1 min.

So in your example, if you were working at 100bpm then every 25,000 microseconds a clock byte it sent, and keep in mind it takes a specific amount of time to handle or 'transmit' these 3 bytes. Since the device on the recieving end uses this to derive the actual tempo any congestion in the midi stream will cause minor tempo fluctuations in externally clocked devices. So far this is what I've said before but in a bit more detail.

Now given your above example, I would first guess that Scope simply uses the same MIDI format for its internal operation. Since I know that Midi is async and calculated on the cpu (versus sync which is audiorate and calculated on the dsps) then what you're seeing is Scope's Async timing issues in relation to the host system, something that modular users are particularly aware of. Because the first 404 isn't giving an exact value of '100' to the 2nd 404, but instead using a stream of midi data, again what you're seeing is minor fluctuations in the clock signal. This time it's being moved from one dsp based device to another through the host system.

Audiorate on the dsp card is going to be fixed by your audio clockrate crystal, which is generally as stable as you can reasonably afford to get in an audio environment. A 'vst' application such as FruityLoops calculates all tempo information internally in an entirely different format to midi (in a format compatible with the vst specification) and will only have issues when it doesn't get enough cpu time, as it only needs to insure that it gets all final audio to the ASIO layer in time.

Anyway there are certainly things that could be done to derive a stable internal clock from an external clock that fluctuates, so there is room for improvement here. But I will agree with Liquid Len that you should probably not expect too much for our current codebase, and learning to work around issues like these is common when doing music production.

ARCADIOS · Post by **ARCADIOS** » Sun Mar 25, 2007 3:33 pm

you don't have to apologise valis.
i know that my english is not good as yours (i suppose you are american, according to west coast location you say).
thanks for all information on midi clock.

Post by **hubird** » Sun Mar 25, 2007 5:28 pm

yeah, good story, at least I know the difference now between sync and async...a shame I didn't know that after all those years, I admit

Spend the whole day (minus PZ) on solving a weird Midi problem in my studio that I didn't have before (problem solved tho, read on if you like).

It looked like a Midi transfer problem from Cubase to SFP.
Note triggering was a mess, 1 on 5 played notes didn't sound, note on's were missed, notes off also (damn hanging notes that hardly were to stop), etc.
Midi Filter didn't help, but I discovered that the Virus-A produces active send, which on it's turn seemingly can't be set off.
WTF?

Now it wrecks that I have a complicated studio setup, with two macs, with USB, Midi and ADAT connection all over the place.
I can understand those Reason adapts...

My Korg Mikro controller has usb and Midi, but usb sets Midi off when active.
I can switch to Midi, in which case I send the Midi directly to SFP on the OS9 mac.
This way I can work on only that mac, with Scope and old Cubase VST 5.1, the KVM switch takes care for the rest.

A Roland A880 merges two inputs max, the outs serve the hardware instruments.

NB.
I have also a little utility thingie from Elektron, the Turbo Midi TM-1.
It has a Midi In, Midi Out and usb out.

The usb port improves the Midi speed by max 20 times (according to Elektron), and improves the outgoing bandwidth up to 10 times.
Also sample transfer (in my case to the MachineDrum/S) is much faster than befor,
I went in detail, as this thing could be interesting for anyone, as it is build on the (open source) Midi protocol, it's universal applyable.
About €85,-, it's a design beauty, check the Elektron site (.se).

Then there is the RME ADAT/Midi interface in the OSX mac, it has two Midi interfaces In/Out.
That's nice, as it expands my input possibilities.

I wanted all my controllers and instruments having recordable into Cubase at the same time, to record instantly, be it a Virus or MonoMachine knob, a drum pad on the PAD80 or a fader of the microKontroll c.q. the PC1600.
I got that working perfect.

[Coming from Cubase 5.1, Cubase SX3/OSX has great in/out layout for Audio and Midi (tho the GUi isn't really glossy).
I was sure about my settings.
Btw, only the Audio/Midi Setup is stupid and rigide, they should have a look at SFP for flexible ways of graphically connecting gear!
I'll have to check out Illustrator to make a perfect 'drawing of my Midi/usb connections, as I tend to forget the details after some time].

Then I had that stupid Midi triggering problem.
I was just about re-installing Cubase or other unsure actions; yet I have rather big confidence in OSX as 'closed' system which takes care for internal routings etc. My switch to a two a double computer setup must have been good for something after all

To make it short, I found out that this old little (passiv) Anatec thru box was the problem.
It got it's midi from one of the RME outs, and devided it to the A880 and the OS9 mac, to serve SFP and (other) external gear.
Different cables or changing outs didn't help, it looks like it has gone, or it can't handle clock streams and I didn't know (it did work before tho).
Wish it had been gone dead really , had been easier to detect.

Anyway, it's fine again.
The second out of the more-than-complete RME interface helped me out, so everything is like before

Moral: it's always...not what you think

Check out the Turbo Midi MT-1, it could help in your studios if you have external gear

husker · Post by **husker** » Sun Mar 25, 2007 5:44 pm

just to clarify, the Elektron TM-1 turbo mode can ONLY be used with Elektron gear currently....for other gear you need to turn turbo off. Although it is 'open', no one else supports that mode yet...

valis · Post by **valis** » Mon Mar 26, 2007 2:04 am

hubird wrote:yeah, good story, at least I know the difference now between sync and async...a shame I didn't know that after all those years, I admit

Well I don't have access to the codebase so don't take my word as gospel. I'm just combining lots of hearsay from these forums and a few devs with my experiences. Learning that Scope was developed after a port of realtime csound that I was interested in back in the day went a long way to improving my understanding of things behind the scenes, but without access to the codebase I can't really be sure. In csound there is a-rate & k-rate, and I am somewhat familiar with dealing with both, so sync & async make sense. Exactly how they work I'm not sure, but if async is like k-rate then increasing it by a significant amount to 'improve' the resolution would probably make things worse as it will only make the jitter finer grained (drill'n bass glitch anyone?) and increase cpu load by magnitudes over what it currently uses.

Anyway good to hear you sussed your midi issue. I can relate...back in December I started having a problem with my Scope box, which wound up affecting every PC in here over a few weeks. I was so incredibly frustrated, especially when I started doing reinstalls and it reappeared. I recall whining about it a lot at the time, as it coincidentally started happening the day I decided to try syncing to 88.2 externally. Once I eliminated malware as a problem, I did a bit of stripping everything down and doing disk images as I added things in batches allowed me to finally narrow in on the conflicting app, a software firewall that I've used for years mostly to monitor what applications 'call home'. It was preventing 16bit code from running, which even affected the Scope installer, but most of what it affected didn't seem to have any 16bit code, even after peeking with a resource hacker. It was only stuck WOW ntvdm instances that finally caught my attention.

Something I wouldn't have even known about had I not had problems back on NT4 with my 3d app's serial port dongle crashing constantly, years ago.

Post by **hubird** » Mon Mar 26, 2007 7:37 am

husker wrote:just to clarify, the Elektron TM-1 turbo mode can ONLY be used with Elektron gear currently....for other gear you need to turn turbo off. Although it is 'open', no one else supports that mode yet...

Hm, must have missed something.
What about older E. machines then?

thanks Valis, must have been terrible to experience that problem so long.
Your story made me thinking if OSX isn't involved in the malfunctioning of that thru box, tho I don't have anything firewall activated.
One of those sneaky OSX functions you can't turn off...and I don't know

will check that little box on another notch

samplaire · Post by **samplaire** » Mon Mar 26, 2007 7:50 am

My midi stabiliser request

valis · Post by **valis** » Mon Mar 26, 2007 9:06 am

hubird wrote: thanks Valis, must have been terrible to experience that problem so long.
Your story made me thinking if OSX isn't involved in the malfunctioning of that thru box, tho I don't have anything firewall activated.
One of those sneaky OSX functions you can't turn off...and I don't know
will check that little box on another notch

The only thing terrible about it was the time spent looking for the source of the conflict, as these machines are my sole source of income. And the 'bug' that the software was displaying has more to do with Windows software than anything else. I doubt the OSX firewall is causing similar issues. The only reason that WIndows software firewalls could even begin to have this issue is because every 'security' app wants to monitor every aspect of operation on a Windows box now. I wish that I didn't have to run such things, as I'm less concerned about 'viruses' (never had one on my main boxes) and such than I am about applications that are installed with legally purchased (or free) tools that I used and include other payloads.

In any case, here's to hoping that all of our Scope wishes eventually come true.

Post by **hubird** » Mon Mar 26, 2007 2:30 pm

ok, thanks for the reassurence

ARCADIOS · Post by **ARCADIOS** » Mon Mar 26, 2007 5:58 pm

so i guess its time to have a midi clock stabilizer.

husker · Post by **husker** » Mon Mar 26, 2007 6:19 pm

hubird wrote:
husker wrote:just to clarify, the Elektron TM-1 turbo mode can ONLY be used with Elektron gear currently....for other gear you need to turn turbo off. Although it is 'open', no one else supports that mode yet...
Hm, must have missed something.
What about older E. machines then?

there is only 1 'older' E machine - the SIDstation, which doesn't support the TM-1 turbo mode. So just the machinedrum and monomachine currently