QC Composition Import

Feature Requests
, , , , ,
1

I know that the Vuo team has made a pretty firm stance on not creating a function to import QC compositions, but I think this could hugely add to Vuo adoption if this was an option, and I hope you all would reconsider. With the wealth of existing QC examples and work, this would be killer.

There’s been some work with a converter called QTZWeb ( GitHub - daeken/Qtzweb: Quartz Composer to JS/WebGL compiler ) Which I’m sure you’re aware of. Perhaps a similar technique could be used, reading a qtz file, and finding an analog for stock patches only (perhaps a placeholder slug could be placed for 3rd party QC patch/plugins). A separate utility even would work for this if you all didn’t want to include it into the main Vuo codebase.

2

Hey Matt,

Thanks for bringing this up. Yes, we’ve taken a thorough look at this for the reasons you’ve explained; it would be quite useful. At the moment, we simply don’t have the resources for such an undertaking. We’ve estimated what it would take to produce a somewhat complete translator, and all estimates are pushing 200k in development dollars, which is a whimsical number for us right now. In the future, perhaps a community led crowdfunding campaign might be able to help bring this together. Quartz Composer has about 400 native patches, and QTZWeb only supports 28, do you find this small amount of support useful? Offering a minimal amount of support like this would reduce the workload, yet it would still be a pretty huge project. I’d love to hear if you or others have more thoughts on the subject.

3

Perhaps an initial launch with a small amount of support, just building a framework of an app (something very light & basic), and allow/rely on the community at large to extend it?

I know you all have to be hyper focused on feature requests given the amount of resources you have. I could see this as a first step to pulling QC users to Vuo. I’m not sure what the interest on a crowdfunded campaign would be. I’ll post this in the QC Facebook group and see what sort of feedback can be gotten.

4

I can see an argument for importing them as assets or fx pipelines, as vdmx does, but not as editable patches, I’d rather see native patches that do similar functionality, I think the idea of a clean slate is much more appealing, and can imagine the bug fixing alone would be a nightmare!

1 Like
5

We’d like to get more community feedback on this feature request, so we’ve opened it for voting.

6

I do not think this would be great.

Work with Quartz if you want Quartz, and support Vuo for its future.

It’s already more powerful as quartz in several points, why waste an amazing amount of time to implement a depreciated software ?

Here is the future !

7

The idea was for people that have amassed a large library of QC work, so they don’t have to rebuild everything. I agree that Vuo is more capable, however I feel that ignoring the legacy is a bad approach.

Look at it in terms of customer conversion. How many people are using QC for Avocado or Origami? Those could all be Vuo customers very easily. Especially when they learn that QC is slowly dying.

8

Mmm …

Recycling old work … Doesn’t creators recreate all the time ? I mean a designer loves to create, I don’t know how long I can look at some old composition before I start to burn about the idea of the next one … It’s all about new stuff is it not ?

I can hear your point of view and I don’t say I don’t agree at all, but as the team mentioned, it’s such a huge work to get that done, that it could slow down the native Vuo’s expansion, which surely is much more powerful.

I think Vuo still lacks some nodes for all those Avocado and Origami users, that’s why they are not here yet. Some prototype UI nodes, more layers options, more text things, nice modern examples.

I try to be one of the users here making UI protoypes/apps to show those users what is already possible with Vuo, and I try to discover what Vuo needs to beat up those softwares.

Then I do my best to sum up the lacks and submit some Nodes here. And for each release so far one got released.

They added/are adding for example.

  • Hex Color Nodes (like Origami).

  • Custom fonts implementation (does Quartz allows that ?).

  • Drag and drop files to the compositions (not the editor, the composition window).

A software also needs some time to be discovered by people. It’s a jungle on the web.

Can you already export apps with Avocado and Origami ? No.
And believe me, when iOS and Windows app exportation features will be added, I think those Avocado/Origami users will jump here.

But as for Quartz, Vuo has lots of possibilities, and therefore a lot of different users. Some people want to make UI prototypes, other want apps, other wants to VJ … I think Vuo its feature will be a result of how many of these guys become active for each category of Vuo’s possibilities.

But I agree Vuo is new, was built from scratch by a small company, are selling their software for a great price, but still needs some improvements.
I’ve been speaking with some UI prototypers and great Quartz users and they told me some things in Vuo irritates them and are preventing them to use Vuo more.
In some ways Vuo is much easier then Quartz, in some others much more complex.

But I already love Vuo for all what it allows me to do what Quartz doesn’t and I’m fighting to make it not even as simple and powerful as Quartz but even better for the creation of apps.

But when I hear how much work it would need to add Quartz support, as an old Quartz user, I definitely not think that would be a solution.

But that’s my opinion and I love to discuss about it.

9

Matt (@mattgolsen) or anyone — What do you think of @cat’s idea of “importing [QC compositions] as assets or fx pipelines, as vdmx does, but not as editable patches”? I think that would be pretty feasible. It would mean creating a node like QC’s Composition Importer. I don’t think this would be any more difficult than many other nodes we’ve created. (It would also be something a 3rd-party developer could do.)

10

I’m actually in agreement, I don’t think it’s as large of a priority as most of the other features, especially given the workload it would take to implement it. Importing them as assets would be great, and I think a good approach. I think it would be a good bridge, and may even recreate interest from older QC users that have fallen off the radar.

I think Vuo is phenomenal software, and the team has done an amazing job in implementing it. It’s definitely a Herculean task.

11

@jstrecker how would that handle custom QC patches ? Because I guess most of the QC users use Kineme/Avocadeo/Origami/V002/1024 patches !?!

12

Custom QC patches should work fine. They’d be loaded from the “QC Plugins” or “QC Patches” folder if installed on the user’s system. (The Vuo node would disable Safe Mode, so any plugins should work.) If you’re exporting an app from Vuo, you could package custom patches with the app by placing them in a special folder inside the app bundle.

13

@jstrecker

“You could bundle Custom Patches with the App by placing them in a special folder inside the App Bundle” …

Amazing !