TAAE2: granularity

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.

Comments

  • 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 AEBufferStackApplyVolumeAndBalance or AEDSPApplyGain). An AESumModule I 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 AEBufferStackMix.

    The benefit of having simple functions like AEBufferStackMix and AEBufferStackApplyVolumeAndBalance is 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.

  • @j_liljedahl said:
    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)

Sign In or Register to comment.