jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture
Jaymie commented on howie's Discussion, “Motion Detection

You're on the right track with relative paths. Use some double-dots to elevate it up out of the app bundle. Details here.

jstrecker's picture

When my coworker and I tried the stream, it played for a little longer on our computers but not much. 15 seconds at most.

There's nothing special about this stream that we know of that would prevent it from working in Vuo. It's actually RTSP-over-TCP, so that shouldn't be a problem. I'm able to play it with the ffplay command-line tool in the latest version of FFmpeg (4.3.1). (Vuo uses the FFmpeg library to play RTSP videos.) Possibly we need to update our FFmpeg version, or perhaps there's a bug in the way our code is using FFmpeg.

I've converted this discussion to a bug report and updated the title. Thanks, jandraka, for letting us know about the problem.

jstrecker's picture
Jaymie commented on Paul's Discussion, “ARM native

Without committing to anything, I would guess that we have several weeks of work still to do on Vuo 2.3.0 — with native ARM support being the main feature of this release.

In the interest of transparency, here's our progress on ARM:

Mostly done:

  • Build each of Vuo's open-source dependencies (33 Conan packages) as "universal" (ARM + x86_64) binaries
  • Update Vuo's other dependencies, such as the macOS SDK
  • Update the Vuo compiler code to use a newer version of the LLVM/Clang API that supports ARM
  • Modify the Vuo compiler code so it can compile nodes and compositions to either ARM or x86_64
  • Build the Vuo application and modules (nodes, types, libraries) as universal binaries

In progress / still to do:

  • Handle the new code-signing and notarization requirements on macOS 11 + ARM
  • Update the FxPlug export to be compatible with the newest version of Final Cut Pro
  • Show an error when attempting to use proprietary dependencies that haven't released ARM versions (NDI and Leap)
  • Much more testing, and fixing any bugs found
jstrecker's picture

Closing the bug report for now… happy to reopen if you can provide more info.

jstrecker's picture

The simplest workaround would be to leave the Window port of the Arrange Layers in Column node unconnected. The Window input is only needed if the layers to be arranged are Real Size layers, which the slider layers are not.

As you figured out, the problem has to do with subcompositions. In the original composition, the Arranged Layer output port of the subcomposition is a trigger, which fires events whenever any of the Make Slider nodes do. Adding the Window cable within the subcomposition changes the Arranged Layer output port so it's no longer a trigger. Within the subcomposition, the events fired from the Make Slider nodes are now blocked (because they overlap a published input's event stream). Instead, the Arranged Layers port now outputs the Window events.

Although there's room for improvement for clarifying event flow through subcompositions — for this specific case, maybe the best solution would be to avoid the problem by removing the Window input from Arrange Layers in Column. The reason it needs the Window port is to calculate the layout for Real Size layers. But if it could defer the layout until render time, then it would no longer needs the Window port.