What if the Feedback Loop Element had a Variable Time

[dscro]

This is one for anyone who has looked at the SB code and is willing to try and modify it. It seems that it would be fairly easy to allow the feedback element to offer a variable time right down to the individual sample time, instead of the 0.01 sec fixed value currently offered. This, for me, has always been a significant limitation keeping me from, among other things ,creating a running sum - basically performing integration - from sample to sample (although I think I can use a feedback comb filter for that application).

Is anyone willing to look at the code and change this?

[eigentone]

This is one for anyone who has looked at the SB code and is willing to try and modify it. It seems that it would be fairly easy to allow the feedback element to offer a variable time right down to the individual sample time, instead of the 0.01 sec fixed value currently offered. This, for me, has always been a significant limitation keeping me from, among other things ,creating a running sum - basically performing integration - from sample to sample (although I think I can use a feedback comb filter for that application).

Is anyone willing to look at the code and change this?

Hi dscro,

The simple answer is: "This is difficult to implement - it would require a lot to be rewritten"

...but you seem to have some familiarity in this regard so I'll explain a bit:

I agree, this functionality is required for several DSP designs. The problem is that elements are designed to handle buffers - each element processes several samples with each call (i.e. 256). If everything were handled on a per-sample basis, the performance would go through the roof (relatively). For example, the multiply function will be called after the upstream elements have rendered all their samples (i.e. 256) - then the multiply will process 256 samples at once... as opposed to making 100s of additional function calls (and so on) for each element, for each sample. So, that's technically what we're dealing with. This feature would require a huge rewrite: several new libraries in addition to updating any existing elements to support per-sample rendering. Naturally, some elements will never be able to (logically or actually) utilize per-sample processing (i.e. freq-domain or display circuits). So... I don't see this happening soon, but I know why it is important.

Hope this helps,

J

[dscro]

Thanks, that makes complete sense. Initially I wanted that flexibility for filter designs. But actually I've learned that you can do just about any filter based on a non-recursive sum of past and current samples using nothing more than the sample delay element. What do they call that FIR?

And cascaded series and parallel feedback comb filter elements will let you set up any recursive formula you want. So actually, it's possible to build custom filters and even a whole eq plug without using the included filter elements.

Sure it would be nice in the future to have a fully functional and flexible feedback element but I see the difficulty.

Thanks

[eigentone]

Thanks, that makes complete sense. Initially I wanted that flexibility for filter designs. But actually I've learned that you can do just about any filter based on a non-recursive sum of past and current samples using nothing more than the sample delay element. What do they call that FIR?

And cascaded series and parallel feedback comb filter elements will let you set up any recursive formula you want. So actually, it's possible to build custom filters and even a whole eq plug without using the included filter elements.

Sure it would be nice in the future to have a fully functional and flexible feedback element but I see the difficulty.

Thanks

Hi dscro,

It depends on the filter you want but if you mean filter as in EQ, then yes, FIRs are a very good way to implement filters - they have many advantages over designs using IIRs. The underlying math can be more difficult (if your program requires the calculations), but the results are often more natural for filtering/EQing applications. If the impulses you use become long, you can use a convolution element.

I'd love to see sample level circuit design in SB someday, though I don't think it will happen soon, unless more developers get involved. The unfortunate part is that writing such a program would be a considerable development effort... and only a small percentage of users would be able to program extensively at that level (assuming history repeats itself, unless it is highly adopted by institutions). Of course, good designs could be easily reused/copied from one plug/circuit to another, so the entire SB community would benefit from the technology.

J