DSP Robotics Support

Looks interesting - the "difference equation" part would translate pretty much straight into code - so playing with this might help me understand some of the other stuff I've seen.
Many thanks.

That looks difficult, but actually isn't. I've tried to do the filter coeff calculations in S|M long time ago. I'll do a search...

Here it is... had to convert it to a fsm because the board doesn't allow osm (WTF?)

Thanks MyCo - that looks like fun to play with.
That sure looks a lot less scary inside than I would have imagined - though I guess from the plot that some of the filter responses might be!

MyCo wrote:had to convert it to a fsm because the board doesn't allow osm

I can understand why not the other way around at the SM site, but this seems a bit daft to me - despite my current Ruby 'honeymoon', even I'm still using SM pretty often.

trogluddite wrote:Thanks MyCo - that looks like fun to play with.
That sure looks a lot less scary inside than I would have imagined - though I guess from the plot that some of the filter responses might be!

This is because those Math-Guys like it when it looks so difficult that no one understands it. As you can see, it's pretty easy...

The goal of my "z-plane project" was to build my own filters. This can be done very easily with the z-plane. You just have to convert your cutoff and resonance into pole and zero movements.

MyCo wrote:Here it is... had to convert it to a fsm because the board doesn't allow osm (WTF?)

Cool!! And really nice to play with those poles and zeroes.
That brought my elliptic limiter to my mind. I couldn't resist to add that option to keep the values inside the unity circle range.

MyCo wrote:That looks difficult, but actually isn't. I've tried to do the filter coeff calculations in S|M long time ago. I'll do a search...

MyCo wrote:Here it is... had to convert it to a fsm because the board doesn't allow osm (WTF?)

Thank you so much! You are great MyCo

MyCo wrote:You just have to convert your cutoff and resonance into pole and zero movements.

Excuse my noobish question - how to "plug it" to get it working with actual streams? Does output array need to be converted to stream?

stw wrote:Cool!! And really nice to play with those poles and zeroes.
That brought my elliptic limiter to my mind. I couldn't resist to add that option to keep the values inside the unity circle range.

nice addition, but the Zeros shouldn't get limited. They can also be outside the unit circle, without damaging.

Irminsul wrote:Excuse my noobish question - how to "plug it" to get it working with actual streams? Does output array need to be converted to stream?

Those coeffizients need to be passed into a biquad, you can do the biquad in code, or search in the toolbox for "biquad filter coeff".

But I don't know if this would sound good right now, because the normalization step is missing. I know how to calculate the normalization, but I don't know how to do it in a "general way". In filter design you choose a frequency where you know the gain... in a general design, you don't have that.

If you are interested here is my solution,morph through envelope or xy-pads.

Thanks for sharing that, chris, and welcome to the forum.

Yes, that's just the kind of tone shaping that I was thinking of (and your little wave thumbnails look gorgeous).

The only real difference is that the method I'm trying should, in principle, offer much lower CPU load. As only two oscillators (four for x/y pad) are actually playing at the same time, it should be possible to effectively cut out the silent oscillators completely, and just have two running, playing only the currently cross-fading pair - if only they could switch shapes fast enough at the start of each new crossfade.
Of course, 'in principle' doesn't always work in practice - I have the basic technique working, but we all expect reliability from our plugins, and certainly not memory errors!
So could well be that your approach is the one to go with ultimately.