14-bit bender fixed, but not other 14bit mccs

OS_CE Forums Octopus Support 14-bit bender fixed, but not other 14bit mccs

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
  • #894

    Hi all,

    I posted sometime ago regarding a problem I was having with my octopus’s handling of 14 bit midi data. Whilst basking in the brilliant light of v1.60B I thought i’d raise it.

    Briefly, when trying to learn or record mcc controls from instruments transmitting data in 14 bits (7bit pair) the octopus cannot handle them (exp. pitch bend). One instrument I control is the moog LP this transmits smooth 14bit data for bender, mod wheel and filter cutoff. I am unable to either record this mcc data to a track or use a mix map for mixer control. Which is a pity as I would love to centralise all control including mcc data to the Octopus.

    Aside from this, but on the subject of mcc. I’d love to have multiple (10) mcc data tracks stored within each tracks data structure rather than 1 mcc track per track… but thats another story more important is being able to control my gear either by handling 14bit both ways or by filtering it inline.

    Are others finding this a problem or limitation? Could this possibly be a fix for the future;)

    Im loving the phrase editor by the way. A great evolution.



    Post edited by: pushtin_cat, at: 2008/11/22 19:36

    Post edited by: admin, at: 2009/03/14 04:28

    Post edited by: admin, at: 2009/03/14 04:44

    Adam Wilson

    Hi Wilson,

    when working on the latest 14-bit tweaks for the new record modes, I tested this with bender messages from my Clavia G2x, and that worked fine. I’ll check again against the latest OS.

    You’re saying you cannot record the bender messages. You mean you’re getting nothing al all?

    For starters, when arming a track (without recording it), and and having the synth set to LOCAL OFF mode, does the bender info roundtrip correctly through the Octo back into your synth?

    Do you have any other synth you can test this with?


    Adam Wilson

    Just tried recording bender messages with my latest OS version, and it all works fine. I’ll try the latest official OS release next, but I’m suspecting something else is going on here…


    Hi Robert,

    Thanks for your response. Indeed 14bit pitch bend messages do work correctly. Actually pitch bend is the exception in the case of 14 bit mcc sorry for not making that very clear in my post. The trouble I am having in the case of the moog LP is with the filter cutoff and the mod wheels which the LP transmits as 14bits mcc. when in record mode the octopus does not recognise the incomming 7bit msg pair as a 14bit type rather it tries to lock onto them as separate mcc’s. the result is scrambled input when recording and in the case learning the 14bit mcc to a mixer map this does not work at all.

    I was wondering if it is possible to extend the same functionality thats working well for the pitch bend to other 14bit mcc’s.

    many thanks


    Adam Wilson

    Hi Wilson,

    I understand now. You’re probably talking about NRPN messages that use 14-bit data using a pair of CC messages. That stuff simply hasn’t been implemented, it’s not supportet at the moment.

    As a cheap way out, does the LP support normal CCs for mod wheel and filter cutoff? You’ll lose resolution, yes, but at least you can record your tweaks.


    Hey Robert,

    Unfortunately Moog have that on their todo list :( They are a small company with a lone OS coder. In the mean time I will have to live without control of cutoff and add it as one of my hopes for the Octofuture B)

    By the way what do you think about the potential idea of managing (10 mcc data tracks )within the track data structure i know of course spare tracks can be used, but I do not find it an intuitive or efficient workflow. Particularly when handling tracks with lots of mcc param data.
    I did a small conceptual design of how this idea could be realised on the octopus(a truly fascinating read;) ).


    Many thanks sgsin for your help.


    Adam Wilson

    Regarding the support of midi CC subtracks, you’re certainly not the first to make this request, and I certainly see your point, from a usage point of view. Conceptually, a track that records notes as well as a number of different CC messages is easy to grasp.

    BUT… (and this is my personal opinion, not genoQs’), I think the subtrack concept makes the machine too complex, UI wise. It’s yet another zoom level added, and I’m not sure if I’m waiting for that.

    And then there’s the issue of memory. Adding 10 more CC values, or even worse, 10 NRPN messages to each step needs a ton of memory. And while it may be available atm, we could also use that memory for other features, logic, other data structures, etc.

    So I’m not convinced yet, and for the moment prefer to use a number of dedicated tracks in the page for CCs. This also adds to the fun that certain CC tracks can have different speeds, lengths and plackback algos. Way more fun!


    What about the possibility to "separate" the MCC MIDI channel from the note events. On a normal channel they would be the same value, but if you wished, you could re-purpose the unused MCC messages from a track to match the MIDI channel for another track.

    Maybe that was unclear… you could have:

    ___________Note MIDI ch______MCC MIDI ch
    track 9_________1________________5
    track 8_________2________________5
    track 7_________3________________5
    track 6_________4________________5
    track 5_________5________________5
    track 4_________12_______________12
    track 3_________12_______________12
    track 2_________12_______________12
    track 1_________12_______________12
    track 0_________10_______________10


    Post edited by: ripe, at: 2008/11/24 19:26


    From a usability perspective I think this is once again raising the complexity in the sense that now you have to service 2 channels per track. I think the available real estate on Octopus does not necessarily require this.

    Adam Wilson

    I agree with Gabriel.

    It’s very easy to think of some cool feature. It’s very easy to mess up a perfectly fine machine (though with relatively limited functionality) by adding more and more features and make the work flow more and more complex. In the end featurism may actually kill all the fun and the ‘zen’ of the original design. To keep the zen in, we’ll have to very careful as to what feature is added. IMO of course.

    – Robert

Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.