Hi All, I thought I would mention that, according to my experience, the "real-time signal processing way" is to define @(-1) and all other "negative delays" as a delay of zero, i.e., negative delays simply "clip" to 0. The "offline signal processing way" would be to access the future noncausally and actually support negative delays up to the available buffering limit. I personally think Faust should stay in the "real time" paradigm and not offer this. One could also argue for "wrap around" in the delay buffer, for things like phase modulation of a wave table oscillator, but that's already handled easily enough by an address mask, so I would not advocate for that either. I do think clipping to zero at runtime is better than a compiler error (although a "clipping" warning makes sense in this static case).
Cheers, - Julius On Mon, Sep 10, 2018 at 12:53 AM Oleg Nesterov <o...@redhat.com> wrote: > > On 09/09, yann orlarey wrote: > > > > Hi Oleg, > > > > `process = @(2) : @(-1);` is incorrect because `@(-1)` is incorrect. > > '@(-1)' is incorrect per se, but '@(2) : @(-1)' used to work and imo it was > useful. Say, > > tkeoN(n) = @(n) <: ^(2) - @(0+n)*@(0-n); > > > The > > optimisations made by the compiler should not change the correctness of the > > compiled program. > > Well, optimisations is very important part of faust ;) > > this code > > process = @(ba.time - ba.time); > > or this > > process = @(ba.time * 0); > > is correct. Now it can't be compiled too, by the same reason. > > Again, I do not pretend I understand faust internals, but it seems that we > can simply remove the interval checks in infereSigType(); if interval is not > valid or lo < 0 checkDelayInterval() should notice the problem later? > > > Therefore I think the current behavior of the compiler is > > the right one. > > I can't argue, but to me this looks as unfortunate pessimization. > > Oleg. > > > > _______________________________________________ > Faudiostream-users mailing list > Faudiostream-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/faudiostream-users -- Julius O. Smith III <j...@ccrma.stanford.edu> Professor of Music and, by courtesy, Electrical Engineering CCRMA, Stanford University http://ccrma.stanford.edu/~jos/ _______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
