Keep hitting a wall with troubleshooting a jitter/sync issue between the Pyramid and the TR8. Setting up a long set with lots of data inside the pyramid and it seems that there’s an increasing problem with TR8 falling out of sync after 2 bars… It’s consistent.
Spent the past few days trying to figure out if the issue was TR8 - have tried everything, looked everywhere. I know how to problem solve most anything with the help of the nice people on the internet… and manuals of course.
Downloaded updates for squarp and tr8, and no go. None of the other fixes regarding the TR8 on forums solved it. But it seems i’ve narrowed down the persisting problem to entering a good amount of data into one pyramid file.
I strongly believe this is a pyramid problem, because when I start a new project file and enter a very minuscule amount of data into the pyramid then things work fine, reliably so… but going back to the saved file about halfway through an hour set things start to jitter behind the beat (not phasing out of sync or anything, just a “flam” kind of thing).
Approaching a solution… might be the amount of MIDI data being sent simultaneously… like on the same beat. Kick clap and snare being sent to TR8 simultaneously on same beats makes the whole thing jitter. Maybe it’s just a problem with MIDI itself being a protocol language. Is this why people go for the Cirklon?
MIDI is a serial protocol (and a slow one at that), no two notes sent down the same wire ever occur truly simultaneously, and more data you cram down the wire the more noticeable it will become. It happens with everything, but it’s more obvious with sharp sounds like the drums.
What you can do about it is
use USB or Turbo MIDI mode if your hardware supports it
spread out your hardware over the available outputs, keep daisy chains short
arrange your music to take the MIDI reality into account
Appreciate this reply~ as I had suspected, MIDI is just not that great for complex music.
Just to be thorough in the explanation of this scenario (for anyone else who might find this thread useful):
Pyramid OUT A --> Modular (mutant brain)
Pyramid OUT B --> MIDI Solutions Thru 4 box --> Ch1 to modular Drum Sequencer + Ch 2 to TR8 + Ch 3 to Rev2
@pmatilai - good ideas above, thanks again. To clarify, I’m not using USB/laptop here. As before, hardware can’t be less spread out and nothing is chained aside from the Thru box (and jittery problem persisted with just 1 kick from modular and 4 sounds from TR8 triggered from Pyramid). So I must resort to limiting the music in this way - not such a huge deal for techno, but also a major bummer given the price/otherwise great capability of this sequencer.
Would really love it if Squarp are already thinking about how to adapt MIDI 2.0… or doing something like the Cirklon.
OUT B is a possible bottleneck as you’re feeding three different synths through it. OTOH with just four notes it shouldn’t really be noticeable, that sounds like there’s something else going on.
Since it’s a specific part of the set where it starts happening, I’d look more carefully into that: lots of CC data (whether from an effect or recorded) can drown a MIDI line easily. Are there many MIDI effects active on the Pyramid (accidentally or not) at that time?
The MIDI clock will also chew its portion - if you don’t actually need it then turn it off. But again, four notes are nothing. There’s something else at play.
Thanks @pmatilai -
Only MIDI effect is swing on 4-5 channels. Only cc is velocity on TR8’s kick, snare, clap, and two hi hats. That and the rhythms and clock. I wonder if there’s a way to disable start/stop on the TR8, or I could try and find a way of giving the TR8 it’s own MIDI out from the Pyramid maybe that’d help?
This happened kind of suddenly after working in sync just fine for almost 4 months so… i feel like you might be on to something with the amount of data.
Not sure if I understood that correctly, but if you’re trying to send four simultaenous notes and an expression (?) CCs for all at once, that’s already eight events already competing for the same spot of wire where only one can get through at a time.
For the clock I assume you have Pyramid as the master, and if you don’t need it then disabling it on the Pyramid can clear up the line a bit. Note that there are separate settings for each output, and separately for sending start/stop and the clock beat itself, the beat is the expensive one.
Appearing suddenly is a clue of something, but one must be careful not to jump to conclusions based on assumptions. I’d hook a MIDI monitor to the thru-box to see what’s really hitting the wire at the problematic spot, and work from there.
MIDI is serial, true - but fast enough to handle a few Note Events at the same time. Technically they’re NOT at the same time, but dang close. Yeah, it is still slow comparatively…but: blah blah blah
MIDI is transmitted as asynchronous bytes at 31250 bits per second. One start bit, eight data bits, and one stop bit result in a maximum transmission rate of 3125 bytes per second.
So, I haven’t had enough coffee yet, but trying maths with a dusty head:
3125 bytes/sec; a Note On is 3 bytes, so slightly less than 1ms to send a single Note On. Really, you generally have to send a LOT of data to hit a noticeable lag. But that does depend on equipment. And obvs it is easily doable to overload a data stream or receiving device.
And yes, there is the Seq Start and all the F8 timing msgs, etc. Your mileage may vary.
But I have hit that ceiling on plenty of equipment in the past and I have yet to hit that ceiling with the current rig and narrow it down to the Pyramid not being able to send the data fast enough. And I send a LOT of data both in and out of the Pyramid.
as others have said, Id try to narrow down the cause… e.g. can you find a part of the set that is prone to the issue?
I think its unlikely even with midi din that a few notes on/off are going to start altering timing much… its more likely if you have lots of continuous streams (e.g cc/ch. pressure), but if timing is super critical then it could be the issue.
but if it is midi din serial rate causing the issue,
then an option would be to connect a midi hub that supports USB host e.g. something like iConnectivity midi. USB has a much higher throughput, so would remove the bottleneck from the pyramid to the ‘hub’.
however, Id first attempt to narrow down the problem area before trying to buy something to solve the issue.
Apologies for the thread hijack, but you mentioned
Is this also if youre not going thru a computer? (I know, stupid question).
Im going Pyramid->Hub->BomeBox with about 14 channels, not all playing constantly (some channels are just track trigs & mute/unmute for OT). I havent run into a problem yet, but i still have a prejudice against USB MIDI.
Note: been getting over this since i took the computers out of the mix
If thats thats the case, i might switch a few devices over to the USB universe and not stay awake at night tossing and turning in between MIDI jitter nightmares
@CreepyPants
-TR8 is sometimes running both it’s own patterns (from the TR8 sequencer which is sync’d to Pyraimd). Problem doesn’t happen when it’s 1 or two sounds with velocity info.
-Also sending note data to TR8 (using it as a sound module)
@thetechnobear
the TR8 falls out/jitters when there’s simultaneous notes (kick, snare, clap, 2 hi hats, and each with their own velocity information) being sent along with the transport and clock… the pyramid has no issues with the modular stuff’s timing.
I might have said before that this started happening recently. I think I’ve done simultaneous beats before - I have good ears, classically trained as a percussionist (humble brag), so I would have noticed if it was happening before.
Keep in mind that velocity is part of the 3 byte NoteOn data, so velocity info or not is the same “size” msg.
Eg 9c nn vv
Where c=channel #, nn=note #, and vv=velocity
Have you tried either method solo and received the same results? As in: only parallel sequencing, note results; only sending note data, note results.
I send WAY more than just a couple note ons thru the same Pyramid port and havent experienced this…and im one of the people who looks for this type of problem because i have run into it with other equipment in the past.
Actually i think i use a full 16 Channels on one DIN port, thru box to 4 multi timbral synths, one that has 6 channels dedicated to drums/percussion, and im a 4-on-the-floor whore (so generally twice a measure i have kick, snare, hh, shaker, some perc, often a cymbal)
as @CreepyPants pointed out, with midi DIN you’ll get amount ~1ms resolution, so 5 ‘simultaneous’ messages would be about ~5ms apart… but thats a very short timeframe, and inherent in midi (and always has been )
apart from that, perhaps try without the thru box, see if you still get the same issue.
(do you have the MIDI IN connected? if so check you’re not getting any kind of midi feedback loop)
sure, the throughput is down to what you host/device can support, but yeah you’d expect same throughput as a computer.
the main ‘issue’ with USB midi, is that general purpose operating systems(e.g macos/windows) do not prioritize usb serial data , as its designed for things like printers/storage which are not time sensitive. so some incorrectly believe USB causes jitter, but its not USB issue, hardware devices do not necessarily have this limitation.
note: the reason USB sound cards are ok on pc’s, is they use asynchronous data transfer over USB which are know by the OS to be time critical. probably midi should have used this… but its much more complicated to program
another interesting tech which I’m starting to use is RTP Midi, so midi over ethernet, but that’s a whole different topic.
One more thing: at least in my experience, a problem appearing suddenly is more often than not a result of some change (config, physical setup, whatever) that I did for one reason or another and then totally forgot. Until when much later some mysterious problem arises on something that used to work, and once chased down, it turns out to be that “interesting knob in the settings that didn’t seem to have any effect”
One thing that’s been helpful with me managing jitter is how I use the two midi buses. I tend to have clock sensitive stuff on Bus B whereas my instruments are on Bus A. Also, I try to be cautious how much midi CC stuff I use (midi plugins included). If you’re finding more data increases jitter, then use less data - some ways you can do this are to do more programming in the synths (lfo’s over automation things like that).
Blew my brains out practically with this same situation. I ended up having to use the tr8 as the master clock with the hermod last in line of my machines.
My tr8 sync perfectly but I send note and cc to the tr8 and I dont play notes from the machine or use its patterns while I send notes from the pyramid.
It is the only instrument on the midi out b and it wired directly.
On the midi A out I ve all the other stuff with a kenton.
)