keithlang's picture
keithlang commented on Chris's Feature Request, “Render to Virtual UVC Camera node

My bet is that Apple is developing an API for this, since they gave the mmhmm app a bunch of promo (even though it's not on the App Store because it uses this same deprecated(?) method).

Ie, even though it works now for non-app store apps, I'm guessing(hoping) there will be some support for it in future.

cwilms-loyalist's picture
Chris commented on Chris's Feature Request, “Render to Virtual UVC Camera node

keithlang Very cool that you were able to find a solution and that the Vuo Team was able to help you out. I’ve been reading more about how macOS support webcams and realize there are some real hurdles using IOkit or come up with a solution and have it signed by either Apple or by the same dev as the App you’re using it with. I think it’s a security thing to prevent rogue apps hijacking your camera while it’s in use.

Alastair Thanks, I appreciate the advice. I’ve actually dabbled with both Syphon and NDI. Here are a couple of my Compositions: SyphonCast, NDICast I’m actually working on something new that could potentially incorporate both Syphon, NDI and originally was thinking potentially a virtual webcam output as well if that could be supported at some point. It’s looking much less likely now the way it appears Apple has secured video access by apps in macOS.

useful design's picture
Alastair commented on Chris's Feature Request, “Render to Virtual UVC Camera node

In the meantime, you can output from Vuo as a Syphon image stream server and pick that up in other apps that can output a virtual webcam (the, still QC based, mimoLive for example), and there may still be free apps that do this, CamTwist used to do it back in the day IIRC.

useful design's picture
Alastair commented on Chris's Feature Request, “Render to Virtual UVC Camera node

Maybe some of us can look at paying something to make this a Vuo Pro included feature based on what keithlang commissioned. I don't imagine that his specs would be very different to what we all are looking for?

keithlang's picture
keithlang commented on Chris's Feature Request, “Render to Virtual UVC Camera node

I ended up commissioning the good folks at Vuo to write this for me — a virtual camera plugin. It requires an installer, since it's a system level extension. Due to this, you also can't offer this functionality in the App Store. Going to be releasing my stuff very soon (this week?!) but happy to chat with anyone about it.

jstrecker's picture

Excellent! It's great that you were able to add the pop-up menu to the VuoPluginApp example without adding that much additional code.

A while ago I talked with David Lublin of Vidvox about this. There are a couple of things that I think they'd want to implement differently in VDMX than you have in your code. One is that (last I heard anyway) they're using Vuo's C++ API rather than the Cocoa API.

The other difference is that David had mentioned wanting to compile the composition and set up the UI in parallel, rather than waiting for the compilation to complete before getting the list of menu items. This means that you wouldn't be able to use VuoRunner::Port::getDetails(). Intead, you could call VuoCompilerPublishedPort::getDetails(). I've attached some example code.

There's one more complication. Currently Vuo returns the menuItems in one of two different formats, depending on how the menu items are defined in the node class. In the example code, the Wave and Attribute port have one format and the CoordinateSpace port has the other. Ideally we should standardize on one of those, but for now VDMX would need to support both.

To build and run the example code:

  • Download and unzip.
  • In Terminal:
    • cd ~/Downloads/ListPublishedPortDetails
    • mkdir build
    • cd build
    • cmake ..
    • make
    • ./ListPublishedPorts
jstrecker's picture
Jaymie commented on howie's Discussion, “Motion Detection

In case anyone lands here with the same question, see this more thorough answer.

jstrecker's picture
Jaymie commented on wmackwood's Discussion, “Data Save for Apps

keithlang is basically correct. Since exported apps are ad-hoc code-signed (as required by M1 Macs), trying to save files within the app bundle would cause problems. Instead, you could save the file to a folder such as ~/Library/Application Support/<bundle ID>, ~/Library/Caches/<bundle ID>, ~/Downloads, or whatever would be appropriate according to macOS conventions.

To clarify the current behavior of Save and Fetch nodes when their URL port contains just a file name:

  • When running a composition from the Vuo editor:
    • Fetch nodes look for the file in the folder containing the composition.
    • Save nodes place the file in the folder containing the composition.
  • When running an exported app:
    • Fetch nodes look for the file in the folder containing the composition (Contents/Resources in the app bundle).
    • Save nodes place the file on the Desktop.

When a similar question came up several months ago, we (Vuo developers) internally discussed how we could make this easier, though haven't made any changes yet. We're thinking of (1) clarifying the node documentation, (2) modifying Save nodes so they look for the file in the same folder as the exported app, instead of on the Desktop, and (3) allowing URLs such as application-support://foo.png so you don't have to write out the longer URL ~/Library/Application Support/<bundle ID>/foo.png.

wmackwood's picture
wmackwood commented on wmackwood's Discussion, “Data Save for Apps

Hello Keith,

Would you please explain 'user preferences location'?

William

cwilms-loyalist's picture
Chris commented on Bodysoulspirit's Feature Request, “Code sign and notarize exported apps

I've been working on a Vuo App that I was considering might be good and useful enough to actually submit to the Apple Store once Code signing and notarization is implemented. It's not quite ready yet anyway, mainly because I tore the whole thing apart because I thought of something awesome that I really wanted to implement. In the meantime I had a few questions before thinking too much farther about it.

  1. I realize I would need join the Apple Developer Program to distribute this under at a cost of $99US/year. Would there be any other expenses and fees I'm not aware of?

  2. The message I get when exporting an App that it "requires macOS on an Intel (X86-64) CPU", is that just because my App is using nodes not yet compatible with Apple Silicon, or is it even possible to export a single App that is compatible with Intel and Apple Silicon from Vuo yet? If the answer in no Apple probably wouldn't allow a new app submission that wasn't Apple Silicon compatible would it?

Pages

Welcome!

Vuo is more than nodes and cables, it's a community! Feel free to browse or add your voice.

Browse Discussions

Start a Discussion


Browse Feature Requests

Suggest a Feature


Browse the Composition Gallery

Share a Composition


How can I get notifications?

Learn more about the community

Learn more about Vuo

Vuo Announcements

Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.