Could it be that the VuoRenderedLayers_update function is computationally expensive to run with UI nodes and arrange nodes? Or that it somehow returns the renderingDimensionsChanged as true when using UI elements?
Had this happen again today. Only similarity I can think of is having used NDI scan converter. To be able to quit this time I had to open a composition then the Quit option was available again.
●●●○ — It prevents me from completing a specific task with Vuo.
Steps causing the bug to occur:
Open and run attached composition
Observe somewhat sluggish but usable behavior (might be related to text usage or the Mac it's being run on)
Open sub-composition
Attach Window input port to Window port of arrange node
Start main composition
Observe slow/unusable behavior
Looking at the event flow the arrange node fires events constantly
Have you found a workaround?:
Don't attach window cable to arrange node
Other notes:
I assume the arrange nodes aren't optimized for using them with UI layers (which they are super-useful for). Having an option to "Allow changes" for the Window port type could perhaps solve this?
Thanks for the feedback! I don't always write simple/clear enough so it's golden to get something like that to iron out the wrinkles. Vuo has a build in data to image node, but I'll see about examples for other uses. The tutorial should possibly be split into chapters as well to give more bite-sized approaches to it, the full thing can take some time to get through.
With 32-bit files, you need to take the byte count more into consideration as you have 4 bytes per sample. I didn't write much about automating this from the header data as it would get even longer (chaptering it out might be a way to include it). You can divide the byte-rate by the sample rate to get the bytes per sample, and use that output to set the Comb List pick/skip count.
Having more chunks means you'll also have to offset the start of the read to 45 + the bytes of the additional chunks. Ideally there would be a "Find in Data" node (or something like that) for scanning the file and provide the byte location of the "DATA" chunk-ID. Then you'd be able to use that to get to the starting point relatively easy. For now I think it will have to be a manual process though.
