enzienaudio
How should we support [block~] ?
I have successfully avoided this issue since September 2009. But that time may be drawing to a close. Basically it's a PITA to support and it's not all that efficient due to the need for moving lots of memory around and managing the interface between different block sizes. It will need to be done for supporting the fft~ series of objects, and potentially operations on tables, but until then it will remain a very low priority. Maybe I can make it to 2016?
block~ would be a fantastic thing, especially if fft~ is efficient. We could also discuss which FFT implementation to use. Btw., fft~ is really only useful if tabsend~ and tabreceive~ are there as well. Currently, the related support for switch~ (block~'s twin sibling) would be much appreciated. Does the heavy infrastructure support shutting off parts of the dsp chain, as often done in Pure Data?
Post GDC, it's definitely time to implement the FFT family of objects and the infrastructure that goes with it.
Does the heavy infrastructure support shutting off parts of the dsp chain, as often done in Pure Data?
No, not currently. Maybe it will in the future. But if you are desperate to turn off parts of your signal chain, then I would suggest creating two independent Heavy contexts and switching between them during runtime.
I would love to see block~ in Heavy. I need to create a very short (between 1 - 10 sample delay), no switch~ needed in this case. Is it possible to do something like that without needing block~?
