Hi Till, Thanks for the offer! Could you explain in a few words how demand-rate works in supercollider? 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 sam. 1 août 2020 à 18:29, Till Bovermann <lf...@lfsaw.de> a écrit : > dear list, yann, james, > > this is exciting news indeed! i think, faust will substantially benefit > from an on-demand evaluation possibility. i am very happy to help with my > experiences as a long-term supercollider user and developer. it might be > interesting to look at the implementation of demand-rate ugens in sc3, > especially the possibility to reset pattern generating engines. > > all the best > till > > On 31. Jul 2020, at 21:40, Yann Orlarey <orla...@grame.fr> wrote: > > > 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 > >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
