Quantcast

Why the "add" arg?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why the "add" arg?

amindfv
Stylistic question: I've been reading some sclang tutorials recently and everyone seems to prefer the style of e.g.

SinOsc.ar(440, 0, 0, 1)

to

SinOsc.ar(440) + 1

Why is that? If you don't remember all the arguments, for example, the second is much easier to read.

Is it a holdover from the days where the latter wasn't turned into a MulAdd?

Tom

_______________________________________________
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
|  
Report Content as Inappropriate

Re: Why the "add" arg?

Julian Rohrhuber-3

> On 08.02.2017, at 05:17, [hidden email] wrote:
>
> Stylistic question: I've been reading some sclang tutorials recently and everyone seems to prefer the style of e.g.
>
> SinOsc.ar(440, 0, 0, 1)
>
> to
>
> SinOsc.ar(440) + 1
>
> Why is that? If you don't remember all the arguments, for example, the second is much easier to read.

I prefer the second version, and it seems to me it is more common. In the old days there was a performance benefit in the first one.

Sometimes the first is nice because you don’t need extra paretheses when you add a method, like

SinOsc.ar(440, 0, 0, 1).distort

btw you can also use madd

SinOsc.ar(440).madd(1, 1).distort

>
> Is it a holdover from the days where the latter wasn't turned into a MulAdd?

yes.
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Why the "add" arg?

Daniel Mayer

Am 14.02.2017 um 22:03 schrieb Julian Rohrhuber <[hidden email]>:

> btw you can also use madd
>
> SinOsc.ar(440).madd(1, 1).distort


I meanwhile realized that this option is more intuitive for beginners,
tend to start using it myself for readability:

SinOsc.ar(440).range(0,2)


Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Why the "add" arg?

Scott Carver
I suspect that there are small performance benefits to doing an inline mul and/or add versus a muladd or individual binary operator ugen. It saves at least one ugen in the graph, at least - with something as trivial as an add, the cost of entering a Ugen is probably equal to or greater than the cost of the calculation itself. If you think about an entire complex synth, this could end up being a significant number of UGens saved.

What if we add something like this as a step of the graph optimization phase:
SinOsc.ar(1) + m * n   
  => MulAdd(SinOsc.ar(1), n, m)
  => SonOsc.ar(1, mul:m, add:n);

- S

On Tue, Feb 14, 2017 at 4:35 PM Daniel Mayer <[hidden email]> wrote:

Am 14.02.2017 um 22:03 schrieb Julian Rohrhuber <[hidden email]>:

> btw you can also use madd
>
> SinOsc.ar(440).madd(1, 1).distort


I meanwhile realized that this option is more intuitive for beginners,
tend to start using it myself for readability:

SinOsc.ar(440).range(0,2)


Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Why the "add" arg?

amindfv


El 15 feb 2017, a las 14:31, Scott Carver <[hidden email]> escribió:

I suspect that there are small performance benefits to doing an inline mul and/or add versus a muladd or individual binary operator ugen. It saves at least one ugen in the graph, at least - with something as trivial as an add, the cost of entering a Ugen is probably equal to or greater than the cost of the calculation itself. If you think about an entire complex synth, this could end up being a significant number of UGens saved.

What if we add something like this as a step of the graph optimization phase:
SinOsc.ar(1) + m * n   
  => MulAdd(SinOsc.ar(1), n, m)
  => SonOsc.ar(1, mul:m, add:n);


On my machine, the optimization from step 1 to step 2 is already performed (in the case of there being a mul and an add).

Also, I believe step 2 is equivalent already to step 3. (I don't know of ugens which actually have a mul and add arg on the c++ side).

Tom


- S

On Tue, Feb 14, 2017 at 4:35 PM Daniel Mayer <[hidden email]> wrote:

Am 14.02.2017 um 22:03 schrieb Julian Rohrhuber <[hidden email]>:

> btw you can also use madd
>
> SinOsc.ar(440).madd(1, 1).distort


I meanwhile realized that this option is more intuitive for beginners,
tend to start using it myself for readability:

SinOsc.ar(440).range(0,2)


Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------
_______________________________________________
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/
Loading...