When testing 1.2 sub-compositions in VDMX and finding an error it was clarified that VUO is not a system-wide service and has to be embedded in the host app to work. This may have advantages and disadvantages for Vuo and the app developer but it strikes me as a very inefficient way to work and brings up potential issues of compatibility for Vuo compositions now and in the future.
Are there plans to make Vuo a system-wide service to help developers, reduce downloads and save disk space?
When testing 1.2 sub-compositions in VDMX and finding an error it was clarified that VUO is not a system-wide service and has to be embedded in the host app to work.
To clarify further — There’s a folder called Vuo.framework that is embedded inside the VDMX app. There’s also a folder called Vuo.framework embedded inside the Vuo Editor app. Those folders are separate/independent and may or may not be identical.
When we released Vuo Editor version 1.2, it contained Vuo.framework version 1.2. Installing Vuo Editor 1.2 has no effect on the Vuo.framework inside of VDMX, which remains at version 1.1. The VDMX developers have to release an updated version of VDMX that contains Vuo.framework version 1.2.
Are there plans to make Vuo a system-wide service to help developers…
Theoretically, it would be possible for a host app like VDMX or Vuo Editor to search for the Vuo.framework folder in certain locations on the user’s system, such as /Library/Frameworks/. This would make it possible for you to install one copy of Vuo.framework on your system and use it across multiple host apps.
There’s nothing stopping app developers from doing this, but the disadvantage is that the host app might break if you try to use a newer Vuo.framework than the one the host app was built for. I think app developers like to have a chance to test with the new Vuo.framework before releasing it to the public. (We do make alpha/beta versions of Vuo available before release, but it’s always good to test with the real thing.)
…potential issues of compatibility for Vuo compositions now and in the future…
Yes, that’s a legitimate concern. The options I know of to address it are (a) host apps use a system-wide Vuo.framework, despite the caveats above, (b) host app developers release an update immediately when a new version of Vuo is released, or (c) host apps show informative error messages, so at least you know right away what the problem is. To be clear, it’s not all on the host app developers; for any of the above options, we Vuo developers need to do our part to support them. If there are any better options, I would love to hear them.
… reduce downloads and save disk space?
FYI, the Vuo.framework folder is currently about 140 MB.
Hi Jaymie,
Thanks for the reply, I guess we have a long way to go before the framework settles and a lot to learn on the way, anyway i’m looking forward to seeing 1.2 supported in VDMX :-)
I’m sure the team at vidvox is working on it. Tip. If you open your comps made in 1.2 and save them from 1.1. VDMX will recognize the image generator ports. However if you have subcompositions or any new 1.2 nodes you’ll get the error.
Tip. If you open your comps made in 1.2 and save them from 1.1. VDMX will recognize the image generator ports. However if you have subcompositions or any new 1.2 nodes you’ll get the error.
AFAIK you don’t have to re-save the composition in Vuo Editor 1.1 for it to work in VDMX… But yeah, opening in Vuo 1.1 is a good way to check that a composition made in Vuo 1.2 doesn’t contain any 1.2-only nodes or subcompositions.
Image Generator comps run fine when manually added to a bin in VDMX (If they’re not using any new 1.2 nodes). But to get them to show up as a Vuo Source I found it as a workaround once 1.2 dropped I believe the image generator protocol was revised in some way in 1.2?
Weird. I can’t think what would have changed in 1.2 to affect whether a composition is recognized as a Vuo Source by VDMX. I just tried creating an Image Generator composition in 1.2, opening it in 1.1, and re-saving it. There were only superficial changes. (I don’t have an OS X 10.10+ machine handy ATM to actually test on VDMX.) If you’d like to upload a specific composition that you had to re-save in 1.1 for it to work, I’d be curious to see it.
To quote David Lublin over at the VDMX Facebook page on the question of frameworks and 1.2 - “It has its pros and cons. In the case of Vuo 1.2 there were some minor changes beyond just swapping out the framework so either way we need to put out an update to work with it.”
Yes, basic 1.2 compositions dropped into the Mediabin work fine but fail with sub-compositions as VDMX is using an older version of Vuo. I haven’t tested Vuo Source but Vuo plugins work.
David Lublin of VIDVOX let me know that they’re working on a VDMX update that will include various new features and the update to Vuo 1.2, and it will be released in a few weeks.
We’re still hoping for an update of VDMX, but in the meantime we set up Vuo 1.2.2 to allow a workaround: How do I use Vuo 1.2.2 with VDMX5 b8.5.0.7?