Juhana K Kouhia wrote:
> >
> > aopcode integrate(asig x) {
> > asig y;
> >
> > y = y + x;
> > return(y);
> > }
> >
> > has to operate sample-by-sample to work right. Is there a
> > good way to make this work on a block-by-block basis?
>
> I see the problem only if x depends on the y outside of the integrator.
> If the x is N samples block and don't depend on y, then is the above the
> same than
> initialize y[]
> for(i = 0; i < N; i++) {
> y[i+1] = y[i] + x[i];
> }
> or such?
>
> Please, let me think about this even I may be wrong.
Yes, I think you're wrong. :) Your compiled-code example is correct,
but it's not the easiest code to generate for this case.
Think of the following code block:
asig w,x,y,z;
w = y + z; // 1
x = x + y; // 2
x = x + z; // 3
Line (1) can be block-by-clock; it can look like
for (i=0;i<ksmps;i++) w[i] = y[i] + z[i];
and this would be the desirable code.
But for line (2), you have the code you describe above
x[0] = lastx[ksmps-1] + y[0];
for (i=0;i<ksmps;i++) x[i] = x[i-1] + y[i];
And even though line (3) has the same structure as (2),
its semantics are like line (1):
for (i=0;i<ksmps;i++) x[i] = x[i] + z[i];
So we can't generate the right block-processing code from just the
semantics of the expression; we need to do a flow-analysis as
you describe below.
I think your flow-graph analysis is very correct; I've been thinking
about similar things. What I'm not yet sure about is whether there's
good "prototypes" (type 1,2,3 above) for all the feedback cases
which allow for block-based code in all circumstances.
Your shared BBB and SBS model will work, though, as a minimum.
Best,
-- Eric
-- +-----------------+ | Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7| |eds@media.mit.edu| < http://sound.media.mit.edu/~eds > | 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb| +-----------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:14:09 EDT