Handling 14bit midi on the Octopus

[gseher]

Hi All,

I need clarification on the section of the manual under MIDI Controller stream recording (Considerations) That states 1 track 1 CC. My Moog sends 14bit messages that use an additional cc such as the mod cc 1 and cc33. I am watching the visual cc map input as I record and can see the curve representing the input has noisey ‘spikes’ overwriting the input as if cc33 overlaid ontp cc 1. How does the Octopus handle 14bit data and at worst can I filter out the addition 7bits(cc33)?

Many thanks

Wilson

Post edited by: pushtin_cat, at: 2008/04/11 18:44

[gseher]

Hi Wilson,

Interesting point.

It seems the issue is not the 14 bit resolution, but rather, if I understand you correctly, that you have 2 incoming MIDI CC streams "at the same time". Is that correct for an assumption? Is that some sort of output from the touch pad of the voyager, or how is it generated?

Octopus is able to record 14 bits resolution for the controllers that need it, btw. but it knows when it needs 14 bits and when 7 will suffice, according to the MIDI spec.

Anyway – if you are trying to record this kind of stuff, I may have to think of a way to not make the tracks lock to the auto-sensed CC coming in. That’s good in some cases and not others. Maybe allow CC auto-sense only if one track is set to record, as opposed to more than one?

In that case you could set more than one track to record, lock in their CCs, and the input would get filtered across the tracks, recording your touch pad movement accurately. This can of course be extended to up to 10 tracks in a page.

What do others think?

Let me know some more details.
Cheers,

Gabriel

[gseher]

Thanks Gabriel,

Absolutely, it is intuative to be able to record multple tracks simultaniously. If I may suggest one possible scenerio that will multiply the amount of data across the board:evil: The idea would be to have 10 cc subtracks pertaining to a single track.
This would work by using the familar Octopus matrix track selector method. When zoomed into a tracks cc map mode the 10 track selector buttons would be the functional means to access the given cc subtracks.

===============
Viewing/Editing
===============
The 10 subtracks info LED

green LED : Indicates the cc subtrack is bound and contains an data
orange LED: Is bound but no data
red LED : no cc binding

When viewing/editing a selected cc subtrack the parameter values are graphed and edited in the standard way. cc # id is indicated in the outer circle (same way as tempo readings)

========================
Recording and cc Binding
========================
When recording in standard track mode autosensing would check the 10 cc subtracks against each incomming cc if cc# id is already bound it will overwrite the bound subtracks data otherwise create and new binding and write to the next (if)availible cc subtrack.

When zoomed into cc map mode incomming cc data is shown by the cc subtrack(s) selector LED flashing green.

The CLR (once) would clear the selected cc subtracks data CLR(twice) clear cc# binding.

When in cc map mode the mixer pots are live and helpfuly mapped to the bound cc subtrack that they are associated.

Well thats the idea, I`d be interested to know what you think. It requires more storage, but for me its seem more efficent and intuative to package the cc data within the track.

Cheers,

Wilson

By the way what really makes the Octopus great is the fact that its is a growing project with a great community and excellent support.

Post edited by: pushtin_cat, at: 2008/04/14 13:20

[Author]

Posts