Quantcast

LLVM-based libfaust integration?

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

LLVM-based libfaust integration?

lfsaw
Hello there,


While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.

Here's a general overview on the interface:
        http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html


We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.


My humble contribution to the discussion is the following little text, maybe it sparks ideas.


---

A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:

SuperCollider's architecture is modular.

while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.

A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.

Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).

But maybe this is something for a different place to discuss... maybe sc-dev?

----


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

Re: LLVM-based libfaust integration?

sletz
"which in particular means that the CTor cannot take too long" : anything more precise here? And what happens if "CTor takes too long" ?

"would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly)." Doesn't OSC allow to transmit string  type ? Is the size limited ? Or arbitrary data blobs?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

floriangrond
In reply to this post by lfsaw
I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.

Florian


On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
Hello there,


While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.

Here's a general overview on the interface:
        http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html


We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.


My humble contribution to the discussion is the following little text, maybe it sparks ideas.


---

A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:

SuperCollider's architecture is modular.

while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.

A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.

Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).

But maybe this is something for a different place to discuss... maybe sc-dev?

----


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

Re: LLVM-based libfaust integration?

sletz
We could imagine to keep the libfaust + JIT *heavy* part on sclang side, and just transmit the « machine code » on scsynth side, to be dynamically linked and executed. This would require to split the current published version of « libfaust » a bit, but this is feasible. The points are then 1) how to transmit this « machine code »  (could be as a string AFAICS) and 2) is the «  dynamically link » to heavy to be  « realtime-save, which in particular means that the CTor cannot take too long »...

Stéphane

> Le 12 mai 2017 à 18:23, [hidden email] a écrit :
>
> I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
> Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.
>
> Florian
>
>
>
> www.grond.at
>
> On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
> Hello there,
>
>
> While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.
>
> Here's a general overview on the interface:
>         http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html
>
>
> We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.
>
>
> My humble contribution to the discussion is the following little text, maybe it sparks ideas.
>
>
> ---
>
> A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:
>
> SuperCollider's architecture is modular.
>
> while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.
>
> A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.
>
> Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).
>
> But maybe this is something for a different place to discuss... maybe sc-dev?
>
> ----
>
>
> cheers
>         Till
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

lfsaw
In reply to this post by floriangrond
IMHO, JIT and separate plugin development are two very different things and should be considered separately.
While the plugin development is pretty straight forward (create a symbolic link to your the folder with your .dsp files, run faust2supercollider in there, reboot server [if interface changed, recompile sclang], test/use your new and shiny plugin), it still requires to reboot the server. A JIT compiler would essentially mean that one can write a plugin _while the server is running_ to do e.g. live-coding experiments but also plugin development in a very short development cycle. This would also mean that (by introducing faust as a UGen language), people are finally able to write their 1-sample feedback synths (sic).

:)
        Till


> On 12. May 2017, at 19:23, [hidden email] wrote:
>
> I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
> Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.
>
> Florian
>
>
>
> www.grond.at
>
> On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
> Hello there,
>
>
> While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.
>
> Here's a general overview on the interface:
>         http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html
>
>
> We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.
>
>
> My humble contribution to the discussion is the following little text, maybe it sparks ideas.
>
>
> ---
>
> A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:
>
> SuperCollider's architecture is modular.
>
> while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.
>
> A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.
>
> Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).
>
> But maybe this is something for a different place to discuss... maybe sc-dev?
>
> ----
>
>
> cheers
>         Till
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

sletz
I must add that the « Pierre Lecomte based HOA plugins » case is a bit « border line » , in the sense that (for or some reason we still have to look for...) the Faust compilation step takes *a lot* to time, and the C++ compilation also. But for a lot of reasonable DSPs, the Faust ==> LLVM ==> JIT path is quite fast, as we regularly experiment with the FaustLive application for instance.

Now it would help of SC developers can answer the more technical issues I’ve asked, thanks.

Stéphane

> Le 13 mai 2017 à 09:07, [hidden email] a écrit :
>
> IMHO, JIT and separate plugin development are two very different things and should be considered separately.
> While the plugin development is pretty straight forward (create a symbolic link to your the folder with your .dsp files, run faust2supercollider in there, reboot server [if interface changed, recompile sclang], test/use your new and shiny plugin), it still requires to reboot the server. A JIT compiler would essentially mean that one can write a plugin _while the server is running_ to do e.g. live-coding experiments but also plugin development in a very short development cycle. This would also mean that (by introducing faust as a UGen language), people are finally able to write their 1-sample feedback synths (sic).
>
> :)
> Till
>
>
>> On 12. May 2017, at 19:23, [hidden email] wrote:
>>
>> I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
>> Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.
>>
>> Florian
>>
>>
>>
>> www.grond.at
>>
>> On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
>> Hello there,
>>
>>
>> While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.
>>
>> Here's a general overview on the interface:
>>        http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html
>>
>>
>> We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.
>>
>>
>> My humble contribution to the discussion is the following little text, maybe it sparks ideas.
>>
>>
>> ---
>>
>> A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:
>>
>> SuperCollider's architecture is modular.
>>
>> while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.
>>
>> A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.
>>
>> Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).
>>
>> But maybe this is something for a different place to discuss... maybe sc-dev?
>>
>> ----
>>
>>
>> cheers
>>        Till
>> _______________________________________________
>> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

James Harkins
In reply to this post by sletz
On May 13, 2017 00:17:45 [hidden email] wrote:

> "which in particular means that the CTor cannot take too long" : anything
> more precise here? And what happens if "CTor takes too long" ?

Scsynth should complete all of its calculation for a hardware buffer's
worth of audio well within the duration of the hardware buffer, including
Ctor operations. And there is no way to fork the Ctor off into a lower
priority thread, because the Ctor's work must be completely finished before
the engine calls the unit's next_ function. It all has to stay in the
realtime thread.

If a Ctor takes too long, the hardware block of audio will be late and
you'll hear a dropout. I don't think there's any consequence in terms of
stability, but dropouts are not something we want to encourage in live
situations.

hjh

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




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

Re: LLVM-based libfaust integration?

sletz

> Le 13 mai 2017 à 11:26, [hidden email] a écrit :
>
> On May 13, 2017 00:17:45 [hidden email] wrote:
>
>> "which in particular means that the CTor cannot take too long" : anything
>> more precise here? And what happens if "CTor takes too long" ?
>
> Scsynth should complete all of its calculation for a hardware buffer's worth of audio well within the duration of the hardware buffer, including Ctor operations.

OK.

> And there is no way to fork the Ctor off into a lower priority thread, because the Ctor's work must be completely finished before the engine calls the unit's next_ function. It all has to stay in the realtime thread.

So we would need a kind of « 2 steps »  synth object which Ctor’s first returns a kind of dummy audio object (with a default behavior that works reasonably well in the audio graph), to be « switched to the real one » (in an atomic way…)  when finished. Would it be possible?

>
> If a Ctor takes too long, the hardware block of audio will be late and you'll hear a dropout. I don't think there's any consequence in terms of stability, but dropouts are not something we want to encourage in live situations.

Yes sure !

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

Re: LLVM-based libfaust integration?

floriangrond
In reply to this post by sletz


On May 13, 2017 04:28, <[hidden email]> wrote:
I must add that the « Pierre Lecomte based HOA plugins » case is a bit « border line » , in the sense that (for or some reason we still have to look for...) the Faust compilation step takes *a lot* to time, and the C++ compilation also. But for a lot of reasonable DSPs, the Faust ==> LLVM ==> JIT path is quite fast, as we regularly experiment with the FaustLive application for instance.

Agreed!

Now it would help of SC developers can answer the more technical issues I’ve asked, thanks.

Stéphane

> Le 13 mai 2017 à 09:07, [hidden email] a écrit :
>
> IMHO, JIT and separate plugin development are two very different things and should be considered separately.
> While the plugin development is pretty straight forward (create a symbolic link to your the folder with your .dsp files, run faust2supercollider in there, reboot server [if interface changed, recompile sclang], test/use your new and shiny plugin), it still requires to reboot the server. A JIT compiler would essentially mean that one can write a plugin _while the server is running_ to do e.g. live-coding experiments but also plugin development in a very short development cycle. This would also mean that (by introducing faust as a UGen language), people are finally able to write their 1-sample feedback synths (sic).
>
> :)
>       Till
>
>
>> On 12. May 2017, at 19:23, [hidden email] wrote:
>>
>> I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
>> Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.
>>
>> Florian
>>
>>
>>
>> www.grond.at
>>
>> On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
>> Hello there,
>>
>>
>> While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.
>>
>> Here's a general overview on the interface:
>>        http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html
>>
>>
>> We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.
>>
>>
>> My humble contribution to the discussion is the following little text, maybe it sparks ideas.
>>
>>
>> ---
>>
>> A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:
>>
>> SuperCollider's architecture is modular.
>>
>> while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.
>>
>> A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.
>>
>> Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).
>>
>> But maybe this is something for a different place to discuss... maybe sc-dev?
>>
>> ----
>>
>>
>> cheers
>>        Till
>> _______________________________________________
>> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

Nick Collins-2
scsynth UGens can spawn NRT processing, including extra construction work ahead of coming online properly (just run a dummy next function till then). 

See example here in the source for a source separation plugin: 
and in an LLVM plugin here:

best
N


On 13 May 2017, at 11:51, [hidden email] wrote:



On May 13, 2017 04:28, <[hidden email]> wrote:
I must add that the « Pierre Lecomte based HOA plugins » case is a bit « border line » , in the sense that (for or some reason we still have to look for...) the Faust compilation step takes *a lot* to time, and the C++ compilation also. But for a lot of reasonable DSPs, the Faust ==> LLVM ==> JIT path is quite fast, as we regularly experiment with the FaustLive application for instance.

Agreed!

Now it would help of SC developers can answer the more technical issues I’ve asked, thanks.

Stéphane

> Le 13 mai 2017 à 09:07, [hidden email] a écrit :
>
> IMHO, JIT and separate plugin development are two very different things and should be considered separately.
> While the plugin development is pretty straight forward (create a symbolic link to your the folder with your .dsp files, run faust2supercollider in there, reboot server [if interface changed, recompile sclang], test/use your new and shiny plugin), it still requires to reboot the server. A JIT compiler would essentially mean that one can write a plugin _while the server is running_ to do e.g. live-coding experiments but also plugin development in a very short development cycle. This would also mean that (by introducing faust as a UGen language), people are finally able to write their 1-sample feedback synths (sic).
>
> :)
>       Till
>
>
>> On 12. May 2017, at 19:23, [hidden email] wrote:
>>
>> I just remember that the compilation of some of the faust based HOA plugins, I did together with Pierre Lecomte took a long time so the JIT idea might turn out to be often too late. Working to improve the plugin option seems more interesting to me.
>> Stephane Letz added a flag to the faust2supercollider script which returns the .sc class and the .cpp file, very useful for plugins.
>>
>> Florian
>>
>>
>>
>> www.grond.at
>>
>> On Fri, May 12, 2017 at 12:05 PM, <[hidden email]> wrote:
>> Hello there,
>>
>>
>> While discussing optimisation strategies for the refactoring of Greyhole/JPverb over at https://github.com/supercollider/sc3-plugins/pull/143#issuecomment-301109005 , @sletz sparked the idea to integrate the FAUST JIT-compiler into SuperCollider.
>>
>> Here's a general overview on the interface:
>>        http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html
>>
>>
>> We just thought to throw it in here, maybe there's someone willing (and capable) to look into this. I am very certain that the FAUST developer community is more than willing to help out in implementation details.
>>
>>
>> My humble contribution to the discussion is the following little text, maybe it sparks ideas.
>>
>>
>> ---
>>
>> A JIT-style faust integration into SuperCollider would be insanely great to have. However, there are certain caveats for this built right into the SC architecture:
>>
>> SuperCollider's architecture is modular.
>>
>> while the language deals with high-level control structures and is, as an interpreted language, highly flexible, sound processing happens on  scsynth, a hardwired structure of a node tree, audio/control buses and (float*) buffers.
>>
>> A trivial choice to put the JIT compiler would be an scsynth plugin. However, operation of any scsynth plugin requires it to be realtime-save, which in particular means that the CTor cannot take too long. >> bummer.
>>
>> Another choice would be to integrate JIT compiler into the language. Apart from that C++ extensions of the language are far from non-trivial  (and fellow developers will properly laugh at us trying to get yet another feature implemented there), this would mean that the compiled program needs to be transferred to the server somehow... almost the only possibility for data exchange between language and server are OSC messages, the only data type available would be buffer objects that can only contain floats (well, we could cast those into whatever... but that's kinda ugly).
>>
>> But maybe this is something for a different place to discuss... maybe sc-dev?
>>
>> ----
>>
>>
>> cheers
>>        Till
>> _______________________________________________
>> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

sletz
Very interesting thanks. So I understand that Clang based compilation is done on scsynth side, and this explains for instance that « 1) Can't get clang reporting of code compilation errors to print to SC post window at present » right?

In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.

Does that make sense ?

Stéphane


> Le 13 mai 2017 à 14:17, [hidden email] a écrit :
>
> scsynth UGens can spawn NRT processing, including extra construction work ahead of coming online properly (just run a dummy next function till then).
>
> See example here in the source for a source separation plugin:
> http://composerprogrammer.com/code/SourceSeparation.zip
> and in an LLVM plugin here:
> http://composerprogrammer.com/code/ClangUGen.zip
>
> best
> N
>
>
> On 13 May 2017, at 11:51, [hidden email] wrote:
>


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

Re: LLVM-based libfaust integration?

floriangrond
Just to clarify: once the executable code is ready to be started, ... could it then optionally also be saved to a file in plugin style? So that compilations that take longer don't need to be redone? If so that would make then faust-based SC3plugins contributions obsolete.  


On Sat, May 13, 2017 at 9:18 AM, <[hidden email]> wrote:
Very interesting thanks. So I understand that Clang based compilation is done on scsynth side, and this explains for instance that « 1) Can't get clang reporting of code compilation errors to print to SC post window at present » right?

In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.

Does that make sense ?

Stéphane


> Le 13 mai 2017 à 14:17, [hidden email] a écrit :
>
> scsynth UGens can spawn NRT processing, including extra construction work ahead of coming online properly (just run a dummy next function till then).
>
> See example here in the source for a source separation plugin:
> http://composerprogrammer.com/code/SourceSeparation.zip
> and in an LLVM plugin here:
> http://composerprogrammer.com/code/ClangUGen.zip
>
> best
> N
>
>
> On 13 May 2017, at 11:51, [hidden email] wrote:
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

sletz
Yes this could be done, see post here : http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html

Basically there is a set of read/write functions that can either save the LLVM IR (in binary or textual form) which would save the «  Faust DSP ==> LLVM IR compilation » part, or even better the machine format that would save the « Faust DSP ==> LLVM IR  ==> JIT ==> machine code » part.

But I don’t think this would make faust-based SC3plugins obsolete, this new model would be complementary. We have the same model in Max/MSP where the developer can either « statically » compile his Faust DSP with « faust2max6 » kind of script, or use the faustgen~ external that embeds the libfaust based dynamic compilation chain. Developer usually experiment/develop with the  faustgen~ external, then they recompile the final DSP code with the static approach. This can be easier to deliver self-contained Max/MSP patches for instance.

Stéphane

> Le 13 mai 2017 à 17:36, [hidden email] a écrit :
>
> Just to clarify: once the executable code is ready to be started, ... could it then optionally also be saved to a file in plugin style? So that compilations that take longer don't need to be redone? If so that would make then faust-based SC3plugins contributions obsolete.  
>
> www.grond.at
>
> On Sat, May 13, 2017 at 9:18 AM, <[hidden email]> wrote:
> Very interesting thanks. So I understand that Clang based compilation is done on scsynth side, and this explains for instance that « 1) Can't get clang reporting of code compilation errors to print to SC post window at present » right?
>
> In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.
>
> Does that make sense ?
>
> Stéphane
>
>
> > Le 13 mai 2017 à 14:17, [hidden email] a écrit :
> >
> > scsynth UGens can spawn NRT processing, including extra construction work ahead of coming online properly (just run a dummy next function till then).
> >
> > See example here in the source for a source separation plugin:
> > http://composerprogrammer.com/code/SourceSeparation.zip
> > and in an LLVM plugin here:
> > http://composerprogrammer.com/code/ClangUGen.zip
> >
> > best
> > N
> >
> >
> > On 13 May 2017, at 11:51, [hidden email] wrote:
> >
>
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

floriangrond
Thanks a lot for the clarification. It would definitely be very cool to have this! One more question: the
« Faust DSP ==> LLVM IR  ==> JIT ==> machine code » compilation process
is cross-platform? You remember that I was insisting on the .cpp files to add it to the cross-platform SC3plugin collection.

I noticed that the faust online compiler does not offer a SuperCollider option for Windows.





On Sat, May 13, 2017 at 12:18 PM, <[hidden email]> wrote:
Yes this could be done, see post here : http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html

Basically there is a set of read/write functions that can either save the LLVM IR (in binary or textual form) which would save the «  Faust DSP ==> LLVM IR compilation » part, or even better the machine format that would save the « Faust DSP ==> LLVM IR  ==> JIT ==> machine code » part.

But I don’t think this would make faust-based SC3plugins obsolete, this new model would be complementary. We have the same model in Max/MSP where the developer can either « statically » compile his Faust DSP with « faust2max6 » kind of script, or use the faustgen~ external that embeds the libfaust based dynamic compilation chain. Developer usually experiment/develop with the  faustgen~ external, then they recompile the final DSP code with the static approach. This can be easier to deliver self-contained Max/MSP patches for instance.

Stéphane

> Le 13 mai 2017 à 17:36, [hidden email] a écrit :
>
> Just to clarify: once the executable code is ready to be started, ... could it then optionally also be saved to a file in plugin style? So that compilations that take longer don't need to be redone? If so that would make then faust-based SC3plugins contributions obsolete.
>
> www.grond.at
>
> On Sat, May 13, 2017 at 9:18 AM, <[hidden email]> wrote:
> Very interesting thanks. So I understand that Clang based compilation is done on scsynth side, and this explains for instance that « 1) Can't get clang reporting of code compilation errors to print to SC post window at present » right?
>
> In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.
>
> Does that make sense ?
>
> Stéphane
>
>
> > Le 13 mai 2017 à 14:17, [hidden email] a écrit :
> >
> > scsynth UGens can spawn NRT processing, including extra construction work ahead of coming online properly (just run a dummy next function till then).
> >
> > See example here in the source for a source separation plugin:
> > http://composerprogrammer.com/code/SourceSeparation.zip
> > and in an LLVM plugin here:
> > http://composerprogrammer.com/code/ClangUGen.zip
> >
> > best
> > N
> >
> >
> > On 13 May 2017, at 11:51, [hidden email] wrote:
> >
>
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

sletz

> Le 13 mai 2017 à 21:41, [hidden email] a écrit :
>
> Thanks a lot for the clarification. It would definitely be very cool to have this! One more question: the
> « Faust DSP ==> LLVM IR  ==> JIT ==> machine code » compilation process
> is cross-platform?

machine code is specific for a given CPU.

> You remember that I was insisting on the .cpp files to add it to the cross-platform SC3plugin collection.
>
> I noticed that the faust online compiler does not offer a SuperCollider option for Windows.
>

Yep, we would need to cross-compile in this case.

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

Re: LLVM-based libfaust integration?

James Harkins
In reply to this post by sletz
 ---- On Sat, 13 May 2017 21:18:02 +0800 <[hidden email]> wrote ----
> In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.

In the model I’m thinking of, Faust DSP ==> LLVM IR  ==> JIT ==> machine code steps would be done on sclang side (so that DSP programing error can simply be reported here…), and the machine code only would be sent to scsynth side, then the « dynamically link in memory »  step is never supposed to fail, could be done using NRT modele, until the executable code is ready to be started.

I haven't been following this very, very closely, but I think this would be the way to go. I can think of a couple of other reasons, beyond error reporting:

1. SuperCollider's model is to compile a SynthDef() once and reuse it many times with Synth(). If compilation were in the server, you would recompile the FAUST code for every Synth... which is crazy... erm, extremely inefficient.

2. Nick had suggested that UGen Ctors can fork activities outside the real-time DSP thread, and then the UGen can run a dummy function until everything is ready. That may be fine for audio UGens, where initial silence would be acceptable. But we can't be sure nobody will ever use this for control signals. If they do, a dummy function could blow up downstream filters or causing other havoc. So I think it's necessary to get the LLVM code ready in advance so that Synths can simply use it without any more preparation.

hjh


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

Re: LLVM-based libfaust integration?

Tim Blechmann-2
> 1. SuperCollider's model is to compile a SynthDef() once and reuse

> it many times with Synth(). If compilation were in the server, you
> would recompile the FAUST code for every Synth... which is crazy...
> erm, extremely inefficient.
>
> 2. Nick had suggested that UGen Ctors can fork activities outside
> the real-time DSP thread, and then the UGen can run a dummy
> function until everything is ready. That may be fine for audio
> UGens, where initial silence would be acceptable. But we can't be
> sure nobody will ever use this for control signals. If they do, a
> dummy function could blow up downstream filters or causing other
> havoc. So I think it's necessary to get the LLVM code ready in
> advance so that Synths can simply use it without any more
> preparation.
IR/jit code is essentially a non-rt resource, which could be managed
via plug-in commands (compare [1]): preparation/compilation can be
done asynchronously and plugins can reply with a reference (integer id
or the like) when jit-compilation has finished. this reference to the
jitted code can be used when constructing ugens without sacrificing
real-time safety.

my soundfile players use a similar mechanism for the queuing mechanism
(compare [2, 3]).

[1]
https://github.com/supercollider/supercollider/blob/master/server/plugins/UIUGens.cpp#L281
[2] https://github.com/timblechmann/nova-ugens/blob/master/NovaDiskIO.cpp
[3]
https://github.com/timblechmann/nova-ugens/blob/master/sc/NovaDiskIOUGens.sc


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LLVM-based libfaust integration?

Tim Blechmann-2
In reply to this post by floriangrond
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I just remember that the compilation of some of the faust based
> HOA plugins, I did together with Pierre Lecomte took a long time so
> the JIT idea might turn out to be often too late.

btw, for ambisonics (which basically boils down to vector operations
with rather sparse matrices) there may not be a real need for a c++
based plugin as the synthdef graph optimizations kick in and simple
vector operations are highly optimized.

converting the FOA panners from ATK to pseudo-ugens reduced the cpu
usage by at least an order of magnitude. it also has the advantage
that parameter smoothing (to prevent zipper noise when changing
parameters) and optimizations for audio/control/instrument rate
parameters comes for free.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZGCsRAAoJEAIkvWiom07DL1MP/jdecK2Gfq8H5zh+SM+rLwp5
Uc5CmTYn80dZnvtrArnhE/zfUO40HI5zTqQHsa7DynNPAy5BSBVsJY1s5pr7TZUX
POBDeRQzyQz4g4tkRqdSAkGCtJCPt0WnXIfS8pw8SqJVcUNCWg2iAaT3FxNUyVJb
hrKDBPkSJVogtGjSUgb/X1+8tvfgECvWkhkzSHkRDG72Fg/BDR5oJ/YMXEWLDeSW
8oXcMzM77crqT1iAYKuC3U/98wcVHW+zC5l4iiX/rYDETNQ3GyqU29o+HfMwpKgB
mkcjiRDmbZOjAzkooyRf90rvQyBDa1LaSAZwFC4DihN2fGLiBV9EX4pZhUFjCvjo
I3sxrbXmcE6l1VPKjj0NBsrlNyKxl6anIOay8og/jZBfXak843bwLyAiZ8p3j5Ov
mMKTd8iY2IJRAsqICUmJa/a+WntQZeFaPm3H+dhEeM9LiSp/wQDpY7XDgOjggMSw
8BjLAS5QYN0KaH5qSUNEi3ZFzjwA2l6ticuyHqGGDHhZXOF8+UmcZnZ0uRAzygDu
8N0zoQC4LM7pKNWqT4aKWBWwDK7J7w4LkWh4GzmZkgOKALox9X/tgoB6NWuozIrs
nh/Dl1jvTe6Hxp8Jn+w2PXfFd3x4iEQuAChi5g4TId2qcd/k3uIBMYpps1HW4fJP
WwB9MZx1AuV3N/4YuCx2
=kTo6
-----END PGP SIGNATURE-----


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

Re: LLVM-based libfaust integration?

sletz
In reply to this post by James Harkins
>
> 1. SuperCollider's model is to compile a SynthDef() once and reuse it many times with Synth(). If compilation were in the server, you would recompile the FAUST code for every Synth... which is crazy... erm, extremely inefficient.
>
> 2. Nick had suggested that UGen Ctors can fork activities outside the real-time DSP thread, and then the UGen can run a dummy function until everything is ready. That may be fine for audio UGens, where initial silence would be acceptable. But we can't be sure nobody will ever use this for control signals. If they do, a dummy function could blow up downstream filters or causing other havoc. So I think it's necessary to get the LLVM code ready in advance so that Synths can simply use it without any more preparation.
>
> hjh
>

libfaust has then concept of DSP factories and DSP instances: basically from a Faust DSP source, a dsp_factory* is created once (using the createDSPFactoryXX function), then several llvm_dsp* can be created using this factory (using createDSPInstance function). See http://faust.grame.fr/news/2016/01/12/using-dynamic-compiler.html. Factories can also be created by reading precompiled code forms (see the writeDSPFactoryToXXX/readDSPFactoryFromXXX functions).

The idea here would be to create the factory on sclang side, write the factory machine code as a string (using writeDSPFactoryToMachine), transmis this string to scsynth side (OSC messages here ?), recreate the factory there (using readDSPFactoryFromMachine in a NRT processing mode), then create one or several llvm_dsp* instances  (on scsynth side). I see one difficulty here that creating llvm_dsp* instances does not use the SC RTAllocacyor but this can probably be solved.

Stéphane


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

Re: LLVM-based libfaust integration?

Michael McCrea
In reply to this post by Tim Blechmann-2
Somewhat OT, but to follow up on Tim's note about synth graph optimizations (ambisonics, ATK) ...

btw, for ambisonics (which basically boils down to vector operations
with rather sparse matrices) there may not be a real need for a c++
based plugin as the synthdef graph optimizations kick in and simple
vector operations are highly optimized. 
 
converting the FOA panners from ATK to pseudo-ugens reduced the cpu
usage by at least an order of magnitude. it also has the advantage
that parameter smoothing (to prevent zipper noise when changing
parameters) and optimizations for audio/control/instrument rate
parameters comes for free. 

I did some testing of your implementations of ambisonic transforms as pseudo-ugens, and a few issues came up, which I tried to document here (perhaps you got a notification about this):

It appears that there are precision differences between the UGen vs. pseudo-ugen implementations, and some of the parameter smoothing introduces discontinuities depending how values are wrapped (say across the 0<>2pi transition). So unless there is a workaround for these sorts of issues, what you get "for free" from may not actually be what you want. 

I didn't have time to dig into these any more, but without more clarity on why there is precision lost, without the ability to control directions of interpolated values, and with some odd differences in interpolation between audio/control rate modulation, we opted not to move to pseudo-ugens. If you have insights on these issues, the ATK devs would welcome it!

Cheers,
Mike

On Sun, May 14, 2017 at 3:01 AM, <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> I just remember that the compilation of some of the faust based
> HOA plugins, I did together with Pierre Lecomte took a long time so
> the JIT idea might turn out to be often too late.

btw, for ambisonics (which basically boils down to vector operations
with rather sparse matrices) there may not be a real need for a c++
based plugin as the synthdef graph optimizations kick in and simple
vector operations are highly optimized.

converting the FOA panners from ATK to pseudo-ugens reduced the cpu
usage by at least an order of magnitude. it also has the advantage
that parameter smoothing (to prevent zipper noise when changing
parameters) and optimizations for audio/control/instrument rate
parameters comes for free.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZGCsRAAoJEAIkvWiom07DL1MP/jdecK2Gfq8H5zh+SM+rLwp5
Uc5CmTYn80dZnvtrArnhE/zfUO40HI5zTqQHsa7DynNPAy5BSBVsJY1s5pr7TZUX
POBDeRQzyQz4g4tkRqdSAkGCtJCPt0WnXIfS8pw8SqJVcUNCWg2iAaT3FxNUyVJb
hrKDBPkSJVogtGjSUgb/X1+8tvfgECvWkhkzSHkRDG72Fg/BDR5oJ/YMXEWLDeSW
8oXcMzM77crqT1iAYKuC3U/98wcVHW+zC5l4iiX/rYDETNQ3GyqU29o+HfMwpKgB
mkcjiRDmbZOjAzkooyRf90rvQyBDa1LaSAZwFC4DihN2fGLiBV9EX4pZhUFjCvjo
I3sxrbXmcE6l1VPKjj0NBsrlNyKxl6anIOay8og/jZBfXak843bwLyAiZ8p3j5Ov
mMKTd8iY2IJRAsqICUmJa/a+WntQZeFaPm3H+dhEeM9LiSp/wQDpY7XDgOjggMSw
8BjLAS5QYN0KaH5qSUNEi3ZFzjwA2l6ticuyHqGGDHhZXOF8+UmcZnZ0uRAzygDu
8N0zoQC4LM7pKNWqT4aKWBWwDK7J7w4LkWh4GzmZkgOKALox9X/tgoB6NWuozIrs
nh/Dl1jvTe6Hxp8Jn+w2PXfFd3x4iEQuAChi5g4TId2qcd/k3uIBMYpps1HW4fJP
WwB9MZx1AuV3N/4YuCx2
=kTo6
-----END PGP SIGNATURE-----

12
Loading...