Bodysoulspirit's picture

You can now just connect a fire node to any node to any of its port instead of the fire event port at the top of the node to achieve that.

George_Toledo's picture
George_Toledo commented on George_Toledo's Bug Report, “select input bug

I think my response to that, is just my original post over again :-)

jstrecker's picture

From the crash report, it looks like the app was exported from an earlier version of Vuo. The "Library not loaded" for Syphon is a bug that has since been fixed. If you re-export the app from Vuo 2.3.2, does it launch successfully?

No other software I own that used to run with kinect seem to get any input from it anymore… I still can't exclude a hardware problem

Yeah, it sounds like a problem with the Kinect, or at least something outside of Vuo since it affects other software.

useful design's picture
Alastair commented on George_Toledo's Discussion, “make triangles object

ah 2d vs 3D of course, doh. Thanks Bodysoulspirit

And the jitters is that just the math of multiples of three? surely once the enqueue is full it stays at 30, looks that way yet sometimes only two triangles.

Bodysoulspirit's picture
Bodysoulspirit commented on George_Toledo's Discussion, “make triangles object

Alastair not sure I understand all your questions but when slowing this down even more you'll see that

• Since only 2D random coordinates are given, of course objects rendered on the same Z plane that intersect can lead to those artefacts, a little z-random values would probably remove most of them.

• When looking at the output port of enqueue, at the beginning you'll see it's first building up the list, and since triangles need 3 positions, a new triangles gets only added once the amount of positions are multiples of 3. Then when the list is full, it adds only 1 more value, but since there are enough now, this remixes the triangles. I guess you only see 5 or 6 depending of where the points are in the list, some math going on with those multiples of 3.

• since the change colour nodes receive the same periodic event rate, but the triangles need 3 positions, when building up, the colours are changed for the triangles already existing too. It would need the color to change only when a new triangle is completely build.

useful design's picture
Alastair commented on jersmi's Feature Request, “Knob for Faster Expressive Results

jersmi regards you reiteration of the OP FR. I was wondering if like the tool tips, we could click on input sliders, knobs whatever and they then stay on the canvas until we close them, and we can drag them around out of the way or into a group to access for example the Attack, Decay, Sustain and Release sliders in the one spot on the canvas.

I guess unique knob and slider, 2/3/4 throw switches etc would be nicer to look at and guessing not a hugely dissimilar amount of work to making existing input sliders and knob version of same persistent, but maybe not Jaymie? TeamVuoUserBase could help with the graphic design aspect of it I imagine.

useful design's picture
Alastair commented on jersmi's Feature Request, “Knob for Faster Expressive Results

I agree with those comments Jaymie. Also Chris sort of slipped the idea into this thread that a knob or slider node/control object sitting on the Editor canvas (that's always visible and "tweekable" without click on any ports) would also have some kind of replication in rendered window with enhanced graphical properties that allow for skinning or whatever. That means the slider/knob/switcher object would need an input to accept a cable from a GUI object properties node ( I think a few of those exist now like Text).

I'm not sure that was ever part of the conversation prior to now and that's another permutation of the three or more different ideas of developer vs Vuo user of 3rd party comp vs Exported app and how any published inputs get manifest across the three different user case scenarios, or four if you count the idea that you can adjust on the Editor canvas but also in some rendered window object.

This whole shebang needs mapping out to make sure future use cases aren't precluded in the rush to get something by way of "ready to tweak" published ports. Im thinking here in terms of the same way "published to root" inputs had native controls in QC and then in Quartz Builder apps when that happened.

Bodysoulspirit's picture

What do you mean with "have the layer be a scaled image size" ? What size do you want it to be ?

While it is true that most "Get" nodes are in pixels, which led me to make custom nodes uploaded in the gallery : "Get Composition Height in Vuo Coordinates" and "Get Image Height in Vuo Coordinates", in Vuo coordinates images seem to have a width of 2, and the height is calculated accordingly.

Also, the layer that can be scaled does not seem to have height and width, just scale for x and y combined as a single value, as if the layer was always a square.

It's not supposed to be a square if your image isn't a square. This node is meant to select one axis, x or y, and adapt the other one automatically based on the image ratio.

If you still need to manually set width & height, there is another Image Layer node Make Image Layer (Stretched) 2.

Then there is also the Real Size one.

What do you mean with "how to change color for each layer instance" ?

useful design's picture
Alastair commented on jersmi's Feature Request, “Knob for Faster Expressive Results

Some other ideas for GUI:

• I was also wondering if maybe nodes like the slider and future rotary slider (knob) could have the option for increment steps via a list input

That would be accomplished with a minimal increment (or step) value.

So a min: 1, max: 10, step: 1 knob or slider would just output numbers 1 to 10 and nothing else. and min: -10, max: 10, step: 0.5 knob or slider would just output numbers {-10, -9.5, -9.0,…10} and nothing else.

I have a few ideas for other ways to improve the usability of sliders and knob, can't wait to mock up this weekend.

useful design's picture
Alastair commented on George_Toledo's Discussion, “make triangles object

I slowed this down and fired three events for every one event to keep the triangles on screen longer.

Two questions, 1) why aren't 10 triangles on the screen at all times (I tried looking from behind in case they're single faced triangles and that's not it)? 2) what causes the "Max Headroom" type colour interactions when triangles interest. I FR the triangle structure object to do some stuff I want really clean colour with, now I'm scared it wont be up to it if there's any intersections.

EDIT third question, what's actually causing the jitters were occasionally a triangle makes a fleeting appearance for a couple of frames?


random triangles gt - with edits.vuo

Pages

Welcome!

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.