First of all, very cool composition! Although Jaymie has made a stellar comp, where a lot can be learned, I hope it’s okay that I pick the original a bit apart and approach it at a different angle.
The first thing that springs to mind when looking at the composition is that you should try to limit the amount of nodes used. I also started out with huuuuge compositions with loads of nodes when first getting on with Vuo. Looking at lists, and understanding them, is key to good management and efficieny. I found that thinking about “build lists” as for-loops helped a lot in the beginning. In addition the “process list” is a simpler version for when you don’t need to mess about with an indexed solution. I’m attaching a “listified” version of your composition. The only changes should be that everything is collected into lists and values are generated (and I changed the color triangle into a rectangle). Prisim Sound-Reactive 0.5_editMM.vuo (26.5 KB)
Calculating values instead of hardcoding them are also useful for expanding or changing the composition on the fly. It can also make for a smoother composition to begin with. Looking at the “Make Mesh…” nodes, they basically use numbers in a range - which is where you’d want to use the “Make Points Along Line” node. That way you can pack all the “Make Mesh…” nodes into a “Build List”, along with the color selection. This again can be generated as per Jaymies solution, or get picked from indexed values from a “Select Input…” node.
Another point is triggering. As Vuo pushes events, and don’t pull them, you want to avoid excessive triggering of nodes. This means that as long as a node is triggered it will calculate even though it’s not used (opposite of QC). For constants this means that connecting it to a “Fire on Start” node usually is enough. The “Allow Changes” node is also worth noting in this sense.
Collecting everything into lists also has the benefit of reducing rendering to a minimum. Instead of rendering on a per object basis, you can change 3d object blending (although I’m not sure why it’s there as it stands?) and render the bunch of objects at the same time. Reals and vectors are computationally cheap, while pixels aren’t (relatively speaking). I didn’t do much about the layer aspect of it as I guess it is a tidier solution than blending images. Also, if you want, you can add an offset to the color lines of the triangle controlled by the amplitude for instance in this way, so that they overlap, and you get to use the blending.
Smoothing sound for visualisation is an interesting topic. While averaging the previous values works fine for most applications, it does come with a laggy appearnce. In addition, fast peaks just accumulates in the averaging, creating a somewhat duller look. The problem with using smooth nodes in lists is that you don’t get different timebases, so they don’t work proper. They can also exhibit the same laggy behaviour if not carefully constructed. Looking at what you’d normally want from a sound value controlling something, it’s usually just a matter of a value from 0-1. Turning the problem on its head, I’ve started using “curve” nodes for smoothing - but with the audio signal as the timebase. This way it’s possible to play around with the different curve and easing modes to get a smoothed appearance without the lag - but still with some of the jittery appearance as a purely converted audio signal.
