[sdiy] Techniques for Multiplying MIDI Clock frequency?

[Mike Bryant]

> I was referring only to hardware manufacturers, not software developers.
DigiDesign were a hardware manufacturer.  The ProTools software came free back then :-)


> In that era, all software was Mac-only or Windows-only. You basically picked the platform and developed software exclusively for that platform. Cross-platform successes were incredibly rare.
Agreed.  DigiDesign only changed that once Apple adopted PCI bus so the same accelerator board plugged into the newest Macs and Windows PCs.  But I'd say even now Windows is a minority thing in studios.



>> I'm not sure what this "high bandwidth" mechanism is, other than the fact that Full Speed is a lot faster than 31.25 kbaud.
>> Page 18 of the old spec, deleted in the new one as an alternate mechanism is provided

> Thanks. I never noticed the Transfer Bulk endpoint option before.
> Given that Windows doesn't support non-Jack MIDI Entities, and literally refuses to recognize and connect with a USB-MIDI Device that even mentions a non-Jack Entity in its Descriptors, my gut instinct is that Windows does not support Transfer Bulk  > endpoints, either. But I am a bit cynical. Are you aware of any USB-MIDI Device product that implements Transfer Bulk endpoints?
> If so, which operating system releases actually support this?
> ... and which MIDI software supports the feature?

Windows indeed doesn't.  A few sampling devices use it and they mention Mac only, but as I said it's been removed from the latest spec and replaced by better solutions in MIDI 2.0 



>> If you have a good hub with a well buffered Transaction Translator per port AND a MIDI driver that supports higher rates then you can talk to many devices each at Full Speed.  Each device of course still communicates with the hub at Full Speed, they can't do anything else of course, but the Host sees data arrive from the hub at High Speed.  My driver has been tested using 16 devices all set up to continuously transmit messages at full speed without falling over or losing messages.  That's obviously far in excess of what one is ever going to see in real operation, but gives me confidence nobody will ever lose messages in real operation provided they use an approved hub.

> I imagine that this would have to increase the latency, because the entire packet would have to be received by the Hub before it could be re-transmitted at the higher speed.

In theory it could start transmitting at the point where it knows the rest of the packet will arrive in time, but I've never timed anything that accurately.


> I have a hunch that this wouldn't work for Isochronous, but I can see how it might work quite easily with Bulk.
That was my next comment :-)   Isochronous indeed doesn't.



>>  I really think MIDI 2.0 should have enforced or at least recommended High Speed was supported, but it didn't.  Presumably too many people still using old processors rather than moving to the STM32F73x or NXP equivalent.
> There are *a ton* of USB-capable chips out there, and the price range goes well below what an STM costs. One of the design goals of USB was to make *cheap* possible. i.e. the larger your manufacturing quantity - think: millions of units - the more sensitive the CPU cost becomes.

STM32F730 is $2 and is quite quickly replacing the STM32F103 as the standard MCU in high volume pro-audio equipment as it can take on much of the DSP as well so you can often avoid the cost of a SHARC.  Harman Group and Music Tribe are both starting to use it a lot so usage spreads to their contract designers and spin-offs pretty quickly.  And when the F73x runs out of steam the H75x series start at only $1.50 more for 2.5 times the performance.  I used three F730s and one H750 in a design I did for a client last year.  NXP meanwhile seem to have tied up the Alexa-type and home security markets with their versions. 
Below that the STM32G03, the equivalent NXP, and the new RP2040 are all under $1 if you really only need full speed USB, but give far more performance than older devices.  G03 is useful as so far it does seem to be uncrackable unless you use an electron beam scanner, so it keeps your code secure if you need that feature.



> Plus, if you make something require USB 3.0 then the hardware won't work on old computers. That can sometimes be a sizable market - difficult to ignore.

I said make high speed a requirement, not super speed :-)    USB3 is actually a major problem in audio as it can wipe out some forms of wireless communication so I think most people are sticking with USB2.0.   My clients have never asked for 3.0 anyway, and I don't suggest it even though the VL805 is now under $1.

Mike