November 22, 2008 at 18:35 #894
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:44November 23, 2008 at 11:42 #2114
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?
RobertNovember 23, 2008 at 13:27 #2115
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…November 23, 2008 at 21:19 #2116
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.
WilsonNovember 24, 2008 at 09:38 #2117
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.November 24, 2008 at 13:15 #2121
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
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.
WilsonNovember 24, 2008 at 16:25 #2123
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!November 24, 2008 at 18:24 #2124MikeParticipant
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
Post edited by: ripe, at: 2008/11/24 19:26March 14, 2009 at 03:27 #2125
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.
GabrielMarch 14, 2009 at 06:22 #2306
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.
- You must be logged in to reply to this topic.