MartinusMagneson's picture

Option for VuoCurve and VuoCurveEasing to use 0...1 scale instead of bools

This is probably one of those requests that sounds simpler to implement than they are, but it would be nice to have the option to use a scale of 0 to 1 to move through these. 0 = linear, 1 = exponential. 0 = easing in, 1 = easing out.

This would mean that the in + out option would not be available in this scenario, but that would be possible to math around in implementations. It would also bring about the option to animate the easings which would be fun!

The main purpose of this would be to neat up some nodes with separate curve modes and easings for 2d/3d/4d points which can look a bit excessive at the moment.

Scratchpole's picture

ahhaaa found a work around: use Smokris.Reinterpret 3D Object on the line grid and it keeps the same UV mapping.

Chris's picture

Hello Jaymie, thank you for your answer.I understand Vuo's choice. Of course working with the beta 2.0 is an option but I don't know how to get it and I'm probably not the good user for reporting some bugs (I'm new with this type of app.) I'm a sound engineer and musician and I'm mainly focused for now on what I call the interfaces (the outside world ,midi, audio, controllers, osc, ...) creating visuals will come later. Thank you

innlight75's picture
@innlight75 commented on @smokris's Composition, “360° image/movie viewer

when i save the smokris.makeInstructionsObject in my node library i have this error Nodes that aren't installed:

Approximate Text Height (smokris.approximateTextHeight)

but i had opened smokris.approximateTextHeight and saved to my node library. i have verified the folder and the file is into.

Can you help me? Thanks

jstrecker's picture
@jstrecker commented on @Scratchpole's Discussion, “Have you seen OpenPose?

Thanks for the tip. We looked into OpenPose in OpenCV to see if it would be compatible with Vuo. Although the OpenPose model dataset is still noncommercial, there's an alternative dataset with a license that should work for us. They say that macOS support is coming sometime in 2019. With macOS support, we could consider OpenCV for the built-in skeletal tracking feature request.

jstrecker's picture
@jstrecker commented on @root's Feature Request, “Node set for skeletal tracking with Kinect

We recently surveyed a bunch of skeletal tracking libraries. Of the 27 we looked at, 3 are viable candidates to include in Vuo:

  • BodySkeletonTracker
    • head and arms only (no torso or legs)
    • depth camera required in practice, based on our brief testing
  • Skeltrack
    • head and arms only (no torso or legs)
    • depth camera required
  • PoseEstimation-CoreML
    • better tracking than the other two, based on our brief testing
    • uses regular camera, not depth camera
    • requires macOS 10.13+, not Windows/Linux-compatible

The other 24 libraries we considered wouldn't currently work with Vuo for one reason or another: Windows only, proprietary or non-commercial license, incompatible programming language, etc.

So we will likely choose one of the above libraries, unless something better comes along by the time we implement this feature request.

All of the above libraries input an image rather than interfacing directly with a Kinect or other camera. PoseEstimation-CoreML uses a regular video camera. Skeltrack requires a depth camera. BodySkeletonTracker says that the depth camera is optional, but we weren't able to get it to track without one.

Now that we have a better idea of the libraries we might use, I've bumped this feature request's complexity rating down a notch, meaning we will be more likely to choose it compared to a more complex feature with a similar number of votes.

jstrecker's picture

Chris, I discussed your suggestion with the team. While I totally understand not wanting to spend money on something that's going to be free soon, it would take us some time and possibly even a new release to unlock the trial version. We think it would be better to focus on getting the 2.0 beta release out instead.

Scratchpole's picture

Incorrect UV map on Make Grid Points Object


Vuo version: 

OS version: 

  • macOS 10.12

How severely does this bug affect you?: 

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

Steps causing the bug to occur: 

  1. Make Grid Points Object
  2. Make Make Grid Lines Object
  3. Input image as shader
  4. Image displays stretched vertically on the point grid, it's correct on the line grid.

Have you found a workaround?: 

No. But if I use image resize and feed it a 1:1 ratio image it displays at the correct proportions. Sadly this does not resolve the issue. I want to feed the same image to both a point and line grid and have the image the same on both.




Vuo is more than nodes and cables, it's a community! Feel free to browse or add your voice.

Browse Discussions

Start a Discussion

Browse Feature Requests

Suggest a Feature

Browse the Composition Gallery

Share a Composition

How can I get notifications?

Learn more about the community

Learn more about Vuo

Vuo Announcements

Sign up for the Vuo announcements mailing list to get news and join the community. We post about once per month.