So how far can you stretch the granularity of this idea? Could one turn every bufferoperation into a module?
For example: create a generic AESumModule to sum buffers into a result buffer. (obviously, this can be done, but is it somehow useful?)
Since the use of vDSP is recommended, and most of the vDSP calls operate on separate buffers, I can conceivably make a AEGainModule which multiplies whatever is on the stack into its result buffer and pushes the result buffer on the stack.
It's a good question - I don't have a firm idea of where that line exists. I think a module to apply gain to a buffer list is overkill (hence the existence of
AESumModuleI think also lies on the 'overkill' side of that line - I feel like summing buffers is an operation suited to the buffer stack itself; hence
The benefit of having simple functions like
AEBufferStackApplyVolumeAndBalanceis that they require no state or memory allocation, and can be used straight away. Modules require allocation in advance, so they're more 'heavyweight' objects, so to speak.
I think the line is exactly there: Modules are stack-operating objects that need to keep state. Operations that don't need state does not need any object, just the function to apply the operation.
But that's exactly what a GainModule (or e.g. a VolumeAndBalanceModule) does: it keeps track of the gain state, and it applies the function to the current buffer. And, in its most granular form, it is exactly the same for simple operators:
1. you push a buffer
2. you push a second buffer
3. you apply operation "sum" which needs the default behavior of popping the input buffers, and pushing a resultbuffer on the top of the stack
The reason for my question is that it reminds me of a similar discussion about pixel processing in GEGL: https://en.wikipedia.org/wiki/GEGL (see GEGL design)