core UGen checklist

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

core UGen checklist

Nathan Ho
hi list,

i'm going to be working on some new UGens over the next few months
(mainly reverbs, antialiased oscillators, and virtual analog models).
i've come up with a little checklist of everything i consider to be the
minimum quality standards for a core UGen:

https://github.com/supercollider/supercollider/wiki/%5BWIP%5D-Developer-info-(DEVELOPING.md)#new-ugens

i will repeat the checklist here for those who don't want to leave the
comfort of their email clients:

- The UGen should be deemed useful enough to the general SC user base.
- The Ctor sample should be initialized. If this is not done, very nasty
bugs can occur.
- Any calls to RTAlloc should be protected from RTAlloc returning a null
pointer. This usually happens when there isn't enough real-time memory
left, and results in a server crash if unprotected.
- Zap dangerous values (subnormals, infinities, nans) in feedback loops
to 0. SC provides a zapgremlins function that does this for you.
- Don't leave any unnecessary print statements lying around.
- Sample rate and block size independence should be maintained if
applicable. For example, audio UGens shouldn't sound radically different
if the sample rate is increased.
- For audio UGens, control-rate inputs should be interpolated if
applicable.
- UGens should have both .ar and .kr methods if applicable.
- Don't use a doneAction argument. Set the done flag instead.
- UGens should be efficient. SuperCollider takes pride in being easy on
the CPU, and UGens should help support that reputation.

is there anything i'm missing, or anything disputable about the above?


nathan

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

Josh Parmenter
So - looking at your reverb that you sent over (rather quickly), I’m wondering what kind of overhead there is to the C++ method calls on the classes. I usually avoid that and use Functions that pass in the UGen or other struct if values need to be shared / updated, and I wonder if that is where your performance hit is coming from.
I’ll look more tomorrow, but that was just something I noticed tonight that I wanted to look more into.
Josh

/*
Josh Parmenter
www.realizedsound.net/josh
*/

> On Jan 2, 2018, at 22:04, [hidden email] wrote:
>
> hi list,
>
> i'm going to be working on some new UGens over the next few months (mainly reverbs, antialiased oscillators, and virtual analog models). i've come up with a little checklist of everything i consider to be the minimum quality standards for a core UGen:
>
> https://github.com/supercollider/supercollider/wiki/%5BWIP%5D-Developer-info-(DEVELOPING.md)#new-ugens
>
> i will repeat the checklist here for those who don't want to leave the comfort of their email clients:
>
> - The UGen should be deemed useful enough to the general SC user base.
> - The Ctor sample should be initialized. If this is not done, very nasty bugs can occur.
> - Any calls to RTAlloc should be protected from RTAlloc returning a null pointer. This usually happens when there isn't enough real-time memory left, and results in a server crash if unprotected.
> - Zap dangerous values (subnormals, infinities, nans) in feedback loops to 0. SC provides a zapgremlins function that does this for you.
> - Don't leave any unnecessary print statements lying around.
> - Sample rate and block size independence should be maintained if applicable. For example, audio UGens shouldn't sound radically different if the sample rate is increased.
> - For audio UGens, control-rate inputs should be interpolated if applicable.
> - UGens should have both .ar and .kr methods if applicable.
> - Don't use a doneAction argument. Set the done flag instead.
> - UGens should be efficient. SuperCollider takes pride in being easy on the CPU, and UGens should help support that reputation.
>
> is there anything i'm missing, or anything disputable about the above?
>
>
> nathan
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

patrick
In reply to this post by Nathan Ho

Hey Nathan,


What do you mean by this exactly?


- Don't use a doneAction argument. Set the done flag instead.


Patrick
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

julian.rohrhuber
In reply to this post by Nathan Ho
> - UGens should have both .ar and .kr methods if applicable.

They also should properly handle ar and kr arguments if applicable.


> - UGens should be efficient. SuperCollider takes pride in being easy on the CPU, and UGens should help support that reputation.

This could be clarified. My suggestion would be something like:

- UGens should run efficiently in real-time. They should distribute calculations over time. Unlike plugins in other systems, they shouldn’t take much CPU for initialisation and runtime. Depending on the task, between tens and ten thousands of them may run at the same time.
- It is recommended to reduce a UGen’s features to an optimal point and make sure that it can be combined with other UGens well.



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

Re: core UGen checklist

julian.rohrhuber
In reply to this post by Josh Parmenter

> On 03.01.2018, at 07:17, [hidden email] wrote:
>
> So - looking at your reverb that you sent over (rather quickly), I’m wondering what kind of overhead there is to the C++ method calls on the classes. I usually avoid that and use Functions that pass in the UGen or other struct if values need to be shared / updated, and I wonder if that is where your performance hit is coming from.
> I’ll look more tomorrow, but that was just something I noticed tonight that I wanted to look more into.
> Josh

Originally, the plugin API was thought of being plain C without C++. Had we kept with this, I assume that it would have had a number of advantages.

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

Re: core UGen checklist

floriangrond
- For audio UGens, control-rate inputs should be interpolated if applicable.

While still working to get the HOA plugins to work (i.e. compile on scsynth and supernova and to eventually merge them into the SC3Plugins, I would like to through in the following thought:

for ambisonics, 3D audio in general, or any ring topology, the following .kr rate interpolation would be great:
linear for all values between -pi and +pi but jumping from +pi to -pi so that this discontinuity is preserved
otherwise, the sounds jump when going over the full circle since the interpolation can lead to values that in fact, we don't want.
Like this, we could have the efficiency of .kr without the wrap around artifacts.

Would that possibly justify a new type of control rate?

Florian






On Wed, Jan 3, 2018 at 1:44 AM, <[hidden email]> wrote:

> On 03.01.2018, at 07:17, [hidden email] wrote:
>
> So - looking at your reverb that you sent over (rather quickly), I’m wondering what kind of overhead there is to the C++ method calls on the classes. I usually avoid that and use Functions that pass in the UGen or other struct if values need to be shared / updated, and I wonder if that is where your performance hit is coming from.
> I’ll look more tomorrow, but that was just something I noticed tonight that I wanted to look more into.
> Josh

Originally, the plugin API was thought of being plain C without C++. Had we kept with this, I assume that it would have had a number of advantages.

Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
I don't think so.

Why not simply a version of K2A that presumes trigonometric interpolation?

best, ..h.h..


On 03/01/18 19:53, [hidden email] wrote:
> Would that possibly justify a new type of control rate?

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

Joseph Anderson-4
Nice idea!



Dr Joseph Anderson | Research Scientist

DXARTS, Box 353414

University of Washington

Seattle, WA 98195-3680

 

http://www.dxarts.washington.edu


Subscribe to our events list to receive email updates about lectures, performances, exhibitions and more.



On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]> wrote:
I don't think so.

Why not simply a version of K2A that presumes trigonometric interpolation?

best, ..h.h..


On 03/01/18 19:53, [hidden email] wrote:
> Would that possibly justify a new type of control rate?


Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

floriangrond
I like the K2A idea too, but what are the performance implications comparing audio rate buses after K2A and control rate busses with a dedicated trigonometric interpolation behavior in the Ugen?
I like to think that this wrap around situation is a general issue in whatever type of 3D audio.

Florian



 


On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]> wrote:
Nice idea!



Dr Joseph Anderson | Research Scientist

DXARTS, Box 353414

University of Washington

Seattle, WA 98195-3680

 

http://www.dxarts.washington.edu


Subscribe to our events list to receive email updates about lectures, performances, exhibitions and more.



On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]> wrote:
I don't think so.

Why not simply a version of K2A that presumes trigonometric interpolation?

best, ..h.h..


On 03/01/18 19:53, [hidden email] wrote:
> Would that possibly justify a new type of control rate?



Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
one would need a specific example to assess the performance, but in my
experience i have moved to mostly using audio rate and find the gain of
k-rate in many cases negligible. i would assume that your ops would stay
in k-rate for most of the time (e.g. combination of unary and binary
ops, scaling, clipping etc.) and only be interpolated in the very last
stage? because if you are talking about interpolation, you are already
talking about a sink ugen that runs at audio-rate, or not? so where
would be the overhead of inserting the K2APolar at this point?

best, .h.h.




On 03/01/18 22:17, [hidden email] wrote:

> I like the K2A idea too, but what are the performance implications
> comparing audio rate buses after K2A and control rate busses with a
> dedicated trigonometric interpolation behavior in the Ugen?
> I like to think that this wrap around situation is a general issue in
> whatever type of 3D audio.
>
> Florian
>
>
>
>  
>
>
>
> www.grond.at <http://www.grond.at>
>
> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Nice idea!
>
>
>     *
>     *
>
>     *Dr Joseph Anderson | Research Scientist*
>
>     DXARTS, Box 353414
>
>     University of Washington
>
>     Seattle, WA 98195-3680
>
>      
>
>     http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>
>
>     Subscribe to our events list
>     <https://dxarts.washington.edu/mailing-list> to receive email
>     updates about lectures, performances, exhibitions and more.
>
>
>
>     On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         I don't think so.
>
>         Why not simply a version of K2A that presumes trigonometric
>         interpolation?
>
>         best, ..h.h..
>
>
>         On 03/01/18 19:53, [hidden email]
>         <mailto:[hidden email]> wrote:
>         > Would that possibly justify a new type of control rate?
>

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
something like this, cast into a ugen:

+ UGen {
        polarAr {
                var xk, yk, xa, ya;
                xk = this.cos;
                yk = this.sin;
                xa = K2A.ar(xk);
                ya = K2A.ar(yk);
                ^atan2(ya, xa)
        }
}

{ K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
{ polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)


On 03/01/18 22:22, [hidden email] wrote:

> one would need a specific example to assess the performance, but in my
> experience i have moved to mostly using audio rate and find the gain of
> k-rate in many cases negligible. i would assume that your ops would stay
> in k-rate for most of the time (e.g. combination of unary and binary
> ops, scaling, clipping etc.) and only be interpolated in the very last
> stage? because if you are talking about interpolation, you are already
> talking about a sink ugen that runs at audio-rate, or not? so where
> would be the overhead of inserting the K2APolar at this point?
>
> best, .h.h.
>
>
>
>
> On 03/01/18 22:17, [hidden email] wrote:
>> I like the K2A idea too, but what are the performance implications
>> comparing audio rate buses after K2A and control rate busses with a
>> dedicated trigonometric interpolation behavior in the Ugen?
>> I like to think that this wrap around situation is a general issue in
>> whatever type of 3D audio.
>>
>> Florian
>>
>>
>>
>>  
>>
>>
>>
>> www.grond.at <http://www.grond.at>
>>
>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Nice idea!
>>
>>
>>     *
>>     *
>>
>>     *Dr Joseph Anderson | Research Scientist*
>>
>>     DXARTS, Box 353414
>>
>>     University of Washington
>>
>>     Seattle, WA 98195-3680
>>
>>      
>>
>>     http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>
>>
>>     Subscribe to our events list
>>     <https://dxarts.washington.edu/mailing-list> to receive email
>>     updates about lectures, performances, exhibitions and more.
>>
>>
>>
>>     On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         I don't think so.
>>
>>         Why not simply a version of K2A that presumes trigonometric
>>         interpolation?
>>
>>         best, ..h.h..
>>
>>
>>         On 03/01/18 19:53, [hidden email]
>>         <mailto:[hidden email]> wrote:
>>         > Would that possibly justify a new type of control rate?
>>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

Josh Parmenter
so - let’s say we have an input where the k-rate arg goes from -0.9pi to 0.9 pi … and another that goes from -0.9pi to -1.1pi - would those act differently as they should?

I can try to test later as well, but this was something I had an issue with when working on ATK.

Josh


> On Jan 3, 2018, at 1:31 PM, [hidden email] wrote:
>
> something like this, cast into a ugen:
>
> + UGen {
> polarAr {
> var xk, yk, xa, ya;
> xk = this.cos;
> yk = this.sin;
> xa = K2A.ar(xk);
> ya = K2A.ar(yk);
> ^atan2(ya, xa)
> }
> }
>
> { K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
> { polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>
>
> On 03/01/18 22:22, [hidden email] wrote:
>> one would need a specific example to assess the performance, but in my
>> experience i have moved to mostly using audio rate and find the gain of
>> k-rate in many cases negligible. i would assume that your ops would stay
>> in k-rate for most of the time (e.g. combination of unary and binary
>> ops, scaling, clipping etc.) and only be interpolated in the very last
>> stage? because if you are talking about interpolation, you are already
>> talking about a sink ugen that runs at audio-rate, or not? so where
>> would be the overhead of inserting the K2APolar at this point?
>>
>> best, .h.h.
>>
>>
>>
>>
>> On 03/01/18 22:17, [hidden email] wrote:
>>> I like the K2A idea too, but what are the performance implications
>>> comparing audio rate buses after K2A and control rate busses with a
>>> dedicated trigonometric interpolation behavior in the Ugen?
>>> I like to think that this wrap around situation is a general issue in
>>> whatever type of 3D audio.
>>>
>>> Florian
>>>
>>>
>>>
>>>  
>>>
>>>
>>>
>>> www.grond.at <http://www.grond.at>
>>>
>>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>    Nice idea!
>>>
>>>
>>>    *
>>>    *
>>>
>>>    *Dr Joseph Anderson | Research Scientist*
>>>
>>>    DXARTS, Box 353414
>>>
>>>    University of Washington
>>>
>>>    Seattle, WA 98195-3680
>>>
>>>    
>>>
>>>    http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>>
>>>
>>>    Subscribe to our events list
>>>    <https://dxarts.washington.edu/mailing-list> to receive email
>>>    updates about lectures, performances, exhibitions and more.
>>>
>>>
>>>
>>>    On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>>    <mailto:[hidden email]>> wrote:
>>>
>>>        I don't think so.
>>>
>>>        Why not simply a version of K2A that presumes trigonometric
>>>        interpolation?
>>>
>>>        best, ..h.h..
>>>
>>>
>>>        On 03/01/18 19:53, [hidden email]
>>>        <mailto:[hidden email]> wrote:
>>>> Would that possibly justify a new type of control rate?
>>>
>>
>> _______________________________________________
>> sc-dev 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-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

Josh Parmenter
In reply to this post by contact
Also - I wonder if we really need to unwrap at all? Why not just use the value that is passed in and not worry about the ‘desired’ range?
Josh



> On Jan 3, 2018, at 1:31 PM, [hidden email] wrote:
>
> something like this, cast into a ugen:
>
> + UGen {
> polarAr {
> var xk, yk, xa, ya;
> xk = this.cos;
> yk = this.sin;
> xa = K2A.ar(xk);
> ya = K2A.ar(yk);
> ^atan2(ya, xa)
> }
> }
>
> { K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
> { polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>
>
> On 03/01/18 22:22, [hidden email] wrote:
>> one would need a specific example to assess the performance, but in my
>> experience i have moved to mostly using audio rate and find the gain of
>> k-rate in many cases negligible. i would assume that your ops would stay
>> in k-rate for most of the time (e.g. combination of unary and binary
>> ops, scaling, clipping etc.) and only be interpolated in the very last
>> stage? because if you are talking about interpolation, you are already
>> talking about a sink ugen that runs at audio-rate, or not? so where
>> would be the overhead of inserting the K2APolar at this point?
>>
>> best, .h.h.
>>
>>
>>
>>
>> On 03/01/18 22:17, [hidden email] wrote:
>>> I like the K2A idea too, but what are the performance implications
>>> comparing audio rate buses after K2A and control rate busses with a
>>> dedicated trigonometric interpolation behavior in the Ugen?
>>> I like to think that this wrap around situation is a general issue in
>>> whatever type of 3D audio.
>>>
>>> Florian
>>>
>>>
>>>
>>>  
>>>
>>>
>>>
>>> www.grond.at <http://www.grond.at>
>>>
>>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>    Nice idea!
>>>
>>>
>>>    *
>>>    *
>>>
>>>    *Dr Joseph Anderson | Research Scientist*
>>>
>>>    DXARTS, Box 353414
>>>
>>>    University of Washington
>>>
>>>    Seattle, WA 98195-3680
>>>
>>>    
>>>
>>>    http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>>
>>>
>>>    Subscribe to our events list
>>>    <https://dxarts.washington.edu/mailing-list> to receive email
>>>    updates about lectures, performances, exhibitions and more.
>>>
>>>
>>>
>>>    On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>>    <mailto:[hidden email]>> wrote:
>>>
>>>        I don't think so.
>>>
>>>        Why not simply a version of K2A that presumes trigonometric
>>>        interpolation?
>>>
>>>        best, ..h.h..
>>>
>>>
>>>        On 03/01/18 19:53, [hidden email]
>>>        <mailto:[hidden email]> wrote:
>>>> Would that possibly justify a new type of control rate?
>>>
>>
>> _______________________________________________
>> sc-dev 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-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/


_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
Hey,

I'm not sure I understand; I thought the problem is interpolation for
angles in radians which use a circular space - how is this related to
value ranges (angle ranges)? I'm just converting temporarily to
cartesian coordinates before interpolating...

best, .h.h.


On 03/01/18 22:53, [hidden email] wrote:

> Also - I wonder if we really need to unwrap at all? Why not just use the value that is passed in and not worry about the ‘desired’ range?
> Josh
>
>
>
>> On Jan 3, 2018, at 1:31 PM, [hidden email] wrote:
>>
>> something like this, cast into a ugen:
>>
>> + UGen {
>> polarAr {
>> var xk, yk, xa, ya;
>> xk = this.cos;
>> yk = this.sin;
>> xa = K2A.ar(xk);
>> ya = K2A.ar(yk);
>> ^atan2(ya, xa)
>> }
>> }
>>
>> { K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>> { polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>>
>>
>> On 03/01/18 22:22, [hidden email] wrote:
>>> one would need a specific example to assess the performance, but in my
>>> experience i have moved to mostly using audio rate and find the gain of
>>> k-rate in many cases negligible. i would assume that your ops would stay
>>> in k-rate for most of the time (e.g. combination of unary and binary
>>> ops, scaling, clipping etc.) and only be interpolated in the very last
>>> stage? because if you are talking about interpolation, you are already
>>> talking about a sink ugen that runs at audio-rate, or not? so where
>>> would be the overhead of inserting the K2APolar at this point?
>>>
>>> best, .h.h.
>>>
>>>
>>>
>>>
>>> On 03/01/18 22:17, [hidden email] wrote:
>>>> I like the K2A idea too, but what are the performance implications
>>>> comparing audio rate buses after K2A and control rate busses with a
>>>> dedicated trigonometric interpolation behavior in the Ugen?
>>>> I like to think that this wrap around situation is a general issue in
>>>> whatever type of 3D audio.
>>>>
>>>> Florian
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>
>>>> www.grond.at <http://www.grond.at>
>>>>
>>>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>    Nice idea!
>>>>
>>>>
>>>>    *
>>>>    *
>>>>
>>>>    *Dr Joseph Anderson | Research Scientist*
>>>>
>>>>    DXARTS, Box 353414
>>>>
>>>>    University of Washington
>>>>
>>>>    Seattle, WA 98195-3680
>>>>
>>>>    
>>>>
>>>>    http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>>>
>>>>
>>>>    Subscribe to our events list
>>>>    <https://dxarts.washington.edu/mailing-list> to receive email
>>>>    updates about lectures, performances, exhibitions and more.
>>>>
>>>>
>>>>
>>>>    On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>>>    <mailto:[hidden email]>> wrote:
>>>>
>>>>        I don't think so.
>>>>
>>>>        Why not simply a version of K2A that presumes trigonometric
>>>>        interpolation?
>>>>
>>>>        best, ..h.h..
>>>>
>>>>
>>>>        On 03/01/18 19:53, [hidden email]
>>>>        <mailto:[hidden email]> wrote:
>>>>> Would that possibly justify a new type of control rate?
>>>>
>>>
>>> _______________________________________________
>>> sc-dev 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-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>
>>
>> _______________________________________________
>> sc-dev 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-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
oops - nevermind. of course, this introduces jitter, although it avoids
the discontinuities. a proper ugen would probably just use wrap2(pi)
first, and then check for absdif(x1, x0) > pi to avoid the discontinuity.

best, ..h.h..


On 03/01/18 22:56, [hidden email] wrote:

> Hey,
>
> I'm not sure I understand; I thought the problem is interpolation for
> angles in radians which use a circular space - how is this related to
> value ranges (angle ranges)? I'm just converting temporarily to
> cartesian coordinates before interpolating...
>
> best, .h.h.
>
>
> On 03/01/18 22:53, [hidden email] wrote:
>> Also - I wonder if we really need to unwrap at all? Why not just use the value that is passed in and not worry about the ‘desired’ range?
>> Josh
>>
>>
>>
>>> On Jan 3, 2018, at 1:31 PM, [hidden email] wrote:
>>>
>>> something like this, cast into a ugen:
>>>
>>> + UGen {
>>> polarAr {
>>> var xk, yk, xa, ya;
>>> xk = this.cos;
>>> yk = this.sin;
>>> xa = K2A.ar(xk);
>>> ya = K2A.ar(yk);
>>> ^atan2(ya, xa)
>>> }
>>> }
>>>
>>> { K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>>> { polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>>>
>>>
>>> On 03/01/18 22:22, [hidden email] wrote:
>>>> one would need a specific example to assess the performance, but in my
>>>> experience i have moved to mostly using audio rate and find the gain of
>>>> k-rate in many cases negligible. i would assume that your ops would stay
>>>> in k-rate for most of the time (e.g. combination of unary and binary
>>>> ops, scaling, clipping etc.) and only be interpolated in the very last
>>>> stage? because if you are talking about interpolation, you are already
>>>> talking about a sink ugen that runs at audio-rate, or not? so where
>>>> would be the overhead of inserting the K2APolar at this point?
>>>>
>>>> best, .h.h.
>>>>
>>>>
>>>>
>>>>
>>>> On 03/01/18 22:17, [hidden email] wrote:
>>>>> I like the K2A idea too, but what are the performance implications
>>>>> comparing audio rate buses after K2A and control rate busses with a
>>>>> dedicated trigonometric interpolation behavior in the Ugen?
>>>>> I like to think that this wrap around situation is a general issue in
>>>>> whatever type of 3D audio.
>>>>>
>>>>> Florian
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>
>>>>>
>>>>> www.grond.at <http://www.grond.at>
>>>>>
>>>>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>>    Nice idea!
>>>>>
>>>>>
>>>>>    *
>>>>>    *
>>>>>
>>>>>    *Dr Joseph Anderson | Research Scientist*
>>>>>
>>>>>    DXARTS, Box 353414
>>>>>
>>>>>    University of Washington
>>>>>
>>>>>    Seattle, WA 98195-3680
>>>>>
>>>>>    
>>>>>
>>>>>    http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>>>>
>>>>>
>>>>>    Subscribe to our events list
>>>>>    <https://dxarts.washington.edu/mailing-list> to receive email
>>>>>    updates about lectures, performances, exhibitions and more.
>>>>>
>>>>>
>>>>>
>>>>>    On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>>>>    <mailto:[hidden email]>> wrote:
>>>>>
>>>>>        I don't think so.
>>>>>
>>>>>        Why not simply a version of K2A that presumes trigonometric
>>>>>        interpolation?
>>>>>
>>>>>        best, ..h.h..
>>>>>
>>>>>
>>>>>        On 03/01/18 19:53, [hidden email]
>>>>>        <mailto:[hidden email]> wrote:
>>>>>> Would that possibly justify a new type of control rate?
>>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev 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-dev/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>>
>>>
>>> _______________________________________________
>>> sc-dev 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-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>> _______________________________________________
>> sc-dev 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-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

floriangrond
the relation to value ranges (angle ranges) is because of different coordinate system definitions.

the Spherical class that is typically used in the ATK goes from -pi to pi (e.g. for the azimuth) so the discontinuity is when wrapping around between -pi and pi
other definitions might go from 0 to 2pi etc.
I personally prefer the Spherical class and would adopt this for consistency

however on PanAz etc. the argument range goes from -1 to 1 as in Pan2 and again the discontinuity would be elsewhere.


Best,

Florian


 




On Wed, Jan 3, 2018 at 5:00 PM, <[hidden email]> wrote:
oops - nevermind. of course, this introduces jitter, although it avoids
the discontinuities. a proper ugen would probably just use wrap2(pi)
first, and then check for absdif(x1, x0) > pi to avoid the discontinuity.

best, ..h.h..


On 03/01/18 22:56, [hidden email] wrote:
> Hey,
>
> I'm not sure I understand; I thought the problem is interpolation for
> angles in radians which use a circular space - how is this related to
> value ranges (angle ranges)? I'm just converting temporarily to
> cartesian coordinates before interpolating...
>
> best, .h.h.
>
>
> On 03/01/18 22:53, [hidden email] wrote:
>> Also - I wonder if we really need to unwrap at all? Why not just use the value that is passed in and not worry about the ‘desired’ range?
>> Josh
>>
>>
>>
>>> On Jan 3, 2018, at 1:31 PM, [hidden email] wrote:
>>>
>>> something like this, cast into a ugen:
>>>
>>> + UGen {
>>>     polarAr {
>>>             var xk, yk, xa, ya;
>>>             xk = this.cos;
>>>             yk = this.sin;
>>>             xa = K2A.ar(xk);
>>>             ya = K2A.ar(yk);
>>>             ^atan2(ya, xa)
>>>     }
>>> }
>>>
>>> { K2A.ar (LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>>> { polarAr(LFSaw.kr(100) * pi) }.plot(duration: 0.025)
>>>
>>>
>>> On 03/01/18 22:22, [hidden email] wrote:
>>>> one would need a specific example to assess the performance, but in my
>>>> experience i have moved to mostly using audio rate and find the gain of
>>>> k-rate in many cases negligible. i would assume that your ops would stay
>>>> in k-rate for most of the time (e.g. combination of unary and binary
>>>> ops, scaling, clipping etc.) and only be interpolated in the very last
>>>> stage? because if you are talking about interpolation, you are already
>>>> talking about a sink ugen that runs at audio-rate, or not? so where
>>>> would be the overhead of inserting the K2APolar at this point?
>>>>
>>>> best, .h.h.
>>>>
>>>>
>>>>
>>>>
>>>> On 03/01/18 22:17, [hidden email] wrote:
>>>>> I like the K2A idea too, but what are the performance implications
>>>>> comparing audio rate buses after K2A and control rate busses with a
>>>>> dedicated trigonometric interpolation behavior in the Ugen?
>>>>> I like to think that this wrap around situation is a general issue in
>>>>> whatever type of 3D audio.
>>>>>
>>>>> Florian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> www.grond.at <http://www.grond.at>
>>>>>
>>>>> On Wed, Jan 3, 2018 at 2:37 PM, Joseph Anderson <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>>    Nice idea!
>>>>>
>>>>>
>>>>>    *
>>>>>    *
>>>>>
>>>>>    *Dr Joseph Anderson | Research Scientist*
>>>>>
>>>>>    DXARTS, Box 353414
>>>>>
>>>>>    University of Washington
>>>>>
>>>>>    Seattle, WA 98195-3680
>>>>>
>>>>>
>>>>>
>>>>>    http://www.dxarts.washington.edu <http://www.dxarts.washington.edu>
>>>>>
>>>>>
>>>>>    Subscribe to our events list
>>>>>    <https://dxarts.washington.edu/mailing-list> to receive email
>>>>>    updates about lectures, performances, exhibitions and more.
>>>>>
>>>>>
>>>>>
>>>>>    On Wed, Jan 3, 2018 at 10:57 AM, <[hidden email]
>>>>>    <mailto:[hidden email]>> wrote:
>>>>>
>>>>>        I don't think so.
>>>>>
>>>>>        Why not simply a version of K2A that presumes trigonometric
>>>>>        interpolation?
>>>>>
>>>>>        best, ..h.h..
>>>>>
>>>>>
>>>>>        On 03/01/18 19:53, [hidden email]
>>>>>        <mailto:[hidden email]> wrote:
>>>>>> Would that possibly justify a new type of control rate?
>>>>>
>>>>
>>>> _______________________________________________
>>>> sc-dev 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-dev/
>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>>>
>>>
>>> _______________________________________________
>>> sc-dev 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-dev/
>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>>
>> _______________________________________________
>> sc-dev 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-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
> _______________________________________________
> sc-dev 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-dev/
> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

jamshark70-2
In reply to this post by floriangrond

On January 4, 2018 2:54:03 AM [hidden email] wrote:

> for ambisonics, 3D audio in general, or any ring topology, the following
> .kr rate interpolation would be great:
> linear for all values between -pi and +pi but jumping from +pi to -pi so
> that this discontinuity is preserved
> otherwise, the sounds jump when going over the full circle since the
> interpolation can lead to values that in fact, we don't want.
> Like this, we could have the efficiency of .kr without the wrap around
> artifacts.


UGens implement their own interpolation internally. If it's appropriate for a specific UGen to treat a specific input as an angle in radians and do circular interpolation, then it can do that already, just by writing different math into the calc function for "ar with one or more kr inputs."

Or am I missing something? AFAICS, for instance, Pan2 does its interpolation this way:

float nextleftamp = level * ft->mSine[2048 - ipos];
float nextrightamp = level * ft->mSine[ipos];

float slopeFactor = unit->mRate->mSlopeFactor;
float leftampslope = (nextleftamp - leftamp) * slopeFactor;
float rightampslope = (nextrightamp - rightamp) * slopeFactor;

LOOP1(inNumSamples,
float zin = ZXP(in);
ZXP(leftout) = zin * leftamp;
ZXP(rightout) = zin * rightamp;
leftamp += leftampslope;
rightamp += rightampslope;
);

But there's no law that says this is the only way SC UGens may ever interpolate kr inputs up to ar. You can always write the appropriate logic here. In Pan2, it's not a circular input so it uses this simple approach, but a circular panner could do it differently.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

amindfv
A couple of separate thoughts:

  - Do we need a checklist item about whether f(0) == f(-1)? We found some pretty frustrating and seemingly unfixable bugs/inconsistencies caused by some UGen expecting f(0)==f(-1), and Impulse not following it. Do we need a "rule" about this for future UGens? (And if so, what?)

  - In case it needs stating: adding UGens to core SC (and not sc3-plugins) is a Big Responsibility. People have learned to trust their eardrums and performances to the UGens in core, and we need to maintain this near-impeccable standard. Of course, if we get unlucky we may need to fix edge cases (like the Ctor bug), but I think the goal we should be shooting for is that once it's in core (and not in sc3-plugins), it doesn't change. A sentence I hope not to hear in the future: "crap, my performance sounds all weird since I built the latest from master."

Btw, very excited to hear you're embarking on new UGens, Nathan, and I can't wait to take 'em for a spin!

Tom



On Wed, Jan 3, 2018 at 6:58 PM, <[hidden email]> wrote:

On January 4, 2018 2:54:03 AM [hidden email] wrote:

> for ambisonics, 3D audio in general, or any ring topology, the following
> .kr rate interpolation would be great:
> linear for all values between -pi and +pi but jumping from +pi to -pi so
> that this discontinuity is preserved
> otherwise, the sounds jump when going over the full circle since the
> interpolation can lead to values that in fact, we don't want.
> Like this, we could have the efficiency of .kr without the wrap around
> artifacts.


UGens implement their own interpolation internally. If it's appropriate for a specific UGen to treat a specific input as an angle in radians and do circular interpolation, then it can do that already, just by writing different math into the calc function for "ar with one or more kr inputs."

Or am I missing something? AFAICS, for instance, Pan2 does its interpolation this way:

float nextleftamp = level * ft->mSine[2048 - ipos];
float nextrightamp = level * ft->mSine[ipos];

float slopeFactor = unit->mRate->mSlopeFactor;
float leftampslope = (nextleftamp - leftamp) * slopeFactor;
float rightampslope = (nextrightamp - rightamp) * slopeFactor;

LOOP1(inNumSamples,
float zin = ZXP(in);
ZXP(leftout) = zin * leftamp;
ZXP(rightout) = zin * rightamp;
leftamp += leftampslope;
rightamp += rightampslope;
);

But there's no law that says this is the only way SC UGens may ever interpolate kr inputs up to ar. You can always write the appropriate logic here. In Pan2, it's not a circular input so it uses this simple approach, but a circular panner could do it differently.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com


Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

jamshark70-2

On January 7, 2018 7:37:51 AM [hidden email] wrote:

>   - Do we need a checklist item about whether f(0) == f(-1)? We found some
> pretty frustrating and seemingly unfixable bugs/inconsistencies caused by
> some UGen expecting f(0)==f(-1), and Impulse not following it. Do we need a
> "rule" about this for future UGens? (And if so, what?)


I ended up abandoning this, without a solution.

Probably the least intrusive is to leave it as it is, and add an InitialTrig UGen that initializes to 1 (and outputs a single 1?) before going to 0: theRealTrig + InitialTrig.kr.

I'm not crazy about that but it's risky to mess with Impulse -- it's too fundamental a UGen.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

Reply | Threaded
Open this post in threaded view
|

Re: core UGen checklist

contact
+1

On 07/01/18 04:37, [hidden email] wrote:
> but it's risky to mess with Impulse -- it's too fundamental a UGen.

_______________________________________________
sc-dev 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-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
12