We’ve finally reached a point of being able to release a close to fully publicly available beta version of the Max package, including documentation!
For this one I’ve put the binaries on GitHub as a release:
There have be a lot of changes since I last sent round some builds so a change log would be too lengthy - I’ll give headlines here and if you get stuck please ask here or via email off list:
- Multithreading and non-realtime are now included
- Full set of tutorials and helpfiles (these replace the pdf docs)
- Cross-frame changes of values on filters (See the tabs on fl.svf~ or fl.biquad~ help patches)
- IO interpolation for all your subsample accurate needs (probably not worth it for most things, but fl.sink~ and sl.source~ help patches have demos)
- Many object addtions and rousing out of functionality
- A few new objects (fl.kernelsmooth~ / fl.makewindow~ / fl.firphase~ / fl.prioritise)
All objects have now been reviewed (changes to fl.spatial~ and fl.dispatch~ pending), but other objects should be considered to have a stable interface. Unfortunately, some of the changes (including parameter names, object names and arguments) will break old patches. Listing everything is out of scope, but the main gotchas are listed below. For parameter name changes you should mostly get errors
Key Breaking Changes:
- Filters substantially reworked and renamed. fl.svf~ replaces fl.sallenkey~ and fl.0dfsvf~ (it is the 0dfsvf code, and the filters work out the same as the salon and key ones).
- fl.timemean~ / fl.timemedian~ / fl.timestddev~ etc. have additional inputs in the middle which means that they will required re-patching (no error given)
- fl.emwa~ and fl.ewsd~ are gone and replaced by fl.movingaverage~.
- fl.window~ now take an exponent inside of a flag to sort the window but in the same argument position (no error given).
- fl.ticks~ substantially reworked - may need checking if in use in a patch
- fl.map~ parameters renamed to in_1 / in_2 / out_1 / out_2 (rather than inoo / inhi / outlo / outhi)
The builds I’ve posted don’t have the checks of previous testing builds. That means they may run a bit faster. However, there was some slow down in buffer reading due to new features that might counter that. I hope to rework the buffer stuff to regain that speed in the main use case, but I didn’t have time to do it for this version.
Happy FrameLib patching - do get in touch if you have any questions! Please also now feel free to send links on to this to any interested parties (I won’t try to control the distribution as tightly now and I hope soon it’ll be available through the package manager).