Hi Till,

This is what the compiler does for pure generators like 1:+~_ or noise. It
inserts information about the clock into the code, so as to differentiate
between the internal states of ondemand(1:+~_) and 1:+~_. But for an
external function, we don't have access to its internal state. And this one
evolves at each call. So, it is up to the user to provide separate
versions. But of course, the compiler should at least be able to report the
problem...

Cheers

Yann


Le sam. 22 août 2020 à 17:35, Till Bovermann <lf...@lfsaw.de> a écrit :

> Hello,
>
>
> this looks awesome!
>
> regarding the below example by Oleg/Yann; wouldn't it make sense that, if
> such a case is detected, to split the computation intop two seprate paths,
> i.e.
>
>
> sig = x0, x1, x2, ... .
> clk = 1,0,1,0,1,0,1,0,....
>
> (clk : ondemand(sig)) => (clk : ondemand(sig_demand_1)) -> x0, x0, x1, x1,
> x2, x2, ...
>                  sig ->  x0, x1, x2, x3
>
>
> ?
>
> --
> Till Bovermann
>
> https://tai-studio.org | http://lfsaw.de |
> https://www.instagram.com/_lfsaw/
>
>
>
>
>
>
>
>
>
>
>
> > On 21. Aug 2020, at 22:31, Yann Orlarey <orla...@grame.fr> wrote:
> >
> > Hi Oleg,
> >
> > Thank you for your example. It is very interesting because it shows that
> it is now possible to write pathological Faust programs that cannot be
> executed (without infinite memory)!
> >
> > Sig, having no input, therefore represents a signal, for example: x0,
> x1, x2, ... . Similarly clk, say: 1,0,1,0,1,0,1,0,....
> >
> > Therefore, to produce simultaneously:
> > (clk : ondemand(sig))-> x0, x0, x1, x1, x2, x2, ...
> >                  sig -> x0, x1, x2, x3
> > we need to store an infinite amount of sig values!
> >
> > Clearly, the Faust compiler has to detect this kind of case and report
> an error...
> >
> > Cheers
> >
> > Yann
> >
> > Le ven. 21 août 2020 à 18:13, Oleg Nesterov <o...@redhat.com> a écrit :
> > Hi Yann,
> >
> > On 08/21, Yann Orlarey wrote:
> > >
> > > A *very* experimental implementation of the ondemand primitive is
> available
> > > here :
> > >
> > > https://github.com/grame-cncm/faust/tree/experimental-ondemand
> > >
> > > The implementation is currently only available for -lang ocpp in scalar
> > > mode. Here are some simple examples :
> >
> > Am I understand correctly? Currently
> >
> >         process = (clk : ondemand(sig));
> >
> > acts the same as
> >
> >         process = control(sig,clk);
> >
> > right?
> >
> >
> -------------------------------------------------------------------------------
> > and it seems it has the same problem:
> >
> >         clk = ffunction(int clk(), "","");
> >         sig = ffunction(float sig(), "","");
> >
> >         process = (clk : ondemand(sig));
> >
> > compiles to
> >
> >         virtual void compute (int count, FAUSTFLOAT** input,
> FAUSTFLOAT** output) {
> >                 //zone1
> >                 //zone2
> >                 float   fTemp0 = fTempPerm0;
> >                 //zone2b
> >                 //zone3
> >                 FAUSTFLOAT* output0 = output[0];
> >                 //LoopGraphScalar
> >                 for (int i=0; i<count; i++) {
> >                         if (clk()) {
> >                                 fTemp0 = sig();
> >                         }
> >                         output0[i] = (FAUSTFLOAT)fTemp0;
> >                 }
> >                 fTempPerm0 = fTemp0;
> >         }
> >
> > and this looks correct. However,
> >
> >         process = (clk : ondemand(sig)), sig;
> >
> > results in
> >
> >         virtual void compute (int count, FAUSTFLOAT** input,
> FAUSTFLOAT** output) {
> >                 //zone1
> >                 //zone2
> >                 //zone2b
> >                 //zone3
> >                 FAUSTFLOAT* output0 = output[0];
> >                 FAUSTFLOAT* output1 = output[1];
> >                 //LoopGraphScalar
> >                 for (int i=0; i<count; i++) {
> >                         float   fTemp0 = sig();
> >                         output0[i] = (FAUSTFLOAT)fTemp0;
> >                         output1[i] = (FAUSTFLOAT)fTemp0;
> >                 }
> >         }
> >
> > and this doesn't look right...
> >
> > Thanks!
> >
> > 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

Reply via email to