In some places, Nodes will be part of a straight chain.
In these places, if no other Node is dependant on the input, a Node can simply use the input Node's buffer.
In order to do this, we can check in prepareToPlay if any Nodes in the graph reference input and if not, set the optimisations to "don't allocate". We can then get the source buffer in process and call setAudioOutput instead of filling it.
This is in place in some locations already but the above is an addition that should make it unnecessary to even allocate the memory in the first place.
[x] TrackMutingNode [172] (saves 88,400B)
[x] RackInstanceNode [80] (saves 73,840B) (use source buffers if single output)
[x] ReturnNode [79] (saves 672,880B) (can disable allocation in prepare if there is valid input, otherwise it will be empty)
[x] RackReturnNode [72] (saves 74,880B) (use source buffers if single output)
[x] PluginNode [79] (saves 67,600B) (use source buffers if single output)
[ ] SinkNode (can have a shared empty buffer and set this as the output)
[ ] ReturnNode [?] (can have a shared empty buffer and set this as the output)
[ ] Nodes receiving sink nodes and skip them to avoid adding silence
N.B. The above could have problems if a Node tries to steal its buffer and write over it. We would need some mechanism for preventing this.
In some places, Nodes will be part of a straight chain. In these places, if no other Node is dependant on the input, a Node can simply use the input Node's buffer. In order to do this, we can check in prepareToPlay if any Nodes in the graph reference
inputand if not, set the optimisations to "don't allocate". We can then get the source buffer in process and callsetAudioOutputinstead of filling it.This is in place in some locations already but the above is an addition that should make it unnecessary to even allocate the memory in the first place.
Other optimisations