Last note, bare in mind, midi is serial… so if you send thousands of messages, you can delay a clock signal! (even over din/without a computer) Of course then there is ‘expectation’, this can be a bit like ‘pixel peeking’ in digital photography, the more you look for the perfect timing, the more elusive it becomes… whilst someone else sitting back, more relaxed about it, will be happy with a bit of jitter/drift (after all real musicians drift/jitter too ) This is why people have different experiences, even those that have powerful setups, can still can get issues, whilst others with more modest system have no issue… you are only as good as your weakest link. (note: unlike audio, you have to be careful with all IO, and not use CPU) The same is partly true of USB midi, if you make sure your computer is setup to have plenty of IO and CPU capacity, and you don’t overload it… then it will work fine too, the issue is… you only need one rogue process or one rogue device, and suddenly your perfect sync can be go.
In theory you need a real time OS to do audio properly, but desktops today have so much spare processing power, that if we configure them correctly (and don’t overload them), we have no issues with them doing audio. “But my computer works fine with USB midi”… yup thats why I said “theoretically” Why not use isosynchronous for standard USB Midi? well because its low volume data, and its also a more complex protocol, so they chose not to use it, to make it easy for manufactures to adopt - so now we are stuck with the standard (this is how things like E-RM all work, they basically use this isosynchronous protocol, which by the way can be used for anything not just sound) in this protocol you don’t push bits of data at it, you have a time based delivery protocol. “Ah, but what about USB soundcards”, I hear you cry, very true these are sample accurate, and have to be - they work because they use USB isosynchronous protocol.
The reason is ,this is what we usually want… imagine write a file to a USB drive, we don’t care about it being written in bursts, we dont want out computer locking up whilst that file is written - so, arguably USB midi chose the wrong protocol (see below)
Erm multiclock at juno serial#
Modern OS’s do not put MIDI at low priority, they put USB serial traffic as ‘low priority’, which happens to include midi. Id like to change this statement slightly…
Erm multiclock at juno windows#
One thing to remember is that modern operating systems such as Windows and OSX put MIDI pretty low for CPU priority. However, some DAWs I sometime use can’t be clock slaves - such as Cubase - in that case I have to use the Syn Gen II. However, I’ve found Ableton Live to be good slaved to the Pyramid - which outputs very stable clock. The USAMO outputs all MIDI signals - not just MIDI clock.Īs for me, before I had the Pyramid I used the Sync Gen II to sync my external gear - including three Elektron boxes and it works great. The E-RM boxes are expensive but worth it. ERM Multiclock Desktop Sync Clock Device With USB By E-RM Erfindungsburo 440. I don’t think Sync Gen is sold anymore but may be able to find one second hand.
Erm multiclock at juno software#
If you wish to use a software DAW as clock master, I suggest looking at one of the solutions I mentioned above. Audio has a much higher CPU priority and so is much more stable and accurate. What they do is covert an audio signal to an external hardware device which converts it to MIDI. This is why solutions such as Innerclock Systems Sync Gen II, E-RM Multiclock and MIDIClock+ exist - as well as Expert Sleepers USAMO. The result of this is jittery MIDI clock and slightly delayed MIDI signals.
0 kommentar(er)
