Why you should add unlimited CC's right now

The reason for a limited number of CCs is that each CC type is to be represented by its own class (programming-wise). Adding a new CC means adding a new class to the code. While that is possible, it is something that has to be considered very carefully.

Another issue is that each CC takes up space on the screen. All 127 CCs would not even fit on one screen anymore, even if all other parameters were collapsed.

Unlimited CCs would probably require a redesign of the way CCs are handled by Synfire altogether.

Another challenge is that most CCs are not portable across different sounds. Some filter cut-off curve might work for one sound, but not for another. Once you get down to the detail of tweaking CCs to control sound, you are leaving the portable phrases approach and are moving towards production-specific mixing.

I could add another 8, or 16 custom CCs, but that would still not make them portable. Although one can assign meaningful names to CCs A, B, C, D, E (per sound) there's no semantics behind that indexing scheme, no meaning that a different sound could interpret and use (or ignore).

Would it perhaps be helpful to remember the CC name of the sound that was used to originally create a phrase? This would at least document the intention behind a custom parameter.

I definitely +1 the request for additional CC's. Right now my Alesis Andromeda is pretty much out of the question as an external synth for Synfire protoyping because of it. That and the fact that the CCs are only that, 0-127 value generic CCs.

The Andromeda does everything via MSB/LSB controller pairs to avoid awful zipper-stepping on the analog filters and such. It would be fantastic if the Controller class could be configured to bind to an MSB/LSB pair, or a standard 0-127 CC (like generic data slider), etc.

..If they could be bound to a configurable pair, and the controller parameter is a continuous value (0.0 - 1.0) it should be relatively simple to convert that floating-point vector representation to a 14-bit integer, then split that across the MSB/LSB controller pair to be output to the synth.

As it stands, even if you do record a filter or ribbon from the Andromeda, the resulting CC mess cannot be edited at all. You have to basically try to record the controls into controller lanes in a sequencer and sync it all up, it just doesn't work.

Well, I absolutely agree. I think you misunderstood the intention of my previous post. I didn't mean to justify the current CC limit in any way, I just wanted to explain why there aren't any more of them right now and why it will take more in-depth considerations to get this changed and integrated properly.

Me being a developer, in many of my posts I'm just thinking out loud how something could be implemented or why a good solution might be very difficult to achieve ;-)

During past development, most standard sequencer-like and bare MIDI features received a lower priority in favor of Synfire's specific and unique features around phrase rendering. This is inevitable in order to move the project forward, but it doesn't mean the basic underpinnings are not being considered and improved over time.

The parameter block already has a "scrollbar" (the mouse wheel). However, as it scrolls group-wise, only a limited number of parameters per group can be visible on screen. I'll check if line-wise scrolling is an option.

Per-project CC mappings seem like a cool idea.

Doing the whole CC thing right requires a major redesign of the underpinnings. The current model is not configurable enough.

EDIT: Created AR1015.

Not even pitch bend is portable. How could filter cut-off and such ever be?

Velocity isn't actually portable either.

Cognitone is certainly not in the position to propose a universal industry standard that yould make everything beyond note pitch, volume, pan and sustain pedal portable across sounds. I doubt anyone in the industry would be interested. Hey, MIDI is still 1980.

If someone went through the effort of creating response curves for velocity, pitch bend and the various more frequently used CCs for each sound in existence, we could add that feature to device descriptions and use a value range of -1.0 ... 1.0 for all parameters.

This reminds me of the idea of an audio-based automatic device description calibration tool. I still think that would be very cool.

Why not extend the idea of the Device Description concept into a Controller Description editor? The way I can envision this idea would be very similar to what is already in place, yet optionally assignable to instruments, and at least portable across our own "studio" setups (I feel that this aspect is the whole crux of these issues.)

This is a very crude mockup of how it could be arranged:

You could have a tree-like setup like the device descriptions, broken down into a number of different categories such as:

Filters:
- cutoff
- resonance
- offset
- spread
- mix level
- envelope level/amount
- data increment (maybe for changing filter types?)
- data decrement

Envelopes:
...with customizable preset groupings such as...
ADSR:
- attack
- decay
- sustain
- release
ASR:
- attack
- sustain
- release
AHDR:
- attack
- hold
- decay
- release
AR:
- attack
- release
...and finally, customizable envelope types eg:
Custom/User:
- attack
- decay1
- decay2
- sustain
- release1
- release2
ala: Alesis Andromeda
(maybe, even a "user customizable" 1-6 or 1-8 segment env...)

...however, I think that at least 6 customizable envelope breakpoints should be available...

Repeat this concept for multiple filters and envelopes (filter env., pitch env., modulation env., generic/user env., etc.) You should be able to add a number of these and label them in the cases where your device has 2 or 3 filters, or 2 customizable mod envelopes, etc., no pitch envelope, etc.

You would obviously expand the tree further..

LFOs:
- rate/speed
- amount
- offset (bi-directional maybe?)
- (maybe data increment/decrement for type switching again?)

...obviously multiple configured LFOs allowed, at least 3-6...

FX:
Reverb:
- amount
- level
- wet/dry
- etc.
Chorus:
- amount
- level
- wet/dry
- etc.

...repeat for common FX, EQs, Phaser, Distortion, etc.

MISC./OTHER:
Ribbon:
- ribbon
..or..
- ribbon (left)
- ribbon (right)
Sample&Hold:
- rate/speed
- level
Unison:
- on/off
- voices
- detune/spread
Mono:/Poly
- on/off

(I'll stop here on the controller list. It probably isn't necessary to list all possibilities at this point.) :)

Upon selecting a controller group in the editor, you should be able to select from a controller type, such as:

- Standard 7-bit CC
- 14-bit MSB/LSB pair
- ON/OFF (like sustain 0-63=off, 64-127=on, or maybe some other customizable range of values...)
- ...and configurable system-specific NRPN/RPN formats, like the Andromeda (this is a good keyboard example, because it has nearly 1,000 MIDI NRPN and Sysex configurable parameters.)
- CC99 NRPN select (MSB) / CC98 NRPN select (LSB) -> CC6 NRPN value (MSB) CC38 NRPN value (LSB)
- (RPNs are a bit more hairy because its typcially just for pitch bend sensitivity setting and shares CC6/38 with NRPN controllers..kind of steps on the other controllers...lame)
- Maybe even SysEx controller options could be available...

NRPN controllers would typically be CC99/98 setup and potentially a -/+ range for values to be mapped to, a uni/bi-directional flag, and maybe an optional default value/offset instead of 0.0, with the actual parameter values being split across CC6/CC38 according to the description.

An example for the Andromeda using the above to control LFO1 rate would be with a pair in the form (in decimal):
CC99=8 CC98=10 and CC6 and CC38 controlling the actual parameter. (I would have to consult more documentation to get the actual specifics, that isn't really necessary for discussion.)

I can think of a few soft synths that also use NRPNs for their business; and if these configurations could be exported and imported, once sets of parameters for a specific soft/hard synth are setup, they could be individually exported and shared/merged into our own device/controller setups.

Just have the user type in the specifics for the controller pairs or select from common drop-down, if you are mapping something like the reserved General Purpose 1-4 controllers reserved by MIDI spec.

A MIDI learn button inside the editor would be great. Say if you were configuring an NRPN controller pair, just click "Learn..", adjust the parameter, and set the range...it could also have a "learn buffer" that records the lowest and highest values of the learned parameter change and offers that as the clamp values, if they are undocumented or hard to access.

You could expand some of this controller logic to have linear and log curves, or even a sigmoid S-curve if you wanted to get really specific. In any case, the controllers would be continuous values 0.0 to 1.0 or maybe even bidirectional -1.0 to +1.0 (like pitch bend for example) and would be mapped to the destination controller value through the appropriate transfer function.. For pitch bend, you could have a configurable pitch-bend range controller as per whatever your device recognizes for setting that range...ditto for portamento.

It might even be worthwhile to have a global/local controller flag in the editor to be able to have controllers not tied to a particular instrument, and rather operate on an FX rack or something and could be assigned to the top-level container only(?) This is all more or less taking everything up a level...

I guess my primary thinking in this is that a controller's level/value shouldn't necessarily be tied to the specifics of the controller or world-at-large :) and should be a bit more abstract. Then you could copy and paste controller spans and operate on them with the vector tools like anything else and it would just work. :)

Additionally, this would all be very valuable once the synthesis engine in Synfire comes to fruition too. It would be awesome to apply fractional brownian noise, L-system, Lorenz attractors, and other operations on controller vectors.

[If you don't read this whole thing, here is the short version...]

>>> Being able to configure and group controllers would extend the concept of intelligent device mapping to controllers, at least up to the point of potentially giving the user an option to choose from a similar controller in the case of major discrepancies, or ignore/mute a controller altogether. This would function almost the same was as resolving instrument discrepancies when opening a project where you have a different piano sound on a device; but it is still a piano sound, so it is used instead... same way with filter cutoff controllers...NRPN 14-bit value on one keyboard, 7-bit general-purpose CC on another...same controller description group...similar sound effect...same portable parameter values in your project...it would just work (in theory!) <<<
:yeah:

This would all be a HUGE win compared to what is already out there with other DAWs. I don't even think this sort of mapping approach is even done out there; not with the sound mapping (things like Logic's library groups are close, but not really the same) and certainly not with controllers... A huge Win/Win situation for sure, and most certainly would be like advancing a level in the direction that the music prototyping idea is already moving.

P.S. Edited a few specifics. I think that is the end of my unstructured morning rambling. :)

I guess I should add that it would probably be useful to be able to disable or mute controllers in the case where you just want to be concerned with the actual phrase/figure copying.

Or maybe additionally some sort of easily accessible on/off checkbox in the library that says "copy inherited controllers" ...something like that.. so saved specific controllers don't overwrite existing controller data.

Example: you have a synth pad with a filter sweep drawn in a controller lane on the instrument and want to experiment with a few phrases. With the box unchecked, dragging out figures from a library would preserve the filter sweep, but replace the figure.

You can drag the Figure parameter from the library alone. This works with many standard parameters.

That would work then in that particular case. :)
"Controller muting" would probably still be useful in some instances!

OMG Keith, that hurt my tiny brain!!

OMG Keith, that hurt my tiny brain!!

lol.. sorry :)

It's a long-winded technical description of an idea to implement more customizable controllers, similar to how the device description works for selecting similar sounds/patches..only grouping controller descriptions into a categorized tree, and selecting from that tree compatible controllers in the event you are sending a similar controller to different devices.

The MIDI stuff is really disgusting, but basically the way it works is there are 2 specific message values that can be sent to select a custom controllable parameter (depending on the hardware or software synth vendor) and 2 values (which can be combined to form a larger number..better resolution) to actually change the parameter.

It basically extends the parameters in normal MIDI control messages to address up to (if I remember correctly) slightly more than 16,000 possible parameters and values, most of which are system specific. This is over the normal range of a controller, which is 127. (System Exclusive messages can use even larger values than 16,000 of course, because they are not limited in scope nearly as much.)