jamoma / jamoma2

A header-only C++ library for building dynamic and reflexive systems with an emphasis on audio and media.
MIT License
30 stars 6 forks source link

Consider generator inputs to add potential for sample accurate start / stop #62

Open nwolek opened 8 years ago

nwolek commented 8 years ago

Idea for this was raised by @tap during the discussion on issue #35. Concept would be for generators (currently Phasor, UnitImpulse, WhiteNoise) to accept an input that controls the starting and stopping of their output.

I've been thinking about this some more since the idea was raised, and the concept is growing on me. One option would be for them to receive a SampleBundle with a mix of zeros and ones that allows you to turn the algorithm on and off. I am imagining a syntax like this for normal operations:

Jamoma::SampleBundle my_control(1, 64); 
my_control.sampleRate = 48000;
my_control.fill(1.0);

Jamoma::Phasor my_phasor;
my_phasor.phase = 0.1;
my_phasor.frequency = -2000.0;

auto out_samples = my_phasor(my_control);
// my_phasor inherits channel, frame and sampleRate from my_control
// results in out_samples filled with values from my_phasor 

my_control.fill(0.0);
auto out_samples = my_phasor(my_control);
// results in out_samples filled with value 0.0

Then since I have a keen interest in a sample accurate start/stop feature, I can imagine some form of control unit generator that alternates between 0.0 and 1.0 to turn the generator on and off within a single SampleBundle. Maybe this is a limitation that we impose: Only generators that have output constrained to zero/one can take no input? All others must have an input SampleBundle like above.

A variation: it could be a mix of zeros and non-zeros, with the non-zeros actually scaling the output like a gain control. This is probably more computationally intense though. I guess it is a question of whether we want to require gain be applied to the output, controlled via input, or both. I would lean toward inputs for start/stop only, therefore restricted to zero/one.

Now that we have several working generators, this is a good time to pause and consider the overall syntax and features we want to have going forward. There is a potential parallel issue in #25, which might be tackled together with this issue in a branch.

I hope all this makes sense. I am tagging this as a question since there is some discussion needed.