Sometimes I have these ideas. I spend some time doing research and eventually don’t proceed with them and they end up on a pile of “unused ideas”.
Some ideas are probably bad ideas, others may be brilliant, who knows, as they end up on a pile of Never-To-Do’s that nobody will see. In the spirit of open source/open information I decided to share this idea, as I’m not going to do it, but maybe someone else is interested in it, it’s free to use:
This one is for people who have very complex midi music, with high note resolution and critical timing.
The pyramid has a Turbo Midi setting, which allows sending up to 6.7 times the speed of normal midi (which is 31250 baud).
You could effectively design a device that goes from Pyramid midi out at 6.7x speed to 16 midi outputs, splitting the data (channel 1 => output 1, etc…) and outputting at normal speed again, and get better midi timing than the normal output (because 1 channel per physical port: less busy on the midi bus, hence better timing).
With 2 of these devices you could get 32 outputs on a single Pyramid, witch significant better timing than the normal outputs through a regular midi through splitter.
interesting.
though Im not sure you’ll get any better timing than a (hardware like iConnectivity) usb host solution, and usb has even more bandwidth.
(though, I suspect at some point the pyramid’s processing/output will become the bottleneck)
you should get 6.7x times better timing between 2 separate midi channels, in theory… (edit: optimal case of course, sending 16 simultaneous notes would not provide any better timing, the difference could be audible for up to 6 simultaneous notes, …if you have crazy hearing skills)
Which could make a huge difference if you have several channels of drums
I’m not so sure about the USB bandwidth, I’m not familiar with the implementation there, nor how iConnectivity device would handle it
well usb 2 is 480 Mbps , 7 x 31250, would be about 0.2 Mbps
the usual argument against usb midi, is that general purpose operating systems it doesn’t have priority scheduling (since its just ‘serial data’) , but this is not (or should not be) relevant to something like iConnectivity/pyramid which are not using such OSs… so can have the same priority as things like DIN.
I don’t think really any of this will have much effect on low volume data like notes/automation, unless you are sending at incredible rates (which your synth also has to handle) … the hope for better data rates is usually that clock will be more stable … since the jitter obviously is the enemy of a stable clock.
edit: I should say I don’t have a lot of experience with the benefits of Turbo midi…
I did try it between the Octatrack and Pyramid, and in my case didn’t really seem to make any difference (at least to clock stability which was my main ‘hope’ for it), but perhaps you need to send a lot of data before you see any difference.
(I don’t have 2 elektron devics, which is a pity as I’d like to see if it made more of a difference when using between these… perhaps the pyramid doesn’t make full use of it? )
MIDI prioritises clock messages, so actually the clock jitter introduced by “lots of notes” is minimal unless you go crazy.
The key here is that instead of making a high traffic bus with 16 channels, you create 16 low traffic buses with a single channel. Something that _ depending on what you are doing_ could make a noticeable difference.
And yes, you will notice a difference quickly for example when layering drum sounds across several channels.
if thats your concern, then usb all the way…
just use a USB Host, then let that fan out to DIN/TRS (if necessary)
usb is also way more flexible, as support multiple ‘ports’ (up to 16) , so you don’t need to cram everything over 16 midi channels. (ok, pyramid only supports ONE port, but many other things support multiple)
I don’t know if turbo midi needs specific hardware ,
if not, if its a software protocol no top, then perhaps talk to someone like Blokas to add to their midihub product - it has a a small MCU built in, so could add support for that kind of thing.
I kinda see where you’re going here, it’s to reduce the midi packet (are they packets? messages?) latency, and effectively channel bond the midi channels on the turbo side (channel bonding stolen from wifi lingo) so you could pack two (or more) midi buses on a single pipe.
On the feasibility standpoint - maybe. I think it would be a fairly significant engineering effort to do something like this. I think you’d have to have special hardware to do the midi channel packing/unpacking. You could prototype this on a couple fpgas or something maybe ? I think you’d have to write custom firmware on the pyramid too, and I’d be concerned about the current hardware being able to do this well.
On a practicality standpoint - well, I don’t really see a musical benefit from the latency. I could see a benefit in terms of “hey, I need more midi channels”. I think, practically speaking, it would just be better if the pyramid had a little more cpu and an extra din port or two, or like the ability to expand into a usb port into multiple buses by way of a usb interface or something. Midi is so dang touchy that, I kinda don’t want new technology as much as I’d want tried and true midi tech (and yet, I cuddle my bomebox at night).
If the buses were faster (and other technical limitations were addressed), I’d probably want things like the ability to mix and match protocols like NPRN and CC and 14bit midi from the pyramid so I could have my high resolution devices be high res. Again, on a practicality basis, I’ve gotten really good with 8 bits of resolution, I don’t really need this - but you could imagine that using a ‘14bit midi cc lfo’ on my moog could be desirable (though I’m realizing I should probably get an envelope generator and just voltage wire it in).
You know, this turbo midi sugg reminded me a little bit of virtual machines in modern computing. It could be cool if you could somehow ‘create a midi bus’ on the fly, and isolate certain data to that channel (like nrpn data, or sysex data). Like the data isolation aspect of it is kind of appealing (cause who knows what a sysex message will do to your pile of synths sometimes). A couple extra din ports would still meet my needs here, but if you implement it first I’ll try it
anyways, I know i’m sitting here like “midi is enough” and yet my important questions to you is: are you gonna prototype this out or what? heehee.
