[Jack-Devel] graph simplification using mathematics?

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

[Jack-Devel] graph simplification using mathematics?

Thomas Brand

Hi,
i wondered if the following scenario could work.
Assuming DSP is basically maths, and the formula and variables for every
plugin would be known, would it then be possible to magically simplify all
formulas of all plugins to one single formula doing all in one step? Does
this sound weird?
Greetings
Tom

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Paul Davis
DSP might be "basically maths" but take a look at any significant host and you will find that its process() callback does way, way more than "basically maths".

On Sat, Jul 2, 2016 at 4:58 PM, Thomas Brand <[hidden email]> wrote:

Hi,
i wondered if the following scenario could work.
Assuming DSP is basically maths, and the formula and variables for every
plugin would be known, would it then be possible to magically simplify all
formulas of all plugins to one single formula doing all in one step? Does
this sound weird?
Greetings
Tom

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Thomas Brand
In reply to this post by Thomas Brand
On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
> Faust :  http://faust.grame.fr
>

Faust was the first thing that came to mind indeed! The introduction
paragraphs in the documentation says

-specification language
-describe signal processors from a mathematical point of view
-free from implementation details

But right after that:
-FAUST programs are fully compiled, not interpreted.

I can imagine to bundle FAUST code from different processors
semi-automatically or handcrafted to one unit relatively easily. However i
was thinking in a direction where the units live in a host still as single
units, to be connected in different ways, and the host would dynamically
derive a single math operation of the current graph. I understand this
would include recompilation or some kind of JIT compilation in order to
work. If possible at all, i think Faust would currently be the best fit,
since it already offers some of the fundamental concepts needed to even
think about doing something like this. That would allow large graphs with
almost no context switches (this is pure speculation).

Greetings
Tom

PS: jack-devel list added to reply

>
>> Le 2 juil. 2016 à 22:58, Thomas Brand <[hidden email]> a écrit :
>>
>> Hi,
>> i wondered if the following scenario could work. Assuming DSP is
>> basically maths, and the formula and variables for every plugin would be
>> known, would it then be possible to magically simplify all formulas of
>> all plugins to one single formula doing all in one step? Does this sound
>> weird? Greetings
>> Tom
>>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Stéphane Letz
In reply to this post by Thomas Brand
Yes indeed : a starting point here : Sarah Denoux, Yann Orlarey, Stéphane Letz, Dominique Fober, CALCUL D’UNE EXPRESSION FAUST ÉQUIVALENTE À PARTIR D’UN GRAPHE D’APPLICATIONS

http://jim2016.gmea.net/actes
 
(although in french)

And in function here : http://faust.grame.fr/faustplayground/ when you export the final equivalent patch.

Stéphane


> Le 3 juil. 2016 à 00:20, Thomas Brand <[hidden email]> a écrit :
>
> On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
>> Faust :  http://faust.grame.fr
>>
>
> Faust was the first thing that came to mind indeed. The introduction
> paragraphs in the documentation says
>
> -specification language
> -describe signal processors from a mathematical point of view
> -free from implementation details
>
> But right after that:
> -FAUST programs are fully compiled, not interpreted.
>
> I can imagine to bundle FAUST code from different processors
> semi-automatically or handcrafted to one unit relatively easily. However i
> was thinking in a direction where the units live in a host still as single
> units, to be connected in different ways, and the host would dynamically
> derive a single math operation of the current graph. I understand this
> would include recompilation or some kind of JIT compilation in order to
> work. If possible at all, i think Faust would currently be the best fit,
> since it already offers some of the fundamental concepts needed to even
> think about doing something like this. That would allow large graphs with
> almost no context switches (this is pure speculation).
>
> Greetings
> Tom
>
>>
>>> Le 2 juil. 2016 à  22:58, Thomas Brand <[hidden email]> a écrit :
>>>
>>> Hi,
>>> i wondered if the following scenario could work. Assuming DSP is
>>> basically maths, and the formula and variables for every plugin would be
>>> known, would it then be possible to magically simplify all formulas of
>>> all plugins to one single formula doing all in one step? Does this sound
>>> weird? Greetings
>>> Tom
>
>

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Thomas Brand
On Sun, July 3, 2016 00:44, Stéphane Letz wrote:

> Yes indeed : a starting point here : Sarah Denoux, Yann Orlarey,
> Stéphane Letz, Dominique Fober, CALCUL D’UNE EXPRESSION FAUST
> ÉQUIVALENTE À PARTIR D’UN GRAPHE D’APPLICATIONS
>
>
> http://jim2016.gmea.net/actes
>
>
> (although in french)
>
>
> And in function here : http://faust.grame.fr/faustplayground/ when you
> export the final equivalent patch.
>
> Stéphane
>

very interesting, thanks for the pointers

>
>
>> Le 3 juil. 2016 à 00:20, Thomas Brand <[hidden email]> a écrit :
>>
>>
>> On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
>>
>>> Faust :  http://faust.grame.fr
>>>
>>>
>>
>> Faust was the first thing that came to mind indeed. The introduction
>> paragraphs in the documentation says
>>
>> -specification language
>> -describe signal processors from a mathematical point of view
>> -free from implementation details
>>
>>
>> But right after that:
>> -FAUST programs are fully compiled, not interpreted.
>>
>>
>> I can imagine to bundle FAUST code from different processors
>> semi-automatically or handcrafted to one unit relatively easily. However
>> i was thinking in a direction where the units live in a host still as
>> single units, to be connected in different ways, and the host would
>> dynamically derive a single math operation of the current graph. I
>> understand this would include recompilation or some kind of JIT
>> compilation in order to work. If possible at all, i think Faust would
>> currently be the best fit, since it already offers some of the
>> fundamental concepts needed to even think about doing something like
>> this. That would allow large graphs with almost no context switches
>> (this is pure speculation).
>>
>>
>> Greetings
>> Tom
>>
>>
>>>
>>>> Le 2 juil. 2016 Ã  22:58, Thomas Brand <[hidden email]> a écrit
>>>> :
>>>>
>>>>
>>>> Hi,
>>>> i wondered if the following scenario could work. Assuming DSP is
>>>> basically maths, and the formula and variables for every plugin
>>>> would be known, would it then be possible to magically simplify all
>>>> formulas of all plugins to one single formula doing all in one step?
>>>> Does this sound
>>>> weird? Greetings Tom
>>>>
>>
>>
>
>


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Evan Laforge
In reply to this post by Thomas Brand
Also this is interesting: http://halide-lang.org/  It's for images,
but just take away a dimension and it looks like audio.

Audio processing can be very data parallel so I'm surprised I haven't
seen any work related to audio on a GPU.  Maybe it's not so suitable
after all.

On Sat, Jul 2, 2016 at 3:24 PM, Thomas Brand <[hidden email]> wrote:

> On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
>> Faust :  http://faust.grame.fr
>>
>
> Faust was the first thing that came to mind indeed! The introduction
> paragraphs in the documentation says
>
> -specification language
> -describe signal processors from a mathematical point of view
> -free from implementation details
>
> But right after that:
> -FAUST programs are fully compiled, not interpreted.
>
> I can imagine to bundle FAUST code from different processors
> semi-automatically or handcrafted to one unit relatively easily. However i
> was thinking in a direction where the units live in a host still as single
> units, to be connected in different ways, and the host would dynamically
> derive a single math operation of the current graph. I understand this
> would include recompilation or some kind of JIT compilation in order to
> work. If possible at all, i think Faust would currently be the best fit,
> since it already offers some of the fundamental concepts needed to even
> think about doing something like this. That would allow large graphs with
> almost no context switches (this is pure speculation).
>
> Greetings
> Tom
>
> PS: jack-devel list added to reply
>
>>
>>> Le 2 juil. 2016 à  22:58, Thomas Brand <[hidden email]> a écrit :
>>>
>>> Hi,
>>> i wondered if the following scenario could work. Assuming DSP is
>>> basically maths, and the formula and variables for every plugin would be
>>> known, would it then be possible to magically simplify all formulas of
>>> all plugins to one single formula doing all in one step? Does this sound
>>> weird? Greetings
>>> Tom
>>>
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Paul Davis


On Sat, Jul 2, 2016 at 6:54 PM, Evan Laforge <[hidden email]> wrote:
Also this is interesting: http://halide-lang.org/  It's for images,
but just take away a dimension and it looks like audio.

Audio processing can be very data parallel so I'm surprised I haven't
seen any work related to audio on a GPU.  Maybe it's not so suitable
after all.

GPUs are very powerful and very parallel but the data pipe has poor latency for realtime audio. This hasn't changed in a decade. Maybe it will sometime.
 


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Paul Davis
In reply to this post by Thomas Brand


On Sat, Jul 2, 2016 at 6:24 PM, Thomas Brand <[hidden email]> wrote:
On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
> Faust :  http://faust.grame.fr
>

Faust was the first thing that came to mind indeed! The introduction
paragraphs in the documentation says

-specification language
-describe signal processors from a mathematical point of view
-free from implementation details

But right after that:
-FAUST programs are fully compiled, not interpreted.

I can imagine to bundle FAUST code from different processors
semi-automatically or handcrafted to one unit relatively easily. However i
was thinking in a direction where the units live in a host still as single
units, to be connected in different ways, and the host would dynamically
derive a single math operation of the current graph. I understand this
would include recompilation or some kind of JIT compilation in order to
work. If possible at all, i think Faust would currently be the best fit,
since it already offers some of the fundamental concepts needed to even
think about doing something like this. That would allow large graphs with
almost no context switches (this is pure speculation).

You are cordially invited to provide a faust implementation of 1 or more of the following:

   Ardour
   QTractor
   Bitwig/Live
   Kontakt
   FreqTweak
  
When done, for bonus points, convince the members of the plugin development communities to implement their work in Faust and make the Faust code available for refactoring by the sort of algorithm Stephane referenced in his reply.

There were plugin APIs long before JACK came along. JACK has very little to do with the lower level aspects of how to chain together DSP blobs (aka plugins) in arbitrary ways, and everything to do with how to connect applications together.

There are all kinds of cool ideas for how to do things inside a single process - Faust is one of them. The inter-application stuff is really a different ball of wax. Fons sounds as if he has some interesting insights there, but it would be hard to integrate them into any host that wants to be able to run without JACK.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Thomas Brand
On Sun, July 3, 2016 02:55, Paul Davis wrote:

> On Sat, Jul 2, 2016 at 6:24 PM, Thomas Brand <[hidden email]> wrote:
>
>
>> On Sat, July 2, 2016 23:14, Stéphane Letz wrote:
>>
>>> Faust :  http://faust.grame.fr
>>>
>>>
>>
>> Faust was the first thing that came to mind indeed! The introduction
>> paragraphs in the documentation says
>>
>> -specification language
>> -describe signal processors from a mathematical point of view
>> -free from implementation details
>>
>>
>> But right after that:
>> -FAUST programs are fully compiled, not interpreted.
>>
>>
>> I can imagine to bundle FAUST code from different processors
>> semi-automatically or handcrafted to one unit relatively easily. However
>> i was thinking in a direction where the units live in a host still as
>> single units, to be connected in different ways, and the host would
>> dynamically derive a single math operation of the current graph. I
>> understand this would include recompilation or some kind of JIT
>> compilation in order to work. If possible at all, i think Faust would
>> currently be the best fit, since it already offers some of the
>> fundamental concepts needed to even think about doing something like
>> this. That would allow large graphs with almost no context switches
>> (this is pure speculation).
>>
>>
>
> You are cordially invited to provide a faust implementation of 1 or more
> of the following:
>
> Ardour
> QTractor
> Bitwig/Live
> Kontakt
> FreqTweak
>
>
> When done, for bonus points, convince the members of the plugin
> development communities to implement their work in Faust and make the
> Faust code
> available for refactoring by the sort of algorithm Stephane referenced in
> his reply.
>
> There were plugin APIs long before JACK came along. JACK has very little
> to do with the lower level aspects of how to chain together DSP blobs (aka
>  plugins) in arbitrary ways, and everything to do with how to connect
> applications together.
>
> There are all kinds of cool ideas for how to do things inside a single
> process - Faust is one of them. The inter-application stuff is really a
> different ball of wax. Fons sounds as if he has some interesting insights
>  there, but it would be hard to integrate them into any host that wants
> to be able to run without JACK.
>

agreed, points taken.
Given that a processing graph doesn't change constantly (except in some
special cases), i'd imagine to kind of "freeze" the plugins setup to a
single instance to gain more room per cycle. Maybe this is just a pipe
dream. Having all involved DSP in a declarative text language instead of
BLOBs. Whole DAWs could be built like this. As i said, just a pipe dream
:)
Greetings
Thomas



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Harry van Haaren
On Sun, Jul 3, 2016 at 4:04 AM, Thomas Brand <[hidden email]> wrote:
Given that a processing graph doesn't change constantly (except in some
special cases),

But parts of the FX chain are often bypassed.
 
i'd imagine to kind of "freeze" the plugins setup to a
single instance to gain more room per cycle.

Can't freeze everything - because then you can't bypass...

And FAUST comes with one complication in this area  - there is no "turn off" switch.
To "bypass" something in FAUST, you compute it anyway, and then multiple the output by zero.
Although this works, it is not a viable solution for complex synths - Sorcer[1] only has 3 wavetables
because adding more means more CPU per voice.

Don't get me wrong - I really like FAUST, and it is extremely powerful for certain use cases - but building
DAWs or "configurable" audio processors is not one. Building DSP blocks that can be used by a DAW or
configurable audio processors is its strength - and its awesome for that.

Cheers, -Harry


--

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Fons Adriaensen-3
In reply to this post by Thomas Brand
On Sun, Jul 03, 2016 at 05:04:17AM +0200, Thomas Brand wrote:

> Given that a processing graph doesn't change constantly (except in some
> special cases), i'd imagine to kind of "freeze" the plugins setup to a
> single instance to gain more room per cycle. Maybe this is just a pipe
> dream. Having all involved DSP in a declarative text language instead of
> BLOBs. Whole DAWs could be built like this. As i said, just a pipe dream

Keep in that in all but the simplest algorithms, audio processing doesn't
just involve calculations on samples, but also logic, maintaining state,
and in general things that don't happen at the audio sample rate but have
their own independent timing which isn't regular and can't be predicted.
Faust isn't particularly good at any of that.

In theory all of that could be expressed in a 'formula', but the complexity
of such a formula will explode exponentially unless you express it as a
chain or graph of separete operations with no or limited interaction. And
then we are back where we started.

You may think that running the entire combined algorithm sample per sample,
avoiding all intermediate buffers, would be more efficient than having
separate modules which communicate by passing blocks of samples between
them. But that is NOT the case. Short loops using a small set of variables
make much better use of CPU registers and the cache, and will be faster.

In other words, even if it would practically possible to do what you
suggest, nothing will be gained, on the contrary.

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Fons Adriaensen-3
In reply to this post by Paul Davis
On Sat, Jul 02, 2016 at 08:55:04PM -0400, Paul Davis wrote:

> There are all kinds of cool ideas for how to do things inside a single
> process - Faust is one of them. The inter-application stuff is really a
> different ball of wax. Fons sounds as if he has some interesting insights
> there, but it would be hard to integrate them into any host that wants to
> be able to run without JACK.

Not at all, and this was even an explicit design goal.

I'll try to explain how this works.
There are three types of 'clients'. All three use essentially
the same API, only some options are different.

The first type is entirely equivalent to a Jack client as we
know it. It has a process callback and ports. Such clients
can run in parallel in same way as in Jack2, you can also
have more than one in a process, but that doesn't change
the way they are handled. Nothing new here.

The second and third types you'd use to create a complex
application consisting of an arbitrary graph of modules
in a single process, e.g. a DAW.

You first create an 'outer client'. Such a client has ports,
but it doesn't have a process callback. Instead it will
encapsulate the internal multithreaded scheduler of the
application. To the end user (e.g. in qjackctl) it just
looks like the first type.

Next you create the modules, which are the third type. The
open() just takes one additional parameter: a reference to
the outer client. Otherwise the API is exactly the same,
you define a callback and create ports. The difference
is that these ports are not visible externally. They can
be used (by the application code only) in two ways: you
can connect them to other internal modules, or map them
to a port of the outer client. By doing the latter the
module becomes visible to the outer scheduler (but not
to the end user). The outer and internal scheduler work
together in such a way as if there were only one, seeing
the entire combined graph. At the same time, everything
that can be handled by the internal scheduler will be
taken care of locally, without any additional overhead
or context switches.

Now if the application doesn't want to be a 'Jack client'
but e.g. use ALSA directly, it still uses an internal
scheduler with the same API, and instead of mapping
internal (module) ports to the externally visible ones
of the outer client, it maps them to channels of the ALSA
interface. To the end user it just looks the same. To the
application, the only difference is that all external
triggers will always arrive at the same time, at the
start of an ALSA period.

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Thomas Brand
In reply to this post by Fons Adriaensen-3
On Sun, July 3, 2016 11:52, Fons Adriaensen wrote:

> On Sun, Jul 03, 2016 at 05:04:17AM +0200, Thomas Brand wrote:
>
>
>> Given that a processing graph doesn't change constantly (except in some
>>  special cases), i'd imagine to kind of "freeze" the plugins setup to a
>>  single instance to gain more room per cycle. Maybe this is just a pipe
>>  dream. Having all involved DSP in a declarative text language instead
>> of BLOBs. Whole DAWs could be built like this. As i said, just a pipe
>> dream
>
> Keep in that in all but the simplest algorithms, audio processing doesn't
>  just involve calculations on samples, but also logic, maintaining state,
>  and in general things that don't happen at the audio sample rate but
> have their own independent timing which isn't regular and can't be
> predicted. Faust isn't particularly good at any of that.
>
>
> In theory all of that could be expressed in a 'formula', but the
> complexity of such a formula will explode exponentially unless you express
> it as a chain or graph of separete operations with no or limited
> interaction. And then we are back where we started.
>

it's a very theoretical thing indeed, with the premise that as long as a
plugin acts deterministically, it could be expressed as a formula (which
can get large/complex). That alone doesn't make it "better" or solve any
problem yet, easy to agree.

> You may think that running the entire combined algorithm sample per
> sample, avoiding all intermediate buffers, would be more efficient than
> having separate modules which communicate by passing blocks of samples
> between them. But that is NOT the case. Short loops using a small set of
> variables make much better use of CPU registers and the cache, and will be
> faster.
>
> In other words, even if it would practically possible to do what you
> suggest, nothing will be gained, on the contrary.
>

OK. Thanks for your insights Fons! As always much appreciated.

> Ciao,
>
>
> --
> FA
>
>
> A world of exhaustive, reliable metadata would be an utopia.
> It's also a pipe-dream, founded on self-delusion, nerd hubris
> and hysterically inflated market opportunities. (Cory Doctorow)
>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
>


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Stéphane Letz
In reply to this post by Fons Adriaensen-3

> Le 3 juil. 2016 à 11:52, Fons Adriaensen <[hidden email]> a écrit :
>
> On Sun, Jul 03, 2016 at 05:04:17AM +0200, Thomas Brand wrote:
>
>> Given that a processing graph doesn't change constantly (except in some
>> special cases), i'd imagine to kind of "freeze" the plugins setup to a
>> single instance to gain more room per cycle. Maybe this is just a pipe
>> dream. Having all involved DSP in a declarative text language instead of
>> BLOBs. Whole DAWs could be built like this. As i said, just a pipe dream
>
> Keep in that in all but the simplest algorithms, audio processing doesn't
> just involve calculations on samples, but also logic, maintaining state,
> and in general things that don't happen at the audio sample rate but have
> their own independent timing which isn't regular and can't be predicted.
> Faust isn't particularly good at any of that.

This is not by itself a limitation of this kind of approach : Faust (for now) is mainly designed to code synchronous mono-rate DSPs and the purpose of my previous mail was to explain that some categories of graphs where each node is coded in Faust can be automatically rewritten (and the compiled) into a single equivalent (possibly more efficient) node. No more no less.

>
> In theory all of that could be expressed in a 'formula', but the complexity
> of such a formula will explode exponentially unless you express it as a
> chain or graph of separete operations with no or limited interaction. And
> then we are back where we started.
>
> You may think that running the entire combined algorithm sample per sample,
> avoiding all intermediate buffers, would be more efficient than having
> separate modules which communicate by passing blocks of samples between
> them. But that is NOT the case. Short loops using a small set of variables
> make much better use of CPU registers and the cache, and will be faster.
>
> In other words, even if it would practically possible to do what you
> suggest, nothing will be gained, on the contrary.
>
> Ciao,
>
> --
> FA

The point can be : what kind of language and tools do we use to code our audio programs : the functional paradigm has some quality by itself that can help in some specific areas.

Stéphane


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Thomas Brand
In reply to this post by Harry van Haaren
On Sun, July 3, 2016 10:55, Harry van Haaren wrote:

> On Sun, Jul 3, 2016 at 4:04 AM, Thomas Brand <[hidden email]> wrote:
>
>
>> Given that a processing graph doesn't change constantly (except in some
>>  special cases),
>
>
> But parts of the FX chain are often bypassed.
>
>
>
>> i'd imagine to kind of "freeze" the plugins setup to a single instance
>> to gain more room per cycle.
>
>
> Can't freeze everything - because then you can't bypass...
>

"Freeze" would only affect the graph, not the parameters that are still
dynamic.

>
> And FAUST comes with one complication in this area  - there is no "turn
> off" switch. To "bypass" something in FAUST, you compute it anyway, and
> then multiple the output by zero. Although this works, it is not a viable
> solution for complex synths - Sorcer[1] only has 3 wavetables
> because adding more means more CPU per voice.
>

On/Off and Bypass would be parameters. I'm not sure i get the scenario you
describe, but "off" would be a switch at the front that doesn't do
anything with incoming data and does output a fixed zero while "bypass"
would act like a bridge, just feeding input to output (*1 if you like).


> Don't get me wrong - I really like FAUST, and it is extremely powerful
> for certain use cases - but building DAWs or "configurable" audio
> processors is not one. Building DSP blocks that can be used by a DAW or
> configurable audio processors is its strength - and its awesome for that.
>

DAW would be a set of widgets, controls and views  "orchestrating" the
blocks. I know that's too much simplified still not completely crazy to
think about IMHO.

>
> Cheers, -Harry
>
>
> [1] http://openavproductions.com/sorcer/
>
>
>
> --
>
>
> http://www.openavproductions.com
>
>


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: graph simplification using mathematics?

Stéphane Letz
>>
>> And FAUST comes with one complication in this area  - there is no "turn
>> off" switch. To "bypass" something in FAUST, you compute it anyway, and
>> then multiple the output by zero. Although this works, it is not a viable
>> solution for complex synths - Sorcer[1] only has 3 wavetables
>> because adding more means more CPU per voice.
>>

>
> On/Off and Bypass would be parameters. I'm not sure i get the scenario you
> describe, but "off" would be a switch at the front that doesn't do
> anything with incoming data and does output a fixed zero while "bypass"
> would act like a bridge, just feeding input to output (*1 if you like).
>
>
>> Don't get me wrong - I really like FAUST, and it is extremely powerful
>> for certain use cases - but building DAWs or "configurable" audio
>> processors is not one. Building DSP blocks that can be used by a DAW or
>> configurable audio processors is its strength - and its awesome for that.
>>

There is an experimental branch on Faust GIT called "master-with-mute » which allows to « dynamically bypass » computation of parts of the graph.


> DAW would be a set of widgets, controls and views  "orchestrating" the
> blocks. I know that's too much simplified still not completely crazy to
> think about IMHO.
>


Well in this community you have 1) lots of experienced C/C++ developers that have developed tools for years… with the power and limits of the kind of imperative languages they use. And you have 2) some crazy people that try (for years also..) to approach the problem with alternate visions, like  : how can functional languages help? How can dynamic compilation help? how can partial evaluation help ? (to name a few…)

Since people from 2) cannot solve everything for now at least, people from 1) say that in the end, you are going to have to use the good old tools to solve the problem… ((-;

But the 2) people stil think that for sure : this is not completely crazy to think about…

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org