On Sat, Dec 6, 2014 at 7:08 PM, Sam Potter
<sfp@xxxxxxx
<mailto:sfp@xxxxxxx>> wrote:
Oh brother!
I guess I should have specified (really??) that the parametrization
I was talking about was just the set of parameters exposed to the
user by the usual ar, kr, etc. methods. Considering just those
parameters, it doesn't make sense to talk about "the running max of
SinOsc".
Considering just those parameters, by your logic, nor does it make sense
to talk about the waveform of SinOsc being a sine wave, since I can set
the freq to zero, the phase to pi/2 and then the waveform becomes
whatever is in the mul input. Or set the mul to zero and then the
waveform is whatever comes in the add input, or set the freq to zero and
apply a waveform to the phase input whose arcsine is what I want the
output to be and then the waveform will be that.
On 12/06/2014 09:22 PM, James McCartney wrote:
Then all documentation would be useless. By your criteria, the
documentation of SinOsc should not even say it outputs a sine wave,
because it could be parameterized to output any arbitrary waveform.
On Sat, Dec 6, 2014 at 5:34 PM, Sam Potter
<sfp@xxxxxxx
<mailto:sfp@xxxxxxx>
<mailto:sfp@xxxxxxx
<mailto:sfp@xxxxxxx>>> wrote:
thanks kindly julian, you are the eternal diplomat, i'm
ashamed.
i wonder though, could we say "The peak amplitude of
SinOsc is one",
or would that too need a qualification?
{SinOsc.ar(SinOsc.ar(50))}.____plot(0.1)
i think the mistake here is clear, we can always turn
back in the
foothills...
best,
rd
The mistake is in assuming that it makes sense to talk
about "the
peak amplitude of SinOsc". "SinOsc" doesn't have a single peak
amplitude -- it's a class which represents an interface to
a table
look-up oscillator which has parameters which have to be
set before
it does anything well-defined. In other words, if you compose
RunningMax (or whatever) and SinOsc, you know nothing about
that
composition's output until you parametrize it.
I guess you could talk about the set of peak amplitudes of
SinOsc,
but I don't see that as being a good thing to include in the
documentation.
___________________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/____research/sc_mailing_lists.____shtml
<http://www.beast.bham.ac.uk/__research/sc_mailing_lists.__shtml>
<http://www.beast.bham.ac.uk/__research/sc_mailing_lists.__shtml
<http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml>>
archive:
https://listarc.bham.ac.uk/____marchives/sc-dev/
<https://listarc.bham.ac.uk/__marchives/sc-dev/>
<https://listarc.bham.ac.__uk/marchives/sc-dev/
<https://listarc.bham.ac.uk/marchives/sc-dev/>>
search:
https://listarc.bham.ac.uk/____lists/sc-dev/search/
<https://listarc.bham.ac.uk/__lists/sc-dev/search/>
<https://listarc.bham.ac.__uk/lists/sc-dev/search/
<https://listarc.bham.ac.uk/lists/sc-dev/search/>>
--
--- james mccartney
_________________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/__research/sc_mailing_lists.__shtml
<http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml>
archive: https://listarc.bham.ac.uk/__marchives/sc-dev/
<https://listarc.bham.ac.uk/marchives/sc-dev/>
search: https://listarc.bham.ac.uk/__lists/sc-dev/search/
<https://listarc.bham.ac.uk/lists/sc-dev/search/>
--
--- james mccartney