Record simultanious mcc data per page track

[gseher]

I’d like to be able to record simultaniously multiple tracks of mcc data within the recording page track.

For example problems occur when using X/Y pad or joystick controllers that are scrambled as 1 mcc track is autosensed and trying to lock on but mixes up when 2 or more messages are inbound (this is also problematic when synths like the moog little phatty handle midi spec 14 bit msg’s by sending mcc data with a pair of tracks.)

Also, I feel the great convienience and strong memory map layout of the octopus’s hierarchical page->tracks->steps(all midi data) data management is somewhat comprimised when a new page tracks must be reserved only to hold the surplus mcc data.

I like to imagine the page track view as containing all of the musical data notes, vel … mcc without using up page tracks for mcc. Otherwise for myself anyway if I had some tracks with mcc others notes …etc..I would quickly lose track of where and what track modified what …more mcc data more potential confusion and less space for musical note data.(particulary for a live scenerio the simpler the better).

I mentioned this in another post so apologies for repeating myself, but I thought I’d mention it here and see what others and of course what Gabriel thinks.

If I may suggest one possible scenerio…

The idea would be to have 10 mcc datatracks pertaining to a single page track.
This would work by using the familar Octopus matrix track selector method. When zoomed into a tracks mcc map mode the 10 track selector buttons would be the functional means to access the given mcc datatracks.

Viewing/Editing

The 10 mcc datatracks info LED

green LED : Indicates the mcc datatrack is bound(autosensed) and contains and data
orange LED: Is bound but no data
red LED : no mcc binding

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

Recording and mcc Binding

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

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

The CLR (once) would clear the selected mcc datatracks data CLR(twice) clear mcc# binding.

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

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

Cheers,

Wilson

[gseher]

Yes good point,I keep finding myself having to edit cc
data in cubase,as using another track or page will get really confusing as to what is controlling what.
X/Y pad is a good example,but also normal cutoff/
Resonance/Decay playoff.
And well done Wilson for explaining a possible structure for doing this.

[Author]

Posts