My rough thoughts to date
Closed this issue · 0 comments
baconpaul commented
So here's my rough thoughts on the goals and how I would approach it
- 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)
- That means the enums (the types) have to come here as does all the code
- 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
- I think we keep the coefficient maker / filter function split and keep the subtypes
- I think we probably want to use a function rather than a list for the name conversion from the enums
- 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
- Write the filters as header only
- Use CPM to runtime grab simde or xsimd to build the tests if we are top level
- 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.