ControlValue doesn't use setter macros

[morganpackard]

Doesn't accept floats

[ndonald2]

@morganpackard I'm not exactly sure what you mean by this one. It does accept floats:

ControlValue & value(TonicFloat value)
{
  gen()->setValue(value);
  return *this;
}

I'm also not convinced that it should use the macros, just because ControlValue is sort of the "end of the line" for ControlGenerators; it's the only ControlGenerator that has a fixed value associated with it, and thus I'm not sure it makes sense to accept other ControlGenerators as inputs (for now anyway).

I think in the future I'd like to try to make the ControlGenerator paradigm more like pd/max where an "atom" of control data doesn't have to just be a float (can also be a list, string, etc), in which case ControlValue might act more like pd/max, where it stores a value by default but can be updated by an input ControlGenerator if the input is triggered.

But for now I think it's probably best to keep it the way it is, where a ControlValue can only be set externally by providing a float. Happy to chat about this if you're thinking something different.

[morganpackard]

There's potential value in having an object that can act as a "socket" that other objects can be plugged in to, and that can be stored in an instance variable. That's what I was trying to do.

All that said, I think I'm going to spend some time getting lambda expressions working as trigger callbacks and playing with those. It's possible that the ability to write code in that style will obviate the need for a lot of the more complicated control generator stuff.

Sent from my iPhone

On Jul 28, 2013, at 11:13 AM, "Nick D." notifications@github.com wrote:

@morganpackard https://github.com/morganpackard I'm not exactly sure what you mean by this one. It does accept floats:

ControlValue & value(TonicFloat value){ gen()->setValue(value); return *this;}

I'm also not convinced that it should use the macros, just because ControlValue is sort of the "end of the line" for ControlGenerators; it's the only ControlGenerator that has a fixed value associated with it, and thus I'm not sure it makes sense to accept other ControlGenerators as inputs (for now anyway).

I think in the future I'd like to try to make the ControlGenerator paradigm more like pd/max where an "atom" of control data doesn't have to just be a float (can also be a list, string, etc), in which case ControlValue might act more like pd/max, where it stores a value by default but can be updated by an input ControlGenerator if the input is triggered.

But for now I think it's probably best to keep it the way it is, where a ControlValue can only be set externally by providing a float. Happy to chat about this if you're thinking something different.

— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/198#issuecomment-21684936 .

[ndonald2]

Yep, the "socket" thing is pretty much exactly how it works in pd/max so I think we are on the same page.

On Jul 28, 2013, at 7:17 PM, Morgan Packard notifications@github.com wrote:

There's potential value in having an object that can act as a "socket" that other objects can be plugged in to, and that can be stored in an instance variable. That's what I was trying to do.

All that said, I think I'm going to spend some time getting lambda expressions working as trigger callbacks and playing with those. It's possible that the ability to write code in that style will obviate the need for a lot of the more complicated control generator stuff.

Sent from my iPhone

On Jul 28, 2013, at 11:13 AM, "Nick D." notifications@github.com wrote:

@morganpackard https://github.com/morganpackard I'm not exactly sure what you mean by this one. It does accept floats:

ControlValue & value(TonicFloat value){ gen()->setValue(value); return *this;}

I'm also not convinced that it should use the macros, just because ControlValue is sort of the "end of the line" for ControlGenerators; it's the only ControlGenerator that has a fixed value associated with it, and thus I'm not sure it makes sense to accept other ControlGenerators as inputs (for now anyway).

I think in the future I'd like to try to make the ControlGenerator paradigm more like pd/max where an "atom" of control data doesn't have to just be a float (can also be a list, string, etc), in which case ControlValue might act more like pd/max, where it stores a value by default but can be updated by an input ControlGenerator if the input is triggered.

But for now I think it's probably best to keep it the way it is, where a ControlValue can only be set externally by providing a float. Happy to chat about this if you're thinking something different.

— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/198#issuecomment-21684936 . — Reply to this email directly or view it on GitHub.

[ndonald2]

Thinking a bit more about this, the setter macros will not work here. If you set another control generator as the value input, then ControlValue needs to tick that generator to get its value. If you set just a float, though, the behavior needs to be different since we don't want to just provide another ControlValue as an input (infinite chain!).

So we can implement the described behavior, but it will fall outside the realm of what the macros are for.

[morganpackard]

Right, totally. Duh!

On Tue, Aug 13, 2013 at 2:42 PM, Nick D. notifications@github.com wrote:

Thinking a bit more about this, the setter macros will not work here. If you set another control generator as the value input, then ControlValueneeds to tick that generator to get its value. If you set just a float, though, the behavior needs to be different since we don't want to just provide another ControlValue as an input (infinite chain!).

So we can implement the described behavior, but it will fall outside the realm of what the macros are for.

— Reply to this email directly or view it on GitHubhttps://github.com/TonicAudio/Tonic/issues/198#issuecomment-22587673 .

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