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> Le sam. 25 juil. 2020 à 19:27, James Mckernon <jmcker...@gmail.com> a écrit : > Hi all, > > Just wanted to post some findings in relation to control, as discussed > above. > > I tested today the latest version I could get hold of from the faust > git repo (e11a0156a, looks like version 2.28), and I found that... > control does indeed work in the way I described earlier in this > thread! That is, it only evaluates its contents (in particular, their > side effects) when its trigger is nonzero. I'm not sure if this is a > change since that discussion, or if I just wasn't testing then on a > recent enough version, or if I was hitting a bug (see below), but this > did not appear to be the case when I tested it before. > > To demonstrate this behaviour, here is a a counter which we enable > with control every second sample. It really is only evaluated when > it's triggered, so the side effect (decrementing its internal > variable) only happens then. As a result, each value is output for two > samples, as desired: > > import("stdfaust.lib"); > process = control(-(1)~_, ba.time : %(2) : ==(0)); // -1, -1, -2, -2, > -3, -3, ... > > But there is a bug here, I guess the same one that Oleg points out. I > believe this is probably what confused me before: > > import("stdfaust.lib"); > process = control(+(1)~_, ba.time : %(2) : ==(0)); // 1, 2, 3, 4, ... > > In this case the counter is incremented every sample because the > compiler detects +(1)~_ as a duplicate of the same expression inside > ba.time, and optimises the process by letting them share the same > calculation, even though one of them should always be calculated and > the other should not. It seems that expressions inside a > control/enable should not be eligible for this optimisation. I will > probably file a bug report for this on github. > > I haven't yet really tested how this works with vectorisation and the > various architectures. (Personally, I am most interested in using it > with faust2faustvst and faust-live.) > > But Til, I believe this means you could use control to build something > analogous to demand-rate structures in SC. Let me know if you would > like a hand converting a simple example. > > Cheers, > James > > > _______________________________________________ > 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
