That looks really nice! - Julius
On Fri, Aug 7, 2020 at 12:31 PM Yann Orlarey <orla...@grame.fr> wrote: > 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 > -- "Anybody who knows all about nothing knows everything" -- Leonard Susskind
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
