DSP Robotics Support

Did not find this filter listed here so, attached is a schematic which tries to implement this paper by using (maybe) not so common coefficient calculation method. Coefficients are packed to degree 7 polynomials and then restored for processing by sample rate in use. For sake of less coding needed, one could turn these polynomials to use some other form.

Restoring accuracy is R^2=1 (OOCalc) and if accuracy isn't important (say R^2=~0.99999999.... is enough), coefficients for HSF and half of LPF could be restored by using simple linear interpolation equations (a*x+c).

This should be much faster way than what normal calculation method would be (I have tested only few calculations of coefficients using GCC and found out that calculation of one degree 7 polynomial takes about 1/3 of the time what it would take from a std::sin() call.

Q: Should there be some added delay somewhere?
Q: How to test/compare execution speed inside FS
Q: Is my Ruby code portable for DSP code component (now that it don't need condition checking)?

EDIT: Here are alternative coefficients (R^2 = ~0.999999999) for HSF filter implementation :

This could be a solution looking for a problem. Keep in mind Linkwitz wrote that paper in the early '60s, when exaggerated-panning ping-pong stereo was all the rage; very few recordings are mixed that way anymore - with sounds panned hard left or right.

I would not worry about calculating the coefficients this or that way - it is done only once, after all.
The DSP part is not very CPU demanding as it is but if you want to make it leaner I would suggest a TDF2 topology instead of the direct form in your schematic. Various filter forms are explained here. Further optimization would be possible going assembly.

One more thing: recursive filters need some sort of denormal prevention, refer to viewtopic.php?f=4&t=2808&p=14873

k brown wrote:This could be a solution looking for a problem. Keep in mind Linkwitz wrote that paper in the early '60s, when exaggerated-panning ping-pong stereo was all the rage; very few recordings are mixed that way anymore - with sounds panned hard left or right.

Yes, it's old paper but, lots of people still listen those old recordings... .

martinvicanek wrote:I would not worry about calculating the coefficients this or that way - it is done only once, after all.
...

Good to know, I thought that streamin type input in DSP code means that ruby code is looped continuously so that sample rate change becomes noticed? BTW, how is that sample rate taken in to ruby component since coding x= @fs results 'NoMethodError' (target is VST)?

Would it be different if all that math in Ruby box is done in DSP code component?

Also, I'm just testing this method to calculate coefficients because of it might help using matched response filters at same speed or even faster than common filters (as like RBJ and MZT) even when parametrized in real time.

juha_tp wrote:I thought that streamin type input in DSP code means that ruby code is looped continuously so that sample rate change becomes noticed?

"Green" and Ruby components recalculate only when events are received at their inputs (i.e. from the left-hand side). In this case (and given also the advice below), the Ruby will recalculate only at the following times...
- When the VST host or soundcard reports a change of sample-rate.
- When the schematic or plugin is loaded.
- When the Ruby code is edited.

juha_tp wrote:how is that sample rate taken in to ruby component

There are three ways...

- When, as here, there is only a single Ruby input, its value can be obtained from @in.

- Multiple inputs are held in an array, accessed as @ins[0], @ins[1], @ins[2], etc...

- R-click the input, and select "N" from the context menu - you can now give the input a name (the name must contain only alphabet, number, and underscore characters, and must begin with an alphabet character). You can then access its value using @name. NB: Once in "naming mode", you can TAB through the inputs (and outputs) to name many in one editing session. Each input/output must have a unique name, of course!

Thanks!