Thanks Julian, I've committed the fix for this (rev 6807). The UGen
behaves exactly the same, but is more more efficient with k-rate
coefficients. Will next look at fixing the a-to-k issue...
Dan
2007/12/14, Julian Rohrhuber <rohrhuber@xxxxxxxxxxxxxx>:
> yes, this is incorrect.
>
> >In fact Julian's code for k-rate modulation (Amplitude_next_kk) looks
> >wrong to me. This bit:
> >
> >if(ZIN0(1) != unit->m_clamp_in) {
> > clampcoef = exp(log1/(ZIN0(1) * SAMPLERATE));
> > unit->m_clamp_in = clampcoef;
> >} else {
> > clampcoef = unit->m_clamp_in;
> >}
> >
> >should be
> >
> >if(ZIN0(1) != unit->m_clamp_in) {
> > clampcoef = unit->m_clampcoef = exp(log1/(ZIN0(1) * SAMPLERATE));
> > unit->m_clamp_in = ZIN0(1);
> >} else {
> > clampcoef = unit->m_clampcoef;
> >}
> >
> >The same goes for the "relax" input.
> >
> >Julian, please correct me if I'm wrong, but it looks to me like you've
> >conflated the clamp-input and clamp-coefficient variables. The UGen
> >works correctly but is not as optimal as you intended, because the
> >recalculation of the coefficient would still happen once every control
> >period.
> >
> >I'll fix this later (and do the a-rate calc func too); let me know if
> >I've got this right or not...
> >
> >Dan
> >
> >
> >
> >2007/12/14, Dan Stowell <danstowell@xxxxxxxxx>:
> >> A while ago Julian reworked the Amplitude UGen slightly to allow the
> >> coefficients to be modulated. Julian, you left some old calc-func code
> >> in there, deactivated using some "#if" macros. Is it OK to remove the
> >> old code? Would make it easier to work on fixing the current code...
> >>
> >> Dan
> >>
> >>
> >> 2007/12/13, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
> >> > I think option 1 makes sense. Pitch.kr can take an audio
input, so it
> >> > makes sense (to me at least) that Amplitude should be able to also.
> >> >
> >> > Josh
> >> >
> >> > On Dec 13, 2007, at 1:50 PM, Dan Stowell wrote:
> >> >
> >> > > Hi all,
> >> > >
> >> > > Applying Amplitude.kr to an audio-rate signal is
allowed, in fact all
> >> > > the examples in the helpfile do this. However, I noticed
that the UGen
> >> > > doesn't really handle this case "correctly" - if run at
control-rate
> >> > > it simply expects its input to be control rate; the end result on
> >> > > audio-rate input is a dodgy downsampling which can lead
to incorrect
> >> > > results.
> >> > >
> >> > > For example, these two should really give similar results but they
> >> > > don't (give them a few seconds to converge):
> >> > >
> >> > > x = {(Amplitude.kr(Impulse.ar(44100/64, 0.0),1,1)).poll}.play // 1
> >> > > x = {(Amplitude.kr(Impulse.ar(44100/64,
0.02),1,1)).poll}.play // 0
> >> > >
> >> > > Same goes for these:
> >> > >
> >> > > x = {(Amplitude.kr(SinOsc.ar(44100/64,
0.0),1,1)).poll}.play // 0.098
> >> > > x = {(Amplitude.kr(SinOsc.ar(44100/64,
pi/4),1,1)).poll}.play // 0.77
> >> > >
> >> > > Options for fixing this:
> >> > >
> >> > > (1) Alter the UGen source, add a new calc func to deal
with the a-to-k
> >> > > (2) Make Amplitude a subclass of Filter, so it refuses
to run k-rate
> >> > > on an a-rate input (unhelpful!)
> >> > > (3) Alter the Amplitude class so it automatically replaces
> >> > > Amplitude.kr(x.ar) with A2K.kr(Amplitude.ar(x.ar))
> >> > >
> >> > > Any particular thoughts?
> >> > >
> >> > > Dan
> >> > >
> >> > > --
> >> > > http://www.mcld.co.uk
> >> > > _______________________________________________
> >> > > Sc-devel mailing list
> >> > > Sc-devel@xxxxxxxxxxxxxxx
> >> >
> >> > ******************************************
> >> > /* Joshua D. Parmenter
> >> > http://www.realizedsound.net/josh/
> >> >
> >> > "Every composer - at all times and in all cases - gives his own
> >> > interpretation of how modern society is structured: whether actively
> >> > or passively, consciously or unconsciously, he makes choices in this
> >> > regard. He may be conservative or he may subject himself
to continual
> >> > renewal; or he may strive for a revolutionary, historical or social
> >> > palingenesis." - Luigi Nono
> >> > */
> >> >
> >> >
> >> > _______________________________________________
> >> > Sc-devel mailing list
> >> > Sc-devel@xxxxxxxxxxxxxxx
> >> > http://www.create.ucsb.edu/mailman/listinfo/sc-devel
> >> >
> >>
> >>
> >> --
> >> http://www.mcld.co.uk
> >>
> >
> >
> >--
> >http://www.mcld.co.uk
> >
> >_______________________________________________
> >Sc-devel mailing list
> >Sc-devel@xxxxxxxxxxxxxxx
> >http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
>
> --
>
>
>
>
>
> .
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
--
http://www.mcld.co.uk