OK, I’m not really an expert. Not compared to some of the bods on these boards. So maybe someone else can chip in here?
Also, it’s really hard to comment without knowing/seeing your setup in its entirety, including your routings in the MIO.
But I do have a few observations that might guide you in some self diagnosis.
The ERM is just a clock. It can’t move midi notes forward or backwards, or quantize them. It just tells other devices when to start/stop and very, very specifically and consistently how fast to play.
My guess is you will probably find all the MIDI flowing through your network is rock solid right up until it hits the DAW when you are recording it back in. I’m happy to be corrected but it seems likely to me that the same reason the DAW/computer can’t record MIDI consistently on grid via a USB connection is the same reason clocking devices over USB from the computer is less than ideal for many people. Especially when audio playback/recording is in play simultaneously.
USB MIDI doesn’t have to be consistently sample accurate in the way that audio recording/playback does so USB MIDI resources are de-prioritised. The computer thinks it can think about other things in between thinking about MIDI ticks and because it’s got a load of other things to think about, it prefers that over USB traffic. (I mean, this is why we feed the ERM audio in the first place right? It’s way more stable than MIDI over USB, and probably DIN too).
And no matter how tight the outgoing clock is, you can’t mitigate for any of that on the way back in.
Then again, if you’ve never had issues in the past, I’m not sure what the problem is. It might be the MIO that’s draining USB resource? I don’t know. Sorry.
I very much doubt it is the multiclock (or the pyramid playing sloppy. Most likely the incoming MIDI getting jittery as it is recorded.
I use the clock to keep incoming audio as grid tight as possible. So I’m not reliant on USB clock stability when I’m recording multiple (long) audio tracks into the DAW. And, separately, I use the clock offsets to account for audio monitoring latency when I have bang on grid audio playing alongside audio inputs from midi devices heading into the DAW. If the computer takes say 30ms to process audio input and ping it back out the interface, the A/D converter and into my monitors, I shift the clock on that device forward to account for it (or shift it back on everything else depending on what I’m doing at the time). That way, everything sounds in time as it comes out the speakers.
What’s the reason you use separate clocks out of the ERM? Are you feeding multiple clocks into the MIO? Really, if you can distribute a single clock to all your devices seamlessly through the MIO, you should only need the one clock output. Unless you are introducing audio latency somewhere else in your rig.
Sorry I can’t be more helpful. I hope I’m not spreading silly information around either. Think I mentioned this last week but I tried this some time ago (programme on Pyramid, play MIDi into the DAW, record it and then refine with the DAW as the sequencer) but gave up for these same reasons.
(These days if I desperately want some Pyra midi in the DAW I just load the midi files in off the SD card. It’s a bit of a drag but nowhere near as infuriating as what we’re talking about here)
Oh…one day I’m gonna try MIDI in over ethernet and see if that’s any better.
Don’t know about your multiple notes from the Pyramid. My guess would be that Logic is picking up the Pyramid output and the midi output from the device you are playing. You want to filter that in the MIO I reckon by disabling the input from the device.