Hi, After these exchanges, I am quite convinced of the interest of having on-demand computation in Faust!
As I said in my previous email, it can't be the current control primitive. It must actually be an operation on signal processors, not an operation on signals. The challenge is to find a primitive that keeps the simple and well-defined semantics of Faust. I started to think about this and sketched an `ondemand(P)` primitive that transforms a P processor into an equivalent on-demand version with an extra clock input. This is all very preliminary, but for those interested, my notes are here https://photos.app.goo.gl/UTHpYfz5q1oe4CRV7, although I doubt it would be understandable to anyone but me ;-) If you have specific use cases and examples to feed the reflection, it would be helpful to us... Cheers Yann *Yann Orlarey* Directeur scientifique/Scientific director orla...@grame.fr <x...@grame.fr> T : +33 (0) 4 72 07 37 00 GRAME - Centre national de création musicale 11 cours de Verdun Gensoul | 69002 Lyon www.grame.fr | facebook <https://www.facebook.com/Gramelyon/> | instagram <https://www.instagram.com/grame_cncm/> | twitter <https://twitter.com/GRAME_LYON> Le jeu. 30 juil. 2020 à 13:17, James Mckernon <jmcker...@gmail.com> a écrit : > Hi Yann, > > Thanks for clarifying your position regarding control and enable, and > their intended use. > > I understand that control poses certain semantic complications. > However, I would also respectfully suggest that a (properly-working) > control primitive would be a powerful addition to the language, which > could perhaps justify such complications. (Indeed, it would be at the > top of my 'wish list' for faust features.) It would make faust an > excellent tool for algorithmic composition. I understand that this is > not a primary focus of the faust project, but the possibility of being > able to use faust to describe not only sample-level DSP but also > higher-level control structures is very appealing to me. > > Given your position, I do not expect anyone to fix the above issues > with control's semantics. However, perhaps I can persuade you not to > remove it? :) I am also considering trying to write a patch myself to > fix those issues - if I ever finish such a patch, I would be grateful > if it could be considered for inclusion. > > Nonetheless, I of course respect the right of the faust developers to > steer faust as seems best to them, with or without whatever primitives > they choose. > > Many thanks, > James > > > On 7/30/20, Yann Orlarey <orla...@grame.fr> wrote: > > Hi James, > > > > We discourage the use of the primitive "control" that we plan to remove. > As > > you reported, "control" poses many semantic problems. In reality, this > > primitive was essentially intended for internal use, in the compilation > of > > the experimental "enable" primitive (enable(x,y) -> control(x*y, y!=0)) > and > > it should never have been made public. > > > > The experimental enable(x,y) primitive has, approximately, the semantics > of > > x*y. But it allows to disable the computation of x when y is 0 (and if x > is > > not used in other circumstances). Enable therefore can save CPU in some > > circumstances. But this primitive must be used with great care. In > > particular, it is the responsibility of the programmer to ensure that his > > use of enable(x,y) behaves as much as possible like x*y. > > > > Cheers > > > > Yann > > > > > > *Yann Orlarey* > > Directeur scientifique/Scientific director > > > > > > orla...@grame.fr <x...@grame.fr> T : +33 (0) 4 72 07 37 00 > > GRAME - Centre national de création musicale > > 11 cours de Verdun Gensoul | 69002 Lyon > > www.grame.fr | facebook <https://www.facebook.com/Gramelyon/> | > instagram > > <https://www.instagram.com/grame_cncm/> | twitter > > <https://twitter.com/GRAME_LYON> >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
