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.
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.
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.
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?
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.
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:
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>,
~/Downloads, or whatever would be appropriate according to macOS conventions.
To clarify the current behavior of
Fetch nodes when their URL port contains just a file name:
- When running a composition from the Vuo editor:
Fetchnodes look for the file in the folder containing the composition.
Savenodes place the file in the folder containing the composition.
- When running an exported app:
Fetchnodes look for the file in the folder containing the composition (
Contents/Resourcesin the app bundle).
Savenodes 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.
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.
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?
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?
Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.