dumski's picture

Teo (@dumski)

dumski's picture

Vuo prevents to choose audio devices with the same name

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.11

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

  1. Connect two same named audio devices (like ext. USB soundards)
  2. Try to choose one of them, then another.

Have you found a workaround?: 

No workaround.

Other notes: 

Vuo can choose only one of the devices. If you want to choose another with the sam name, Vuo keeps the previous one chosen.

dumski's picture
@dumski posted a new Bug Report, “Vuo doesn't see aggregate audio devices

Vuo doesn't see aggregate audio devices

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.11

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

  1. Create an aggregate device in Audio MIDI Setup
  2. Put some audio device node in Vuo
  3. Choose an audio device

Have you found a workaround?: 

No workaround, but Vuo sees virtual audio devices created by Rougue Amoeba's Loopback.app

Screenshots: 

dumski's picture
@dumski commented on @jersmi's Discussion, “Drag Built Layers with the Mouse?

@jersmi, did you solved the flickering problem?

dumski's picture

Hello @Chris, I agree that ability to group nodes and comment them would be VERY useful. But this request (in my opinion) is more for option 1) than 2).

Maybe it depends on how complex subcompositions you want to save for another use. From my experience current behavior cleans up some very simple reusable subcompositions. But it's very inconvenient in some more complex situations. I build huge sets of nodes which take many options and produce some live image (for example drawing by mouse or tablet). In that case I have to filter almost ALL incoming ports for unneeded events (for options like thickness, opacity, color which change sometimes) because of ONE incoming port (mouse position which changes more than 100 times/sec). In that case there is hundreds of "fake" events generated due to current behavior of incoming ports. Performance is VERY poor.

So I think there is some third option you did not mentioned: reuse of node which takes params and produces results based on variously changing params :)

@Jaymie, sorry for such a long time of silence :)

Yes, I agree that changing to event-through-one behavior universally is good idea. In that case you can achieve event-through-all behavior more easily than in opposite direction (I'm curious if I wrote that in English :) But, of course, ability to choose a behavior of ports for every subcomposition would be great.

Cheers, Teo