Hi, Two consecutive delay lines `@(n):@(m)` are now only merged if `n` is constant.
Yann Le lun. 8 oct. 2018 à 13:43, Yann Orlarey <orla...@grame.fr> a écrit : > Hi Oleg, > > You are right, `@(n):@(m)` is equivalent to `@(n+m)` only if `n` is > constant. We must test this condition before merging the delay lines. > Thanks (again) for discovering the problem... > > Yann > > > ------------------------- > > Yann Orlarey > Directeur scientifique > www.grame.fr > > > > > Le dim. 7 oct. 2018 à 16:02, Oleg Nesterov <o...@redhat.com> a écrit : > >> normalizeFixedDelayTerm() does >> >> if (isSigFixDelay(s, x, y) >> return normalizeFixedDelayTerm(x, simplify(sigAdd(d, y))); >> >> but this is only correct if both d and y have computability() < kExec. >> >> IOW, the (x@n)@m = x@(n+m) comment is wrong otherwise, in general >> (x@n)@m is equivalent to x@( n@m + m ), so I think that faust should >> actually create another delay line for @m if n or m is not constant, >> >> OK, I'm afraid my explanation is confusing and not convincing, let me >> provide a test-case. >> >> z1 = ro.cross(2) ~ _ : !,_; >> >> simply reimplements the mem() primitive but always creates xRec line. >> Now, >> any_signal <: mem : z1 :> -; >> >> should always output 0, no matter what "any_signal" actually does. >> However, >> >> z1 = ro.cross(2) ~ _ : !,_; >> delay = sin(no.noise) + 1 : *(10) : int; >> process = ba.time : @(delay) <: mem, z1; >> >> doesn't output the same value in output0/output1, and this is not >> actually right, I think. >> >> Not that I think this is really bad, this case is exotic and perhaps >> can be ignored, but still. >> >> Oleg. >> >>
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users
