Create registermessage struct

[morganpackard]

Add Max and min values.

[ndonald2]

It would be great to also add a "type" enum which among other things would allow automatic creation of UI elements based on the control type:

• Continuous - the default
• Stepped, with interval - e.g. rounded to only integers
• Toggle/switch - toggle between 0 and 1
• Momentary - while held down it's 1, when released it's 0
• Trigger - touch down sends instantaneous message, touch up does nothing
• Others?

[morganpackard]

and the type would be set via an additional argument to addParameter?

On Wed, Feb 27, 2013 at 9:04 PM, Nick D. notifications@github.com wrote:

It would be great to also add a "type" enum which among other things would allow automatic creation of UI elements based on the control type:

• Continuous - the default
• Stepped, with interval - e.g. rounded to only integers
• Toggle/switch - toggle between 0 and 1
• Momentary - while held down it's 1, when released it's 0
• Trigger - touch down sends instantaneous message, touch up does nothing
• Others?

— Reply to this email directly or view it on GitHubhttps://github.com/morganpackard/Tonic/issues/21#issuecomment-14212480 .

Morgan Packard cell: (720) 891-0122 aim: mpackardatwork twitter: @morganpackard

[ndonald2]

Yeah, exactly. Maybe two signatures:

// This one creates a continuous parameter (the default). Optional min/max
void addParameter( string name, TonicFloat defaultValue, TonicFloat min = -FLT_MAX, TonicFloat max = FLT_MAX );

// This one creates a parameter of a specified type
// Only "stepped" or "incremental" types really care about increment
void addParameter( string name, TonicFloat defaultValue, SynthParamType type, TonicFloat min = -FLT_MAX, TonicFloat max = FLT_MAX, TonicFloat increment = 0 );

I'm also thinking it might be more flexible to have addParameter return the struct itself, so it's more intuitive when adding parameters in the constructor. It makes more sense to have "addParameter" return some type of "parameter" than a ControlValue:

// Example - FM based on integer ratios

// Param struct looks like:

struct SynthParameter{
  ControlValue value;
  SynthParamType type;
  TonicFloat min;
  TonicFloat max;
  TonicFloat increment;
};

// Could do this:
SynthParameter freq = addParameter( "freq", 440, 80, 880 );

// or this:
SynthParameter sync = addParameter( "ratio", 4 );
lowFreq.type = SynthParamTypeStepped;
lowFreq.min = 1;
lowFreq.max = 8;
lowFreq.increment = 1;

ControlValue modFreq = freq.value * ratio.value;

outputGen = SineWave().freq( freq.value + SineWave.freq( modFreq ) * modFreq * 0.1 );

[morganpackard]

Seems to me some of this could be accomplished by chaining ControlGenerators. I was imagining we'd have a quantizing generator that would behave much like your stepped type. I think this area deserves some careful thought and marination. Maybe even put off making any decisions until we've written and played with some more different types of Generators and ControlGenerators. -m-

On Wed, Feb 27, 2013 at 11:06 PM, Nick D. notifications@github.com wrote:

Yeah, exactly. Maybe two signatures:

// This one creates a continuous parameter (the default). Optional min/maxvoid addParameter( string name, TonicFloat defaultValue, TonicFloat min = -FLT_MAX, TonicFloat max = FLT_MAX ); // This one creates a parameter of a specified type// Only "stepped" or "incremental" types really care about incrementvoid addParameter( string name, TonicFloat defaultValue, SynthParamType type, TonicFloat min = -FLT_MAX, TonicFloat max = FLT_MAX, TonicFloat increment = 0 );

I'm also thinking it might be more flexible to have addParameter return the struct itself, so it's more intuitive when adding parameters in the constructor. It makes more sense to have "addParameter" return some type of "parameter" than a ControlValue:

// Example - FM based on integer ratios // Param struct looks like: struct SynthParameter{ ControlValue value; SynthParamType type; TonicFloat min; TonicFloat max; TonicFloat increment;}; // Could do this:SynthParameter freq = addParameter( "freq", 440, 80, 880 ); // or this:SynthParameter sync = addParameter( "ratio", 4 );lowFreq.type = SynthParamTypeStepped;lowFreq.min = 1;lowFreq.max = 8;lowFreq.increment = 1; ControlValue modFreq = freq.value * ratio.value; outputGen = SineWave().freq( freq.value + SineWave.freq( modFreq ) * modFreq * 0.1 );

— Reply to this email directly or view it on GitHubhttps://github.com/morganpackard/Tonic/issues/21#issuecomment-14215747 .

Morgan Packard cell: (720) 891-0122 aim: mpackardatwork twitter: @morganpackard

[ndonald2]

True, a lot of the value-conditioning could be done with ControlGenerators, and a quantizing generator is something I was thinking of too. The "stepped" type is probably the most unnecessary out of all the ones I proposed.

What really intrigues me is the ability to expose all parameters with names, ranges, and types for a particular synth - this could be really cool for auto-generating UI's and possibly (WAY down the road) creating a script to turn Tonic synths into AU's or VST's and automatically registering the input parameters.

Maybe we can archive this one for now, or at least decide on a very simple structure to put in place so we don't have to go regress all the synth subclasses later if we do change the parameter behavior. We could always add more to the parameter struct later.

[morganpackard]

ARRRRGGHHH!!!! Can't focus on work. Just want to build this stuff and play with it! Putting blinders on.

On Thu, Feb 28, 2013 at 10:19 AM, Nick D. notifications@github.com wrote:

True, a lot of the value-conditioning could be done with ControlGenerators, and a quantizing generator is something I was thinking of too. The "stepped" type is probably the most unnecessary out of all the ones I proposed.

What really intrigues me is the ability to expose all parameters with names, ranges, and types for a particular synth - this could be really cool for auto-generating UI's and possibly (WAY down the road) creating a script to turn Tonic synths into AU's or VST's and automatically registering the input parameters.

Maybe we can archive this one for now, or at least decide on a very simple structure to put in place so we don't have to go regress all the synth subclasses later if we do change the parameter behavior. We could always add more to the parameter struct later.

— Reply to this email directly or view it on GitHubhttps://github.com/morganpackard/Tonic/issues/21#issuecomment-14238114 .

Morgan Packard cell: (720) 891-0122 aim: mpackardatwork twitter: @morganpackard

[ndonald2]

Basic struct implemented for now. Can be extended later.