Why the "add" arg?

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

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
|

Re: Why the "add" arg?

julian.rohrhuber

> 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
|

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
|

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
|

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/
Reply | Threaded
Open this post in threaded view
|

Re: Why the "add" arg?

alberto.decampo
why not test: (3.9 dev build)

SynthDef(\x, { Out.ar(0, SinOsc.ar (300)) }).add.dumpUGens; // -> 2: SinOsc, Out
SynthDef(\x, { Out.ar(0, SinOsc.ar (300) * 1.0) }).add.dumpUGens; // SinOsc, Out - * 1.0 optimized away
SynthDef(\x, { Out.ar(0, SinOsc.ar (300, 0, 1.0)) }).add.dumpUGens; // ditto

SynthDef(\x, { Out.ar(0, SinOsc.ar (300) * 0.5) }).add.dumpUGens; // 3: SinOsc, *, Out,
SynthDef(\x, { Out.ar(0, SinOsc.ar (300, 0, 0.5)) }).add.dumpUGens.play; // ditto

SynthDef(\x, { Out.ar(0, SinOsc.ar (300) * 0.5 + 0.5) }).add.dumpUGens.play; // SinOsc, MulAdd, Out
// -> this is translated to MulAdd!
SynthDef(\x, { Out.ar(0, SinOsc.ar (300, 0, 0.5, 0.5)) }).add.dumpUGens.play; // ditto

SynthDef(\x, { Out.ar(0, SinOsc.ar (300) + 0.5 * 0.5) }).add.dumpUGens.play; // 4: SinOsc, +, *, Out
// -> not translated to MulAdd because order + * does not match


Personally, my preferred clarity / readability order is:
SinOsc.ar(freq) * 0.5 + 0.3 // clearest
SinOsc.ar(freq, mul: 0.5, add: 0.3 ) // ok

SinOsc.ar(freq, 0, 0.5, 0.3 ) // looks like expert style code, but is the hardest to read:
// it requires remembering the default arg values, even though they  contain no necessary information;
// having to read and then ignore them is actually distracting cognitive load / clutter.


my 2c adc


> On 15/02/2017, at 23:15 , [hidden email] wrote:
>
>
>
> 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/


_______________________________________________
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: Why the "add" arg?

Luka Prinčič / Nova deViator
In reply to this post by daniel-mayer
Daniel Mayer <[hidden email]>:

>
> 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)

this is soooo convenient!
FM is just around the corner. when you are coding and you think "i want
this frequency to be modulated between 400 and 1000" you then can just
use that range method instead of calculating multiply and add.
thanks, what a relevelation. yes, more intuitive for beginners.


({
        SinOsc.ar(
                freq: SinOsc.kr(freq:40).range(440,1200)
        );
}.play;
)




luka.

_______________________________________________
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: Why the "add" arg?

Fredrik Olofsson

> 25 feb 2017 kl. 16:05 skrev Luka Prinčič / Nova deViator <[hidden email]>:
>
> Daniel Mayer <[hidden email]>:
>
>>
>> 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)
>
> this is soooo convenient!
> FM is just around the corner. when you are coding and you think "i want
> this frequency to be modulated between 400 and 1000" you then can just
> use that range method instead of calculating multiply and add.
> thanks, what a relevelation. yes, more intuitive for beginners.
>
>
> ({
> SinOsc.ar(
> freq: SinOsc.kr(freq:40).range(440,1200)
> );
> }.play;
> )

and don't miss out on the variants exprange and curverange...

({
        SinOsc.ar(
                freq: SinOsc.kr(freq:40).exprange(440,1200)
        );
}.play;
)

({
        SinOsc.ar(
                freq: SinOsc.kr(freq:40).curverange(440,1200,MouseX.kr(-10, 10))
        );
}.play;
)

_f

  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#


_______________________________________________
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/