DSP Robotics Support

OH, now I see it... that is very weird... I don't know where the problem could be...

big credit for trying. thank you!

Now this is strange too, simply by changing order of the subtractions on the first line of code (and the equal in next part) change the behaviour of the filter. It should have the same output as before but it does not.

Probably the math skills in the execution order.
Also notice there is no differentiation "probably"

As with the strage behaviour in the first place it is just close to nyquist there is difference with the reordered version. The math and order in both examples are correct.

Yes, that's really weird. But why would you want double precision in the first place? There may be a point with the direct forms, but I don't think it is an issue with this filter type.

martinvicanek wrote:Yes, that's really weird. But why would you want double precision in the first place? There may be a point with the direct forms, but I don't think it is an issue with this filter type.

double precision is always welcome.... if nothing else then as an marketing strategy...

I must admit i have not made measurements with this filter but as martinvicanek said there is a significant difference with direct form filters. Any feedback structure produce rounding errors and noise, and with direct forms you get a "thighter" and a more stable low frequency response with double precision. My goal is simply to squeeze the most quality i can out of this.

I sure would like to know why my implementation does not work

tor wrote:I sure would like to know why my implementation does not work

I think it has to do with the feedback topology and the way how FS evaluates loops. The following three examples illustrate the point.

The first schematic shows a loop with a gain factor 1/2 and a unit delay. The output shows a geometric progression as it should, where each sample has half the value of the previous sample. The Impulse primitive is there to start off the series.
So far so good. Now consider the second schematic: still a loop with gain factor 1/2 and unit delay, only the order of the two primitives is reversed. You would expect the same result, but it is not so. Apparently there is a 2 samples delay in the loop! That reminds me of tor's finding, where a trivial change of the order of operations led to a different result.
In the next schematic I have removed the unit delay from the feedback loop altogether. This is something that should not be permitted, however FS somehow adds a unit delay into the feedback path and the result is the same as in the first example.
Now you could argue that examples 2 and 3 are consistent, but then example 1 does not fit in. (I prefer to think that example 1 gives the expected result while 2 and 3 do not.)

Okay, so in tor's filter schematic there are at least two feedback loops which behave in a similarly uncontrolled way. I have spent quite some time experimenting with unit delays inserted at various places, however I have not been able to get it right. So my conclusion is to avoid wiring loops in FS, as it can lead to unpredictable results even in very simple cases (refer to above examples). If you must have loops, use code. The stages 0 to 3 offer some control which is missing when only wiring primitives.

good work and thank you for providing this good investigation. never occured to me to test it like that.

the manual states that any feedback wiring of stream/poly automatically makes a one sample delay. so in the examples with the delaymodule one should actually get two samples delay. so your example loop2 and loop3 is as one should expect. but example loop1 is the mysterie loop. it clearly shows there is some inconsistency in how the interpreted code is generated. this inconcistency makes it impossible to make designs with a predictable result. and the more complex it gets the harder it is to debug.

as FS do not provide all necessary double word upcodes in asm to do this and the code module does not provide any double word functions it is impossible to do this with code.

some times i think maybe the limitations and flaws in FS/SM is there deliberately to hinder competition for the "real" developers that use this app just as an mockup/test enviroment. i sent a mail to support many days ago, no answer so far. i wonder about all the people who paied for 1 year of updates they must be very disappointed when support and updates are so absent. so many bug reports and feature wishes that probably is quite easy fixed is just ignored.

sorry, i just had to get this little blowout