lines unused slew params & 'stuck states'

[boqs]

hey, so although I said I wasn't getting sucked into a lines rewrite/refactor, I'm already in there & tinkering with the code a bit.

It seems there are a bunch of unused slew parameters - shouldn't we just delete those if the descriptor is changing anyway? scrolling through them is tedious... I don't think it's possible to slew every mix param within cpu limit! It would be great to have a working slew for at least wet (maybe also dry) - because this allows to shape a volume envelope for fade-in / fade-out in addition to the filter slews...

While I'm in there I aim to hunt down the buggy 'stuck' states...

[catfact]

oh absolutely agreed on all points

[boqs]

So... 'lines classic' is running bfin so hard I don't believe it's possible to add more slews into the mix. I managed to add the wet/dry slews & get rid of all buggy 'stuck' states as follows:

• made all ADC/DAC mixing 16 bit. the 'lines' are still using 32 bit processing internally & the del-del feedback paths are 32 bit. But i/o routing is throttled down to 16 bit.
• ripped out a bunch of weird logic in the 'ramp filter' - got rid of all redundant state variables
• ripped out most of the slew-sync logic - it makes simultaneous slewing unpredictable & therefore fragile used in real patches.
• added an equal-power crossfade to read-head slews (easy to switch that back to linear)
• copied all slew param settings from waves

Basically ended up with something on it's way to varilines - but varilines seems to generate a lot of resting noise which sounds like aliasing whereas I can't hear any artefacts due to 16-bit mixing. Varilines must also suffer from the same set of 'stuck' bugs.

Going to rebuild my patch against this new version & add back in one spare 'mixer slew' because I think it may just be possible in future to adapt the slew-sync logic to be realtime-safe (e.g only permit 10 normalising slew operations per frame using greedy algorithm)