multiple h/w sequencers & timing

OS_CE Forums Octopus General multiple h/w sequencers & timing

This topic contains 32 replies, has 8 voices, and was last updated by  duncan 7 years, 6 months ago.

Viewing 15 posts - 1 through 15 (of 33 total)
  • Author
    Posts
  • #1101

    duncan
    Participant

    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.

    #2936

    Chris Henkel
    Participant

    …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…

    #2941

    Carlos Dalla-Fiore
    Participant

    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.

    #2943

    duncan
    Participant

    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.

    #2945

    Carlos Dalla-Fiore
    Participant

    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?

    #2946

    duncan
    Participant

    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.

    #2947

    Chris Henkel
    Participant

    …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

    #2955

    duncan
    Participant

    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.

    #2956

    john Kimble
    Participant

    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

    #2958

    john Kimble
    Participant

    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

    #2957

    Chris Henkel
    Participant

    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

    #2959

    duncan
    Participant

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

    duncan.

    #2960

    Carlos Dalla-Fiore
    Participant

    Hey Ripe, Could you do a Nemo version too?

    #2961

    john Kimble
    Participant

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

    cheers
    ripe

    #2963

    duncan
    Participant

    :-)
    :-)
    :-)
    :-)
    :-)

    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.

Viewing 15 posts - 1 through 15 (of 33 total)

You must be logged in to reply to this topic.