surge-synthesizer/sst-filters

My rough thoughts to date

Closed this issue · 0 comments

So here's my rough thoughts on the goals and how I would approach it

  1. From surge pull QuadFilterUnit and QuadWaveshaper (the standalone filter unit and wave shaper) but do not pull QuadFilterChain (the collection of that as 2 filters and a wave shaper)
  2. That means the enums (the types) have to come here as does all the code
  3. But that code also depends on SurgeStorage for things like pitch-to-blah so we could either make a virtual base class or a template. I really don't want to do virtual function calls for all that pitch resolution so a template it is. There's a sketch of that here
  4. I think we keep the coefficient maker / filter function split and keep the subtypes
  5. I think we probably want to use a function rather than a list for the name conversion from the enums
  6. I think it would be great if the enums were actually enums of course

And finally there's SIMD. What to do. Well I don't think we want to rewrite all the filters with xsimd so a simde dependency is required but in either case we have an external dep on a simd lib. That dep probably shouldnt be a submodule here.

But we could write the filters as header only - and in fact I would like to - in which case it is not a problem. Namely

  1. Write the filters as header only
  2. Use CPM to runtime grab simde or xsimd to build the tests if we are top level
  3. If we are not top level then hey it's ok because you will link this in a context where you have to provide simde

so document that.

Rough thoughts complete.