Hi Till, Thank you very much for your detailed answer. It's very helpful. On my side, I tried to formalize my ideas for an on-demand primitive. A description is available here: https://drive.google.com/file/d/1mEKkW3fKl9Ik8zsClxMzlMWKBjGl-teK/view?usp=sharing. This is still very partial and many aspects remain to be detailed...
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 mer. 5 août 2020 à 14:06, Till Bovermann <lf...@lfsaw.de> a écrit : > Dear Yann, > > > I can try... > > In SC, a demand-rate UGen graph is encapsuled into one of (currently) > three different UGens: > > Demand.ar/kr > Duty.ar/kr > TDuty.ar/kr > > Their functionality vary marginally (triggered execution/execution every > `dur` secs, etc.). > > Each of them has three slots: > > 1. update input — either a trigger (Demand) or a Demand-rate UGen / scalar > (duration, Duty/TDuty) > 2. reset input — if value passes from neg to pos, reset the value stream > to initial conditions > 3. value stream — a Demand-rate UGen graph > > > Demand-rate UGens are UGens that calculate their values every time they > are triggered to do so from the outside, read more elaborate descriptions > on this here: > > http://doc.sccode.org/Classes/Demand.html > and > http://doc.sccode.org/Classes/Duty.html > > > internally, the wrapper-UGens (Demand et al) implement the following > behavior: > > ``` > if reset: > call `next(nan)` on Demand-UGen in demand chain, this makes it > reset. > else if call for next value: > calculate how many values are needed for the current block (N) > ask for N values from demand chain by providing > else: > keep last value (Demand/Duty), or 0 (TDemand) > ``` > > > A demand-rate UGen with parameters in its param-slots does this if its > next function is called: > > ``` > if numSamples == nan: > for each UGen in param-slots: > call `next(nan)`, this makes it reset. > reset myself > else: > for each UGen in param-slots: > call next(numSamples) and collect values in array > compute numSample output based on parameters > ``` > > All relevant source code for the implementation is here: > > > https://github.com/supercollider/supercollider/blob/develop/server/plugins/DemandUGens.cpp > > > hope this helps and I did not make too many errors... > Till > > -- > Till Bovermann > > https://tai-studio.org | http://lfsaw.de | > https://www.instagram.com/_lfsaw/ > > > > > > > > > > > > > On 2. Aug 2020, at 18:40, Yann Orlarey <orla...@grame.fr> wrote: > > > > 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 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 | instagram | twitter > > > > > > 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 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 | instagram | twitter > >> > >> > >> 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
