UGEN dev: Best practice for numerous SETCALC

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

UGEN dev: Best practice for numerous SETCALC

Pierre Alexandre Tremblay
Dear all

As a way to remember how things work, and to really understand the idiosyncrasies of each dsp implementations, I’m porting my little Max externs to SuperCollider (butt~ and ipoke~). It should be fun.

At the moment, I’m in need of street wisdom. Butt~ is a dirty filter which has 5 inputs: audio, freq, bandwidth, dirt, filter_type

Now if I do the permutations of different types (scalar, control, audio) of the last 4 for an audio input I get a LOT of different CALC routines…. Not that I’m lazy, but you know, there is a finite amount of hours in a day ;-)

So I wonder what is your favourite option between code optimisation and code maintenance optimisation. For instance, having a fork between scalar and control inside the control routine? What I would like here, without starting a war of optimisation ethics, is what the SC community is used to, and maybe a link to a filter that deals with audio rate change of freq (the code of RLPF_next does not as far as I can read it)… or maybe I should never accept filter param change per sample?

Any pointers welcome.

Pa
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: UGEN dev: Best practice for numerous SETCALC

julian.rohrhuber

> On 04.12.2017, at 16:50, [hidden email] wrote:
>
> Dear all
>
> As a way to remember how things work, and to really understand the idiosyncrasies of each dsp implementations, I’m porting my little Max externs to SuperCollider (butt~ and ipoke~). It should be fun.
>
> At the moment, I’m in need of street wisdom. Butt~ is a dirty filter which has 5 inputs: audio, freq, bandwidth, dirt, filter_type
>
> Now if I do the permutations of different types (scalar, control, audio) of the last 4 for an audio input I get a LOT of different CALC routines…. Not that I’m lazy, but you know, there is a finite amount of hours in a day ;-)
>
> So I wonder what is your favourite option between code optimisation and code maintenance optimisation. For instance, having a fork between scalar and control inside the control routine? What I would like here, without starting a war of optimisation ethics, is what the SC community is used to, and maybe a link to a filter that deals with audio rate change of freq (the code of RLPF_next does not as far as I can read it)… or maybe I should never accept filter param change per sample?

What we usually do is to have one version that is all control rate, and one version that is all audio rate (only omitting those arguments where it really doesn’t make sense), and then take most expected cases and implement them.

For the last you should consider which inputs benefit from automatic interpolation - for these you want a control rate version.

So if your inputs are: audio, freq, bandwidth, dirt, filter_type

You’d probably need

kr, kr, kr, kr, kr
ar, kr, kr, kr, kr
ar, ar, kr, kr, kr

If your algorithm supports audio rate in all parameters, then, maybe

ar, ar, ar, ar, ar, kr

I don’t know what dirt is.

You may want to check for the idiomatic argument names. The argument name “audio” should probably be replaced by “in” (it need not be an audio signal).

Usually, we use 1/Q (rq) instead for Q for bandwidth, because that usually saves a division.

Hope this helps!
















signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UGEN dev: Best practice for numerous SETCALC

Pierre Alexandre Tremblay
Dear Julian

Thanks for this, it definitely makes sense. I am curious about the automatic interpolation you refer to though: is SC making a linear interp if provided a kr in an ar input? Is it UGEN dependant?

p
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: UGEN dev: Best practice for numerous SETCALC

Pierre Alexandre Tremblay
In reply to this post by julian.rohrhuber
OK replies to self, since maybe someone will not know like me (I should re-read the SC book)

The SC interpolation of KR is implemented in each UGEN however the developer care to. The RLPF code was helpful to understand that filters are not audio rate change for real (i.e. you cannot change the freq within a block discreetly), but will sample the KR values at each block and interpolate linearly the coefficients if freq or res have changed.

Please correct me if I’m wrong.

p
_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: UGEN dev: Best practice for numerous SETCALC

julian.rohrhuber

> On 06.12.2017, at 11:33, [hidden email] wrote:
>
> OK replies to self, since maybe someone will not know like me (I should re-read the SC book)
>
> The SC interpolation of KR is implemented in each UGEN however the developer care to. The RLPF code was helpful to understand that filters are not audio rate change for real (i.e. you cannot change the freq within a block discreetly), but will sample the KR values at each block and interpolate linearly the coefficients if freq or res have changed.
>
> Please correct me if I’m wrong.


It is up to you for which of the arguments you want to support audio rate modulation. Some filter algorithms blow up when they are modulated too quickly. But if it is possible, it it is definitely better to have it. A good example are the freq and phase arguments of SinOsc, which can all be modulated at audio rate.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UGEN dev: Best practice for numerous SETCALC

Pierre Alexandre Tremblay
Thanks so much - I will read this code carefully!

> On 7 Dec 2017, at 10:28, [hidden email] wrote:
>
>
>> On 06.12.2017, at 11:33, [hidden email] wrote:
>>
>> OK replies to self, since maybe someone will not know like me (I should re-read the SC book)
>>
>> The SC interpolation of KR is implemented in each UGEN however the developer care to. The RLPF code was helpful to understand that filters are not audio rate change for real (i.e. you cannot change the freq within a block discreetly), but will sample the KR values at each block and interpolate linearly the coefficients if freq or res have changed.
>>
>> Please correct me if I’m wrong.
>
>
> It is up to you for which of the arguments you want to support audio rate modulation. Some filter algorithms blow up when they are modulated too quickly. But if it is possible, it it is definitely better to have it. A good example are the freq and phase arguments of SinOsc, which can all be modulated at audio rate.


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/