Dear Dario,
this makes it easier for me to understand, thanks for clarification!
Till
--
Till Bovermann
https://tai-studio.org | http://lfsaw.de | https://www.instagram.com/_lfsaw/
> On 14. Jul 2020, at 22:36, 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
>
> On Tue, 14 Jul 2020 at 15:09, Till Bovermann <lf...@lfsaw.de> wrote:
> Dear Dario,
>
> I do not really understand the difference of the two, or why the second
> ("computed but not used") makes sense... since the computation in between
> state changes (to my understanding) should (by definition) not change, there
> would not be any difference to the first case... of course, interpolation
> between steps need (and could be) calculated with e.g. linear interpolation
> _after_ the demand-rate signal computation, in case one would not want to
> have "clicks"...
>
>
> do I understand you correctly?
>
> cheers
> Till
>
>
> > On 14. Jul 2020, at 15:00, Dario Sanfilippo <sanfilippo.da...@gmail.com>
> > wrote:
> >
> > Hello, dear Oleg and Till.
> >
> > From the perspective of a composer/performer who works with live audio, and
> > considering that Faust is intrinsically real-time, would it make sense to
> > have two control primitives, one where computation is skipped when it is
> > not requested, and one where it is computed but not used?
> >
> > I would find the second case useful as it would always require maximum
> > computation and the control rate could be changed on-the-fly without
> > worrying about clicks, provided that no clicks occurred at audio-rate
> > calculations.
> >
> > Best,
> > Dario
> >
> >
> > On Tue, 14 Jul 2020 at 13:43, Oleg Nesterov <o...@redhat.com> wrote:
> > On 07/14, Till Bovermann wrote:
> > >
> > > Thanks also to you, Oleg; is there somewhere an example for the control
> > > primitive,
> >
> > Sorry, I do not know. But see below.
> >
> > However, I did "git pull" and it seems that "control/enable" are already
> > supported in FIR scalar mode. Probably the commit 32846af52e92498? Cool.
> >
> > Say,
> >
> > process = control(sin, _);
> >
> > compiles to
> >
> > virtual void compute(int count, FAUSTFLOAT** inputs, FAUSTFLOAT**
> > outputs) {
> > FAUSTFLOAT* input0 = inputs[0];
> > FAUSTFLOAT* input1 = inputs[1];
> > FAUSTFLOAT* output0 = outputs[0];
> > float fTemp0 = fTempPerm0;
> > for (int i = 0; (i < count); i = (i + 1)) {
> > if (float(input1[i]) != 0.0f) {
> > fTemp0 = std::sin(float(input0[i]));
> > }
> > output0[i] = FAUSTFLOAT(fTemp0);
> > }
> > fTempPerm0 = fTemp0;
> > }
> >
> > note that sin(input0[i]) is only evaluated if input1[i] != 0.
> >
> > Oleg.
> >
> >
> >
> > _______________________________________________
> > 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
