DSP Robotics Support

on way this could be easier to debug was if the wire that by the interpreter is considered the feedback/'one sample delay' was colored/marked different than the regular wires. atleast one could see the flow more clearly.

tor wrote:on way this could be easier to debug was if the wire that by the interpreter is considered the feedback/'one sample delay' was colored/marked different than the regular wires. at least one could see the flow more clearly.

That is not possible because flowstone probably doesn't even know there is feedback.
the schematic is being rewritten into code that may not have to correspond with intuitive routing. You can check the code generated using Analyzer primitive (It's pretty though figuring out what is what). To some degree you can affect the code order with link order, but with DP streams that is very limited (as DP primitives can take only one variable to one input). We might force the right execution order by forcing empty streams (containing only bitwise zeroes) on the DP primitives. It will affect the performance in a negative way though.
It would all be much easier if we had more complete list of Assembly instructions (including SSE2 integer and double-precision instructions). The absence of many even basic instructions (for example unconditional jump - jmp;) in assembler is very awkward and annoying.

A comparison of tor's DP filter with the SP code version shows that the outputs agree with a relative error of < 1e-5 (or < -100 dB), in most cases even 1e-6 which is close to the 24 bit resolution limit. So I am not sure if DP is really worth the trouble for this filter type (it may be well justified for the direct forms).

By the way, tor, the DP implementation of the allpass and shelving filters seems to be slightly incorrect (all others are OK).

Sorry about the bad DP version, I found the error quite quickly. As always I tend to fiddle with FS when I'm tired. It is now fixed (i think).

Thanks tor, also for including the phase plot. It revealed a bug in the allpass filter that I posted on page 3 of this thread, now fixed there. Unfortunately that bug propagated into your design, so if you want to fix that it is
Allpass = Lowpass + Highpass - Bandpass2
(note the minus sign).
That makes two of us tired when posting, I guess.

He he

*Edit: Luckily we are just humans

Now it would be great if we could sort out this OS DP version, here reduced to a simple LP to ease the confusion of to many wires. If we get this right we have all the best options awailable for our designs.

Can a butterworth filter be implemented as ZDF?

I guess so, it is actually what is posted all over this thread.

A 2nd order Butteworth filter is simply one with Q=0.71. For higher orders use a cascade with different Qs and same cutoff frequencies. Here is a lowpass example.