multiple h/w sequencers & timing

[duncan]

apologies all, if this belongs in another thread or is some of you have been waiting for an update on my earlier posts on this topic.

to remind you- my composing set-up allows me to use several different hardware sequencers via a motu midi router, so that I can use one or more sequencers in combination with a keyboard or a midi-bass (peavey) & capture the results into one of the sequencers (usually the P3) or just record the audio.

I discovered that the octopus was transmitting note-on early with respect to any of the other hardware sequencers, & concluded that in order to use the octopus with the other sequencers simultaneously, I would have to invest in a midi delay.

today the delay arrived. it’s a midi solutions unit, & I can vary the delay using sys-ex from a peavey PC1600 controller. after some experiments, I have arrived at the following numbers. at these BPM, I need to delay the output of the octopus by these numbers of mS:

55BPM 40mS
60BPM 38mS
66BPM 33mS
75BPM 27mS
90BPM 23mS
100BPM 22mS
110BPM 20mS
120BPM 18mS
130BPM 16mS
140BPM 13mS
150BPM 11mS

the test conditions were with a roland EF303 as the master clock, & merged with the octopus into a sequentix P3. the octopus’ output was routed through the PC1600 & the delay device, & then merged with the roland by the motu box. all three sequencers were triggering percussion sounds from the same module, & the results were recorded & then measured in soundtrack-pro.

at all speeds, the roland & the P3 were within 4mS of each other.

plainly there is something peculiar going on with the output "stack" of the octopus, as the timing of midi events relative to other devices is tempo-dependent.

anyone got any observations?
anyone else using multiple hardware sequencers like this?

duncan.

[Riccardo]

not observations but interesting

I should run some tests with SR16, MMT-8 and Tenori On

[duncan]

I mentioned this experiment to colin (P3) fraser, who replied with a theory that they might be treating the "start" byte as the first tick of the midi clock. I’m not sure what that means, but CF knows his stuff. he continues:

>>Well, 60 seconds divided by 50 bpm = 1.2s per beat
1.2s divided by 24 ticks per beat = 50ms
150bpm = 16.6ms per tick, so not too far off – allowing for a few milliseconds latency to reduce the timing advance.<<

gabriel, marcel, you still there? what do you make of this? I can live with it for now, but only if I keep the PC1600 & this delay box handy…

d.

[Author]

Posts