- Prefers to be called
- Hareid, Norway
- 6 years 3 months ago
- Last seen
- 2 days 16 hours ago
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
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.
Thanks! Good to know it helps (but test a lot if using it for production!)! I had it running for a couple hours on my 2015 mbp (with Iris graphics) without any apparent issues, but you never know. I intentionally left the compostion at the maximum number of frequencies to stress test so it should crash pretty fast if there is any issues. If it then grinds to a halt it's a sign that something isn't right.
The sorting bit and getting the index can probably be done with stock nodes as it just is an implementation of the "Get Maximum" node for lists. The function itself gives you the index in the list. I really don't know if this is intended use for it regarding efficiency or if there is a better way. From what I understand, internally it uses an array instead of a list to get the raw data, so it should be somewhat more efficient than a pure list approach. There is probably some room for improvement though, as it still takes a roundtrip through a list for every iteration of checking. If all that happens in an (the same) array instead, it might be better.
The way the sorting happens is finding the largest number, then adding it to one list, and the index of it to another list. Then it sets the current number to 0, and repeats. This is probably the least efficient sorting method, I think it's in a general sense comparable to selection sort in this video: https://www.youtube.com/watch?v=kPRA0W1kECg . It might be possible with some "Build List" nodes, but I'm not quite sure. The reorder part as well should be possible in the same vein, but you'd need a fair bit of node wrangling to do so I guess.
Sort points by distance was my first thought as well, the problem I encountered there was that by sorting without having the index, it will put the largest value at index 1 no matter where it is in the spectrum. Sorta works for the random blobs, but you wouldn't get the color separation based on frequency.
(I already have a couple of my shoddy image filter ports included in 1.2.6 ;) Polished by team Vuo of course!)