On Sun, Jul 3, 2016 at 4:04 AM, Thomas Brand <tom(a)trellis.ch> wrote: But parts of the FX chain are often bypassed. 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 [1] http://openavproductions.com/sorcer/ -- http://www.openavproductions.com

There is an experimental branch on Faust GIT called "master-with-mute » which allows to « dynamically bypass » computation of parts of the graph. 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

On Sun, July 3, 2016 11:52, Fons Adriaensen wrote: 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. OK. Thanks for your insights Fons! As always much appreciated.

On Sat, Jul 02, 2016 at 08:55:04PM -0400, Paul Davis wrote: 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)