Chris Henkel

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • in reply to: Automating Filter Cutoff #3000
    Chris Henkel

    …this one might also give some hints – especially in regard to drawing values into the Octopus-display:

    in reply to: Community Collaboration? #2977
    Chris Henkel

    Dayflight-Trok wrote:

    What do you think?

    …i think you just volunteered :whistle: …

    …i am in – but i also recommend setting a deadline at least…

    in reply to: multiple h/w sequencers & timing #2957
    Chris Henkel

    duncandisorderly wrote:

    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

    in reply to: multiple h/w sequencers & timing #2947
    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

    —-end of solution—-

    …best wishes,

    in reply to: Community Collaboration? #2950
    Chris Henkel

    summa_riot wrote:

    It seems a shame that this thread has over 200 views and only 2 people were interested enough to respond.

    …the slow response might be connected to the fact that the Octopus in itself does not produce any sound…so one would have to look for another feature, that would use Octopus capabilities that could set this compilation apart from some other random musical compilations…

    …another fact might be that the idea is still a little vague – so, a next step might be to draw up a set of compilation-rules & -timelines…obviously there would be a few people interested in such an enterprise, and for a compilation you’d initially only need 7-9…depending on how big this should become there could be more contributors included…

    …dont give up yet…B)

    Post edited by: fairplay, at: 2010/10/11 17:28

    in reply to: Working on Octopus reference manual. Interested? #2801
    Chris Henkel

    …just to let you know that i am following your idea closely and that i am looking forward to what you will provide…

    …thank you for your effort!…

    in reply to: Community Collaboration? #2940
    Chris Henkel

    …somehow i had overlooked this thread…

    …as i have participated in a couple of compilations yet, it usually is organised by one individual, who sets the conditions, a time-frame and either offers a Dropbox – like the one on – or asks for notification via email where to download the track (so the contributor has to provide some web- or ftp-space to upload)…

    …anyone out there willing to head the Octopus-Compilation?…

    in reply to: multiple h/w sequencers & timing #2936
    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…

    in reply to: …’stoblue’ & ‘blueuced’*… #2694
    Chris Henkel

    …page 107, paragraph •CPY and PST:

    bool should most probably be pool

    in reply to: …’stoblue’ & ‘blueuced’*… #2693
    Chris Henkel

    …page 102 – the Octopus EFF Overview graphic:

    – indicated colour green for Feed should be orange (i guess)
    – indicated colour red for Feed should be blue (i guess)

    in reply to: …’stoblue’ & ‘blueuced’*… #2692
    Chris Henkel

    …ok, so let’s collect a few other things in this thread so they might eventually be corrected in a future manual-version…

    …especially as i already forgot a couple of things again…

    – very minor thing: page 115 second sentence talks about the Nemo (in the Octopus manual); the next paragraph then includes both machines again…

Viewing 11 posts - 1 through 11 (of 11 total)