currently we have lfo(time, level, shape) which is simple wrapper over 2 ASL slopes.
now that audiorate waves are possible with ASL2, it seems likely to want to create simple oscillators in a similar manner. we can of course just use lfo, but the naming is somewhat unintuitive as it is no longer 'low-frequency'.
secondarily, lfo is configured in time, but oscillators are usually thought of in terms of frequency (ie. 1/time).
so i propose adding a new asllib function oscillate(frequency, level,shape). the full oscillate is preferred over osc because it will be a global function, and i worry that a short osc is likely used in existing scripts, and also suggests Open Sound Control which should be avoided.
thoughts? am i perceiving a problem when there isn't one?
eg: oscillator at 100Hz:
-- current
lfo(0.01)
-- current with fraction
lfo(1 / 100)
-- proposed
oscillate(100)
Just typing this out i have a feeling it's overkill & unnecessary. should it be oscillator? is this likely to cause global namespace clashes with scripts?
tehn
commented
3 years ago
currently we have
lfo(time, level, shape)which is simple wrapper over 2 ASL slopes.now that audiorate waves are possible with ASL2, it seems likely to want to create simple oscillators in a similar manner. we can of course just use
lfo, but the naming is somewhat unintuitive as it is no longer 'low-frequency'.secondarily,
lfois configured intime, but oscillators are usually thought of in terms of frequency (ie.1/time).so i propose adding a new asllib function
oscillate(frequency, level,shape). the fulloscillateis preferred overoscbecause it will be a global function, and i worry that a shortoscis likely used in existing scripts, and also suggests Open Sound Control which should be avoided.thoughts? am i perceiving a problem when there isn't one?
eg: oscillator at 100Hz:
Just typing this out i have a feeling it's overkill & unnecessary. should it be
oscillator? is this likely to cause global namespace clashes with scripts?