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
