jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture
Jaymie commented on dee's Discussion, “App preferences and filepath

That's correct. To quote the vuo.url node set documentation:

Apple discourages modifying files within app bundles, and doing so may break code-signing. As an alternative, your app or plugin can store persistent data in ~/Library/Application Support/<app name>/ or store temporary data in ~/Library/Caches/<app name>/.

jstrecker's picture
Jaymie commented on Paul's Discussion, “Display mirroring

Not currently, but that would be quick to add. We'll consider it for an upcoming release.

jstrecker's picture
Jaymie commented on dee's Discussion, “Sharing Apps

I'm guessing the message your friend is seeing is that the application "can't be opened because Apple cannot check it for malicious software". If so, they can bypass that message by opening the app in a different way — instead of double-clicking on the app, right-click and select Open.

macOS Gatekeeper shows this error message for any application that hasn't been signed and notarized with a paid Apple developer account, including any app exported from Vuo. Fortunately, there is the workaround that I mentioned above. Unfortunately, the only way you'd be able to share apps without triggering Gatekeeper would be to purchase an Apple developer account and sign and notarize them yourself (which would be made significantly easier with this open feature request, but would still require the developer account).

jstrecker's picture
Jaymie commented on dee's Discussion, “App preferences and filepath

Sounds like you were able to solve your own problem…? If not, let us know what remaining questions you have.

jstrecker's picture

pedronbvasconcelos, thanks for providing that reduced setup for testing.

We analyzed your composition with Instruments and didn't find any memory leaks that would explain the out-of-memory error you're seeing. We first checked the composition process (with the HTTP server binary running). We also checked it with Syphon input, and looked at a variation on the composition that seeks the video to random times. We also checked the Vuo editor process, your HTTP server binary process, and a composition that sends Syphon. Instruments reported some small leaks, but nothing large enough that it would be likely to exhaust the system's memory in 5-15 days.

Do you know for sure that the problem happens with this reduced setup? Perhaps it only happens with the full setup. For example, the Vuo composition might leak only when playing certain types of video files, or the leak could be in some other application that was not included here.

From your screenshots, I would guess that you're running the composition as an exported app, rather than from the Vuo editor. If not, that might be worth a try. It would at least eliminate one variable in the experiment.

If you wanted to do more testing with Instruments, it looks like you are going about it the right way. The main thing you'd want to look for is the size of the leak. The ones "allocated prior to attach" are probably not relevant here. What you'd be looking for is ongoing leaks as the process runs. If you track the process for 30-60 minutes, making sure to test all parts/functionality of the composition, do you see any leaks large enough to add up to gigabytes over several days?

If your additional testing does lead you to believe that the problem is in Vuo, please let us know how we can reproduce the leak and we'll investigate further.