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
