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.

[Chris Henkel]

…sorry, have nothing to contribute, but thank you for the information – it might help me to solve a problem in my setup i couldnt really lay my hands on yet…

[Carlos Dalla-Fiore]

This worries me. Especially if the offset varies per BPM. Live performance will be seriously limited if this is the case.

recently i’ve been running a 707 as master to a 606 via din-sync and Nemo as midi slave which is triggering synths and a "touched by sound drm"

The DRM isn’t in time and i’ve been offsetting STA values to try and compensate.

Yesterday an mpc1000 arrived wich i hope to combine with the Nemo for a performance setup with a few synths.

I will try to measure for offsets using a similar technique.

[duncan]

I’d be interested to see the results, when you have time. I should have mentioned, my octopus is running v1.6-something, the latest version. using the delay box means I can get on with using it in the studio at least, & provided I keep the peavey somewhere handy, I can always adjust the delay.
still, it would be nice to hear from the genoqs lads about this….

duncan.

[Carlos Dalla-Fiore]

i havn’t measured as yet, but connected the 2 units and already could hear the problem.

With the Nemo as master it was triggering early. Moreso at low BPM. The MPC as master was closer and stable but jittery. I’m not sure if this is the Nemo, MPC or both.

DIN sync with the Roland boxes doesn’t seem to have this problem. Is this because the machines/processors were simpler back then?

[duncan]

sounds like the same thing I found, then. like I say, I’ve cracked it for now with this delay unit…. but it’s a nuisance having to tweak the thing whenever I change tempo.

din-sync, very sensibly, was a dedicated stream of pulses (24 or 48 ppqn, depending whether you were roland or korg, but otherwise compatible) with the start/stop carried on a separate wire.
midi tries to get everything down a single wire (the other active connection is a steady 5V reference, while the ground wire is usually connected only at one end), which means 16 channels-worth of note-on/off, continuous controllers, patch changes, sys-ex & all the rest, fighting for space at 32.5 kbaud. somewhere in amongst that is the realtime clock data & commands. they’re supposed to be prioritised, but how does that happen in practise? it doesn’t.
besides that, as I have been told, midi "start" & clock bytes are supposed to be separate, & it appears that they are not, in the octopus’ current implementation.

might try an email to genoqs, since they don’t appear to be watching this thread..

d.

[Chris Henkel]

…there is a – pretty easy solution available, which, however, does require someone to release a bugfix-update for the Octopus-OS…

---

how to solve the Octopus-timing problem

---

while reading the measurement results it was immediately clear to me that
the initial MIDI clock event is missing before the sequencer plays the first
step. Following calculation example proves this:
with 24 ppqn MIDI clock resolution, we expect a MIDI clock event with an
interval of: 60 / (bpm * 24)

Compare this with the measurement results:
100BPM 22mS -> expected 25.0 mS (+3.0 mS)
110BPM 20mS -> expected 22.7 mS (+2.7 mS)
120BPM 18mS -> expected 20.8 mS (+2.8 mS)
130BPM 16mS -> expected 19.2 mS (+3.2 mS)
140BPM 13mS -> expected 17.8 mS (+4.8 mS)
150BPM 11mS -> expected 16.6 mS (+5.6 mS)

The values don’t match exactly, but this could be related to a systematic
measurement error (e.g. latency caused by the MIDI router and/or sound source),
because the offset is usually around 3 mS). With BPM >= 140 the offset gets
longer, it seems that the whole chain is under heavy load.

However, looking into the source code: you will find the timer
which sends the MIDI clock under _OCT_interrupts/Intr_TMR.h, driveSequencer()

Genoqs uses the G_TTC_abs_value variable to count from 1..12 for
each 16th step:

// G_TTC_abs_value: The master time keeper between two matrix columns
// Generate the absolute value of TIMER_TICK_COUNTER – which is the master time keeper
G_TTC_abs_value = (G_TTC_abs_value % 12) + 1;

The MIDI Clock is sent with each second TTC (since MIDI clock is working
at half resolution)

// Send MIDI CLOCK on every other TTC starting at 1
if ( (G_TTC_abs_value) % 2 == 1) {

_OCT_exe_keys/key_functions.h, sequencer_START() initializes
G_TTC_abs_value with 0 – thats ok!

But: in Intr_TMR.h the clock is sent before G_TTC_abs_value will be
incremented, accordingly the first clock will be skipped, since:

G_TTC_abs_value == 0 -> (G_TTC_abs_value) % 2 != 1
(no clock)

Proposed change: in _OCT_interrupts/Intr_TMR.h there are two places
where G_TTC_abs_value is incremented (switch() case ON, OFF)
You can safely incremented this counter before the switch() statement,
and especially before MIDI clock should be sent.

Therefore: remove the two "G_TTC_abs_value = (G_TTC_abs_value % 12) + 1;"
lines inside the switch() statement, and add this line at the beginning
of the driveSequencer() function, e.g. after G_MIDI_timestamp has been
incremented.

—-end of solution—-

…best wishes,
chris

[duncan]

chris- excellent work. I wish I had the understanding of the source code & the ability to recompile it myself; this is plainly where the problem lies, & agrees broadly with what colin "P3" fraser suggested a few weeks ago.
I think there are a couple of other forum members- one at least- who have created their own versions of the o/s. maybe this solution should be cross-posted to make sure they see it, & then they can incorporate it in the custom builds.
meanwhile, where are gabriel & marcel?

duncan.

[john Kimble]

If you let me know exactly what changes need to be made, I can recompile an OS file.

I’ll see if I can figure it out from the previous post.

Duncan, would you be able to test the OS to see if it resolves the problem?

cheers
ripe

[john Kimble]

OK, I made the suggested changes.

The file is here:
http://www.socialentropy.com/studio/OCT_162_jk03.elf

Obviously, use at your own risk, etc

Let me know how it works out.

cheers
ripe

[Chris Henkel]

duncandisorderly wrote:

Quote:

excellent work.

…the credits belong to a dear friend whom i had asked for help with this problem – i just quoted from what i was sent before…

…also i am not able to provide a more detailed instruction myself in regard as to how this could be solved in code…from what i understood though, the quote in my last message should contain all the neccessary information for someone able to make a compiler-run?…

…if not, i’d suggest we call genoQs and ask them to do it…

…i was hoping to meet them in person last weekend during the ‘Synthesizer Meeting Munich’ – unfortunately they did not attend…so i could not ask them about it…

…did i understand correctly that ripe would be able to provide an updated OS but does not yet have enough information?…please let me know…

Post edited by: fairplay, at: 2010/10/18 16:35

[duncan]

got the elf, many thanks. I will try to install it tonight & post feedback asap.

duncan.

[Carlos Dalla-Fiore]

Hey Ripe, Could you do a Nemo version too?

[john Kimble]

if the Octopus version works out, I can give it a shot.

cheers
ripe

[duncan]

he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it! he’s fixed it!

I’m sat here with a colin-fraser-midi’d tb303 as my master clock & the octopus is staying perfectly in time with it from 50bpm to around 160bpm…. I’m really too tired to be more scientific about this right now, but "early results are encouraging". there’s also a P3 in the rig, & all three are locked together fine now. I reading the bpm from the front of a line-6 echo pro.

BY THE WAY- I forgot this, & wasted half-an-hour, because the genoqs "elf loader" doc hasn’t been adjusted… if you’re using zterm on a mac, you need to go to the files>transfer convert menu & change it to ordinary binary or you’ll get an unknown image response from the octopus.

erm…. anyone want to buy some delay boxes?

duncan. very happy.

[Author]

Posts