Hi, A *very* experimental implementation of the ondemand primitive is available here :
https://github.com/grame-cncm/faust/tree/experimental-ondemand The implementation is currently only available for -lang ocpp in scalar mode. Here are some simple examples : Once the branch installed here are some command you can use to test: faust2csvplot -lang ocpp test.dsp faust -svg -lang ocpp test.dsp ./test -n 20 t01 = 1 : ondemand(1:+~_); // 1 2 3 4 5 ... t02 = clock(2) : ondemand(1:+~_); // 1 1 2 2 3 3 ... t03 = clock(2) : ondemand(t01); // 1 1 2 2 3 3 ... t04 = clock(2) : ondemand(no.noise); // 5.74858859e-06 5.74858859e-06 -0.344845951 -0.344845951 t05 = no.noise, (clock(2) : ondemand(no.noise)); // same noise but at different rates t06 = no.noise, (clock(2), no.noise : ondemand(_)); // ondemand(_) is Sample and Hold! t07 = clock(2) : ondemand(t06); // cascading ondemands Have a look at the generated block-diagram to see how P is transformed in ondemand(P). In a future version, the clock signal values could be higher than 1, for upsampling. We should then have a fairly general multi-rate system... 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. 13 août 2020 à 23:08, Yann Orlarey <orla...@grame.fr> a écrit : > Hi James, > > Thanks for your suggestions. I need to read this more carefully, but can > you elaborate on "The proposed ondemand helps somewhat with 1, and not at > all with 2 or 3."? > > From my side, a more complete description of ondemand: > https://drive.google.com/file/d/1LkT8KviWocnzt6hqRsLlSri5uwVDWI5p/view?usp=sharing > with a new section on combining on-demands. > > 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 mer. 12 août 2020 à 14:20, James Mckernon <jmcker...@gmail.com> a > écrit : > >> ondemand looks cool, Yann; thanks for writing that up. >> >> I guess it's worth breaking down what makes demand ugens in SC nice to >> work with. I can think of three properties worth discussing: >> >> 1. As already discussed, they respond with a new value when their >> trigger input is nonzero and reset their state when their trigger >> input is nonzero. >> 2. They embed child demand elements in their stream. (Actually, it's >> been a long time since I worked with them, and I'm just going from >> memory, so I'm not sure about this point. Perhaps Til can correct me >> if I'm wrong.) That is, DSeq([DSeq([1, 2]), DSeq([3, 4])]) will yield >> 1, 2, 3, 4 - i.e. all elements are requested from the first child DSeq >> before requesting one from the second. >> 3. They propagate values sent to their trigger/reset inputs. i.e., >> when triggered, a demand ugen will trigger its active child demand >> ugen; when reset, it will reset all of its children. >> >> So 1 relates to how they behave in isolation, and 2/3 are about how >> they behave when nested. (I'm not sure, but I don't think 3 is useful >> without 2.) 2 and 3 are cool, but to get them working in faust seems >> complex, maybe too complex (though I have been thinking of ways to >> achieve it). Nonetheless, 1 is useful enough on its own that I believe >> it would be worthwhile even without 2/3. The proposed ondemand helps >> somewhat with 1, and not at all with 2 or 3. >> >> Although a general-purpose ondemand signal transformer (as in the >> proposed primitive) would make things easier in some respects, it >> seems to me (I wonder whether others will agree) that it is best to do >> this with the simplest tools available. (I suppose I am thinking of >> the 'rule of least power': >> https://en.wikipedia.org/wiki/Rule_of_least_power .) In other words, >> if it is possible to implement most of what one would want from a >> demand-rate processor with existing language constructs, it is >> probably better to do so than to implement a new language construct >> for this case. >> >> I have been sketching out some code implementing a couple of >> demand-rate ugens which I intend to post this weekend. (Not including >> the embedding behaviour, i.e. 2/3 above.) The specific ugens from SC >> that seem to me most useful and practical to implement are DSeq, >> DSeries, DRand, DWhite, and DWRand. (Til, if you (or anyone else) have >> any suggestions for other particular demand-rate ugens from SC which >> would be good to have in faust then let me know.) >> >> I would be interested to hear anyone's thoughts on the above. >> >> Cheers, >> James >> >> >> On 8/7/20, 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> >> >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
