On 7/14/20, Dario Sanfilippo <sanfilippo.da...@gmail.com> wrote: > Hi, Till. > > I'll try to be more clear. > > I'm referring to a control-rate stepped stream as shown in Oleg's example, > where the actual work is performed only if the condition is true, as > opposed to a control-rate stepped stream of the kind that we sometimes > implement using, for example, sample-and-hold units within feedback loops. > > It is also related to what James suggested about having both a lazy and a > non-lazy if. > > In Oleg's code above, the calls per second to the sin function depend on > how many times per second the if-statement is true – the control rate. In > the second example that I describe, the number of calls to whatever > function or functions would be constant and but the values being out would > change based on the control rate. > > The clicks that I was referring to are not those coming from the stepped > stream, but from a hypothetical situation where the control rate is handled > with if-statements where you have enough CPU for low control rates, and not > enough CPU power for high control rates, resulting in audio drop-outs. > > So, personally, I'd always go for a network that always deals with the > maximum CPU requirements to be sure that it is safe in a live performance. > If you remember, I also expressed my concern when Stéphane, on Slack, > mentioned the development of a new primitive that would allow to turn off > the computation of some of the nodes in a network on-the-fly. > > Cheers, > Dario
Hi all, Thanks Oleg and Dario for weighing in. Thanks Oleg, in particular, for drawing attention to the control primitive. It seems that control behaves the same as sAndH implemented with select2. Is the only difference between them that one is implemented with ?: in the c code, and the other with if/else? Perhaps there are performance differences between these two, but it seems they would behave the same? I also couldn't see from a quick inspection the difference between control and enable, but no matter, peu importe. Anyway, I still feel that a short-circuiting conditional primitive would be a useful addition to the language. To be clear, by short-circuiting I mean one that only evaluates the branch it returns, even when the other branch has side effects. This could either be a variant of select2 or of control - in some ways control seems like a better fit. There is also the question of what such a primitive should be called. Something like lazy_control, or short_circuit_control, or just short_circuit? Ideally, it would be a name that would steer a beginner away from it, as the standard behaviour is what a user would probably normally want. If anyone is unconvinced of the value of such a primitive, I can try to describe a use case to make it clear, but for now I will only say that it would make faust much more suitable for algorithmic composition of the kind that Till is talking about, as well as granular synthesis. (This is also my primary use case for faust, so I had already been thinking along these lines before this thread.) I think I'll check out the faust source and see if I can make a start on writing some code for such a primitive. (Of course, I may find myself hugely out of my depth.) But I wonder again whether a patch/pull request for such a primitive would be accepted? Thanks, James _______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
