Skip to main content

Why you should add unlimited CC's right now

Posted

I think waiting on adding the capability of using more cc's is a really really bad idea.

As it is I am currently misusing all of the available cc controllers in order to control synths... In other words, I am using the sustain and portamento to do things like filter cutoffs and ADSR sustain. Synfire has no idea what those parameters are doing... In three months, when pulling them out of my library, neither will I.

This is ruining any phrase libraries by filling transferable parameters with junk that doesn't relate to anything but that specific instruments needs at the moment of creation.

Eventually it will make the phrase libraries I am building now obsolete, especially if more cc's are added and they are implemented in an intelligent manner so that the naming determines the routing.

In other words, if a phrase was created on an instrument where the filter cutoff was cc22, was dragged on to a different instrument it would be able to find the closest match to the control... Perhaps the target synth didn't have a cutoff at all, the parameter might map to a tone control instead.

As it is, its likely that the cutoff is stuck on the sustain pedal, and reusing the phrase on a synth that responds to the sustain pedal automatically... well its not good.

I know, initially the idea was that you would prototype in synfire, and then move the project to a DAW as a midifile for tweaking.

From a professional standpoint that approach is totally unreasonable. Not only does it take way too much time from a real production schedule, but if musical revisions are required back in synfire, all the sequencer tweaking will be lost, or require a slow painful process of manual reintegration of the changes into the tweaked daw data.

If there is a real reason why the limit of cc's is 4 please explain.


Mon, 2010-03-08 - 22:26 Permalink

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.

Mon, 2010-03-08 - 23:23 Permalink

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.

Mon, 2010-03-08 - 23:33 Permalink

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.

Alright then, what makes the synfire method different than every other daw that does support the full spectrum cc's? If there is a technical difference, would it be possible to provide axillary cc's to fill in the gaps (these auxiliary cc's would function as a normal daw's cc's would and wouldn't have the benefit of whatever technology synfire uses that puts the reasonable limit at 4. I would be willing to give up morphing, or let them only exist in the root container with no inheritance if that's what must be...

As far as the parameter bar fitting on the screen. Others have commented that this is a bad design. Its a design that can be easily amended with a scroll bar. It is hardly a valid reason to limit the number of cc's a project independent global instrument can use to four.

I don't suppose there has ever been a sequencer with a 4 cc limit. It is an entirely radical idea. I would hope there would be a more substantial reason than -- we don't have a scroll bar.

Considering that CC's are assigned to Instruments, it is not even possible to choose the 4 essential CC's that would suit the needs of a specific project. Instead they are persistent throughout all projects and changing them would break all previous projects.

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.

In case you are rather thinking of the customizable sound CCs (as opposed to the static parameters like Breath, Volume, Pan), I could add another 8, 16 or even more, but that would still not make them portable.

Although one can assign meaningful names to CCs A, B, C, D, E, ... there's no semantics behind that indexing scheme, no meaning that a different sound could interret and use (or ignore)

That there isn't even a remedial indexing scheme, is a huge crux in your idea behind reusable phrases. To my mind its is essential. But to be fair, the whole concept of a library is exotic and your approach is unique and perhaps such a thing would be difficult to develop. I don't enough about it to say.

I think you should see if your customers agree with you in that very uncommon and quixotic point of view.

What is not exotic, is having access to all cc's.

-- no user should be allowed more than 4 cc's for an instrument across all projects, despite a diverse range of styles, applications and needs --

I don't mean to be bitchy, but I feel that if I don't spell it out the point will be missed.

To start, there are many parameters involved in synthesis and sampling that relate directly and exactly to the musical composition and structure of a piece. An lfo can impart and entirely different rhythm... Performed breath control can reshape the phrasing of a line to completely reorient its meaning, changing the sample start point of a sampler can move you from a Brahms tutti to Madonna...

It is perfectly fine if you don't acknowledge that fact, but to enforce your point of view on paying customers with diverse needs is a little odd. In any event it is not compatible with the needs of a professional composition work flow which is the guise that you have justified the high cost of the software.

Strange, that you are worried about the accuracy of how the filter cutoff will map when you go to such lengths to stress the importance of broad strokes thinking and composition. If the essence and character of a filter sweep is maintained to some degree in transferring a phrase to a new instrument, it is easy enough to use Synfires excellent cc tools to adjust it to taste.

Isn't it the backbone concept of your software that, it is the the SHAPE and RHYTHM that are essential? What does that thinking apply only to discrete elements (note events) and why do you feel compelled to enforce that point of view?

Tue, 2010-03-09 - 14:17 Permalink

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.

Tue, 2010-03-09 - 14:46 Permalink

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.

Tue, 2010-03-09 - 18:23 Permalink

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. :)

Tue, 2010-03-09 - 18:33 Permalink

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.

Tue, 2010-03-09 - 19:08 Permalink

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

Tue, 2010-03-09 - 19:10 Permalink

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

Tue, 2010-03-09 - 23:22 Permalink

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.)