We've investigated, and it seems the bottleneck is a Rosetta bug related to how Apple is processing the camera image OpenGL texture. We don't see a fix until we add native ARM support or switch to Metal. In the meantime, you can try changing the webcam to a lower resolution.
The shader is applied once to each pixel in the output image with no multisampling. Make Image with Shadertoy draws a pair of triangles that completely cover the image, with no visible triangle edges. OpenGL multisampling only makes a difference for edges of triangles. Since they aren't visible, OpenGL multisampling wouldn't have any effect for this node, so Vuo disables it to improve performance.
I'm not sure why it is not working for you. Does it work if you drag just the composition in? If so, and you want to be able to change the URL within VDMX, you can set that up by adding a URL published port that VDMX will see. You can then change that within VDMX. See the attached.
jersmi Yup, and by having 16 sequential sine waves you should have 16 upwards pointing peaks, and 16 pointing downwards. From your image it seems like you have 32 peaks pointing upwards with something in between. As this is also repeating, it will be beneficial to "zoom" in on just one half-cycle of the main sine which would be 1/32 of the full image. By the looks of the wave it seems like the frequency of the part I'd expect to be at the negative range is quite a bit higher. Can you also try with a sine wave from the link I posted with the parameters I provided? Then you can check if the composition works as intended with the expected source material to see if it is the input that differs or if it is the composition that does something funky.
I just made a quick check and it works perfectly as a Vuo comp, but it does not work inside VDMX.
I keep the original video file and the Vuo comp inside a folder on my desktop. And I drag the folder inside my media bin in VDMX.
Sent you a screenshot of the Vuo composition.
I don't have an M1 myself. I've had two reports of 3-5 second video lag with my Vuo-made application, when running on M1 Macs. Given the performance of these machines, I can only guess something else is going on.
Good shout to email their support, thanks! Yeah was wondering if maybe Vuo had any light to shed or were talking to them at all in the last few months, usually found the VDMX responses on the forums / facebook pretty quick but perhaps all a bit busy. If I get an update I will share it here 😊
Yeah, thanks, Magneson. Logically I would divide my data by 16 -- the test wavetable is 16 sequential sine waves. I'll see what I can do.
The good news is that LPCM is by far the most used, and covering a few can cover a lot of ground. I know there can also be proprietary stuff for specific hardware/software, video cameras, game consoles. Then in addition to all the stuff in the doc you sent, there's also other types of metadata. For ex., here's an info page from the US Library of Congress on efforts to standardize and specs for embedding metadata.
We've found an issue where Vuo's image generator protocols need to use the image width and height input ports when outputting an image or movie in VDMX.
I added a Resize Image after the Play Movie node to take each movie frame and resize it using the width and height data from the image generator inputs. The resized image output cable then goes to the image generator outputImage port. This allowed the movie to play within VDMX.
We've fixed this issue in the current version of Vuo, but VIDVOX needs to update VDMX to Vuo's current version in their framework first. For now, using Resize Image will avoid the issue. Also, no need to use both an Allow First Event and Fire on Start. The Allow First Event is sufficient.