jstrecker's picture

Jaymie (@jstrecker)


  • Vuo Founder
  • Team Vuo
jstrecker's picture

After some investigation, I created a bug report for the Smooth with Duration you encountered: Composition freezes with certain structure of triggers + feedback loops. See the part about a workaround.

I don't have a very good answer for your question about timeframe for fixing the graphics-related crashes, sorry. For the past several months, we've been working on features/fixes that were originally planned for Vuo 1.3 and releasing the smaller or more self-contained ones in the 1.2.x versions. Since the graphics changes are complicated, they're still planned for Vuo 1.3. I expect that will be some months away.

jstrecker's picture

Ack. Thank you for reporting this bug, Philip (@Pianomatic), and sorry it's getting in your way. We'll get it fixed.

jstrecker's picture
@jstrecker commented on @Salvo's Discussion, “Track Skeleton with multiple users

@Salvo, does the attached composition do any better? It has all the Filter Skeleton nodes sharing the same Receive OSC node instead of one for each.

I also removed two of the camera nodes, since you just need the one, though that wouldn't be causing the delay.

jstrecker's picture

@unicode, thanks for pointing out this inconsistency. Scheduled for work.

jstrecker's picture

2) Create Node Group (suggested feature)

Chris (@cwilmsloyalist), is this what you had in mind? — Ability to create composition-local subcompositions

  1. It seems with the implementation you discussed, existing subcompositions are going to behave quite differently... I think there needs to be some way for us Vuo composers to tell, at a glance, which Vuo version(s) a subcomposition will work with.

Philip (@Pianomatic), we could add a “created in Vuo version” metadata that appears in the Node Library documentation area. We haven’t been storing that information in compositions so far, but if we added it in Vuo 1.3 then at least you could tell if a subcomposition was created before or after.

When making significant changes to the built-in nodes, we've been leaving the old node in Vuo but marked deprecated (it doesn't show up in the Node Library) and adding a new version of the node. This avoids breaking old compositions.

  1. With events going only to a single published port at a time, what happens to the data? ... It seems to me that the data should be available for the subcomposition to use, even if there hasn't been an event sent into those ports.

Agreed. The plan is that, when you edit a port's value on a subcomposition node, the new value propagates immediately to the connected input ports inside the subcomposition. In your example, if you edited the port Value2, the new value would immediately show up in the Value port of the Value 2 node (but it wouldn't cause the Value 2 node to execute).

  1. If a subcomposer wants events to be sent along routes in addition to where the received event arrived, it could get a bit unwieldy to deal with... Is it possible that there could be some mechanism built into the editor that would allow for an easier (and less messy) way to make this happen?

Excellent point. Maybe there could be a special published input port (event-only) that transmits an event if any published input port transmits an event.