Hopefully, there is a user who can provide feedback on how Pyramid handles multiple instruments connected. How many can I hope to connect before timing gets noticeably affected? Thanks:)
In my experience, this depends on the instruments, not on the Pyramid (or any other MIDI sequencer).
What do you want to do?
1 Like
Hi Peter, well I was thinking of connecting a drum machine, a preset synth (rompler) and few monosynths. On page 21 of the manual it shows 7 different devices hooked up. I guess I’ll just experiment and take it from there. Thanks for the reply:)
If you mean how many devices before timing issues become noticeable, i assume you mean using MIDI Thru. As Peter states, that is dependent on the gear.
However, adding a MIDI router decreases timing issues due to using MIDI Thru. I have 7 output devices and 2 input devices (plus two of the output devices also acting as inputs) and have not noticed timing issues.
Note: i used to have some bizarre jitter issues, but those were not related to the number of devices.
The picture in the manual is purely illustrative.
The Pyramid has two MIDI Out ports, each of which can send messages on 16 channels, and if your gear has MIDI Thru ports you should have no problem chaining it all.
Get a couple of these (or something with similar functionality) if you want to connect lots of synths.
Depending on the heritage of your synths, midi thru might introduce timing errors if over-stretched ?
https://www.kentonuk.com/products/items/utilities/m-thru-12.shtml
To avoid latency in midi, I believe the best method is to avoid daisy-chaining (using midi thru) on external devices, as much as possible.
The Pyramid has technically 3 sets of 16 midi channels as output, and two sets of 16 midi channels as input (someone correct me if I’m wrong here, going on memory while not at home) - Outputs: Midi A, Midi B and USB, inputs: Midi and USB.
Essentially you want your network to be as “shallow” as possible - a midi router box, as previously suggested, allows you to avoid “thru” on several synths, and instead have one connection from the Pyramid to the routing box, then several connections from the routing box to each synth, avoiding daisy chaining - but you will need to configure the correct midi channels on both the tracks in the Pyramid (and be sure to set the correct midi out port) and on the receiving device.
I may have waffled a bit there, so if you have questions by all means go for it.
Essentially, avoid midi through on synths if at all possible - routing via a dedicated midi router/splitter will be much better in terms of latency.
e: I’m not sure that was meant to be a reply to a post in particular, rather the thread as a whole. Sorry.
2 Likes
Thanks to all for the excellent suggestions. I actually have a MIDI thru box (http://midisolutions.com/prodqth.htm) so I’ll use it and hopefully get this MIDI network connected efficiently. Have a good day/evening everyone:)
Currently I have 5 synths and 2 drum machines connected to Pyramid (through Kenton Midi Thru), without any problems.
I have 5 synths + 2 drum machines + 1 sampler + 2 midi effects in daisy chain (midi thru) without any sync issue. Everything working well !
Hey guys/gals, I appreciate the replies- looks like I have nothing to worry about with the amount of devices (probably 5 max) but, what about MIDI cable lengths? Is there a length I should exceed to avoid timing issues?
Thanks again:)
Any realistic length (less than 15 m) is OK.
OK cool, I’ve never used a cable more than 15 feet so I guess I’m ok. Thanks again:)
The general rule for midi cables is the shorter the better, but if you are using a splitter box, to go to multiple midi instruments, keeping all of the cables coming out of the splitter the same length is best, if possible. It may seem a bit nit-picky, but the differences add up quickly and become more apparent when stacking tones, or creating composite tones from multiple sources.
And yes, anything more than 10 feet can be noticeable, especially with multiple drum machines running.
here’s a quote of my favorite gearslutz post where some calculations explained:
(source: https://www.gearslutz.com/board/showpost.php?p=13971568&postcount=62 )
it’s not gear-specific, it’s how MIDI protocol designed and works since early 80s.
Another more thorough answer to this in case it’s not already fully covered. (I wrote this out mostly for my own understanding of why this is necessary, so please do correct me on any of this that I got wrong.)
- MIDI runs at 31250 baud. That’s 31250 bits every second
- To transmit each byte, actually takes 10 bits: 1 start bit, 8 data bits, and 1 stop bit. So that’s 3125 bytes transmitted every second
- A “note on” message takes 3 bytes (noteon+channel, key, velocity), so that’s 1042 note ons messages per second. Alternatively every note on message takes around 1 millisecond.
- A chord on a poly device might have up to for instance 16 note ons. A drum machine might have e.g. 8 voices. Add a few monos for good luck and you’re in the realm of events that happen at the “same time” from a conceptual perspective are now around 30 milliseconds different in time.
- Also consider that we require a 3 byte “note off” message, regular clock messages, 3 byte CC messages, multi byte Sysex messages etc. all to take up the same time slices that we want to send note on info within.
- Now consider a bass note that might be as low as 30 Hz for sake of argument (i.e a period of 30 milliseconds). Imagine that you are trying to place two competing notes in a similar frequency band (perhaps these are actually a bass note and a kick drum). Place two 30Hz sine waves 15 ms apart and they cancel out. Place them 30 milliseconds apart and they play double as loud. You can see how being constrained about where note placement happens based on other messages on the same physical channel hurts things musically and sonically.
- The easiest way to get around the situation where playing notes for things that conflict like this at more exacting times is to add more physical channels.
- Note: This is one example, another similar example is to just consider the emotive feel to drums / piano. We notice small 10s of milliseconds changes in these values.
- Also consider the values that you might enter using percentage based swing. A 51% swing value at 120BPM shifts the delayed note just 10milliseconds (50% swing: notes at 0ms and 500ms, 51% swing: notes at 0ms and 510ms).
so, the bottom line: one box per physical output = 3 multitimbral boxes (e.g. Nova, Electribe, Blofeld, as on the picture below), and i heavily use their own internal arpeggiator/sequencer functions where possible, leaving Pyramid only for jobs that gear can’t do by itself — various complex modulations, euclidean stuff, etc etc.
on the other hand, such division of labour helps me to keep Pyramid projects in scopes of ~8k events limit, which is absolutely not huge too.
1 Like
Thanks a lot for the detailed explanation. Very cool setup you have there. That looks like a lot of fun:)
1 Like
this helped me a lot to understand MIDI limitations (and the reasons for such things as CC thinning), and made me rethink the device communication completely and invent various optimizations to avoid note overcrowding, because prevention is the most effective way to avoid timing issues.
so i share this knowledge along 
yeah, i like this rig, it took me more than a year to make it so cool, but it’s not really complete at the moment — misses 3rd Axoloti.
ah man don’t i know it! it takes time to set up a creative and efficient workflow for your style of music. i like your setup because it looks and functions like a setup I would design myself if I had the gear you have. looks to me like you have all the ingredients to make serious electronic music, and aesthetically it just looks inviting. Dope for real.
returning to the topic: USB MIDI protocol is not restricted to that 31250 baud rate, so if i need to handle more units via MIDI DIN, i would add some USB host that could 1) host Pyramid and 2) host or contain USB to MIDI convertor with suitable number of MIDI outputs. like iConnectivity boxes.
this would add a couple of milliseconds of MIDI jitter … which is anyway much better than overcrowded MIDI stream with 31250 baud rate.