So like the JavaScript and GLSL patches in QC. It's all so complicated at the moment.

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro

Complexity: 

●●○○ — A few weeks of work

Potential: 

●○○ — Appeals to current community

Comments

How do you envision this

George_Toledo's picture
Submitted by

How do you envision this working Alastair?

The interesting point is the implication that coding a node in the editor would be somehow less complex. Would you propose that inputs and outputs still be declared via JSON?

I can see times where it would be nice to create code in the editor to make various types of custom "spreads" of values or particle systems.

What kind of use cases did you imagine?

I'm not suggesting this from

useful design's picture
Submitted by

I'm not suggesting this from an expert user perspective, more novice. I'm yet to make my own node, slowly reading the docs and getting a feel for Vuo v1. In short though, yes for making and manipulating point clouds and the like in very specific ways that may never get stock nodes to approach doing. That was the kind of thing I used to do with QC much of the time so I'm looking for a more powerful and performant way to do it in Vuo.

Since Vuo has more data types than QC and lists of these Data Types are already native, then combining lists of say point data in interesting ways is only possible by coding new patches, which isn't so easy to jump into like QCs JavaScript patch. It involves other Coding environments, the installation of Qt and getting head around that, when it seems like much of that could be automated inside the Editor, once it knows the published In and Outs and the mapping & method code Editor should be able wrap it in a standard node code is what I'm hoping for.

I keep coming across situations where I have say a spread of points distributed along a straight line coming out of the Make Points along Curve node. Then I have an equivalent set coming from a separate straight line and I'd like to draw lines between points in Set A and points in Set B. The Javascript to do this is pretty trivial and I image in C isn't to hard either with some practice but there's such an overhead in learning Qt and coding C in a separate place and installing it. Does one have to restart Vuo to edit the code or how does that work? I guess once I can do it the proper way this might seem a nice to have than a must have but at the moment I am frustrated in my attempt to get Vuo doing things I want it to.

Hey @Alastair, did you work

alexmitchellmus's picture
Submitted by

Hey @Alastair, did you work out any nodes since this feature request?

I have been playing with nodes and there is very little QT to learn (apart from IDE none). Once you get used to the format of the node.c file you can achieve so much with C. Coming from JavaScript it's lovely that you can make a node that runs as fast as any other node in Vuo. In QC there was always the JS performance hit, not any more.

A great place to start is actually the Vuo Git repository- or the source code of the newest vuo release. Have a look in there and see what is similar- then play with it until it works for you. Don't start with Stateful nodes until you get your head around stateless, as it's better to code nodes until you need a state flu node. (So you understand what is actually happening in statefull.)

I actually really think this request is great, because it keeps you in Vuo- and we can make nodes depending on what we are working on. I don't really see it as a novice request- rather time saving. However there could be more important features to implement now- but in a perfect world this would be awesome! (At the end of the day one doesn't even need IDE's to write code- just a text editor- however the debugging is very nice in QT- let's me know what I have to fix!)

No, haven't had time but

useful design's picture
Submitted by

No, haven't had time but maybe over the (australian) summer break I can get into it. I'm well aware of the advantages of C over JS for node coding, in fact i was on my list of must haves for a QC replacement before i got involved in discussions about Vuo before it went alpha.

I'm sure it's not so hard once I put the time into doing it, even though my C is pretty rudimentary and rusty, I started a MOCC Intro to Comp Sci course that uses C to get better at understand C and principles that effect code speed but had to abandon it, maybe 2016 I can finish it.

Just thinking about the

alexmitchellmus's picture
Submitted by

Just thinking about the pipeline in future: would be great to be able to "reload" all nodes in the editor, or when a node is changed? That way we can quickly develop nodes and see them work without having to constantly relaunch the editor to see changes? (Especially if editing a node in another IDE or text editor)

Also would be great to have a simple de-bug occur from within the Vuo editor node editor.

From what @Jaymie described in GLSL node it looks like there will be a new menu in file: create node. So is that where Team Vuo think this will happen? So exciting! Vuo getting some super pro features!

Perhaps for nodes that are

Bodysoulspirit's picture
Submitted by

Perhaps for nodes that are older then 1 year, those who's source code are published, they could be edited ?

So beside "create a C node" something like "edit this node", and it would be saved as a new node once edited (a bit like the actual sub composition nodes) ?

Don't know. Sometimes it's easier to modify something rather then go from scratch, for those who don't code very well.

@alexmitchellmus So i decided

useful design's picture
Submitted by

alexmitchellmus So i decided I need to try and learn C rather than try to bluff my way through writing some simple geometry making nodes and picking it up as I went.

There's quite a few reviews of Learn to Code C the Hard Way that are extremely negative, did you use this book to learn C, have you worked through it? I get that these kinds of pedantic bike shed wars will exist in programmer circles and with a 'difficult' language like C.

Bottom line is I don't want to learn bad C habits. The author of this review recommends K&R 2. Any thoughts?

I started read the Vuo node code and there's just way too much I don't understand of it in the more complex node C, I need to get the fundamentals down before I can start I think (Even though I learnt JS a bit to make patches in QC, was the first time I'd coded in a decade!).

I love your idea of autoload nodes too, it's going to be hard to test some nodes for bugs in perfectly executing code that is spitting out the 'wrong' numbers (say a special case 3D transform node is something I want to make for folding geometry in 3D space) without constantly retesting inside Vuo. Hence my initial FR here.

Just looking through top FR…

George_Toledo's picture
Submitted by

Just looking through top FR…

That obj-c compiler inside of QC that Mirek Ruskin pulled off was so darn cool. —-

I seem to sense a theme behind some FR that aren’t implemented and also the way a few features have been implemented …

Is one of the impediments to many feature requests, the implementing of the node itself (as opposed to pull down drawers and such) being able to reconfigure the amount of ports it has while the editor is running? Or is that not an issue?

i never used his Obj-C

useful design's picture
Submitted by

i never used his Obj-C compiler (impressive as it was i didn’t want to learn Obj-C badly enough :-) ) but his web-socket was a plug-in i used heavily for a while. making GUIs in HTML5 was so fast and effortless compared to bulging something from scratch in QC. i had two way comms between an iPad and QC files running inside PresenterPro, then via a Quartz Builder app syphoned into PresenterPro due to issues/bugs with PresenterPro that weren’t a priority to its developers.

couldn’t answer your insightful question about reconfiguring ports on the fly. i wouldn’t have though it would be that hard but their may be lots of code breaks along the way to fix as you suggest. i guess we’ll know when either of the C, GLSL ports gets into a beta version and Kosanda will tell us how much work went into it.

i expect there’s just too much low hanging fruit to get to it features that a small subset of Vuo users will use a lot. some C programmers of Vuo find the workflow with Qt no big deal. i bet they’re right but imagine the e incentive for beginner C programmers if you could type straight in the editor node and get instant compile and error reporting. and then to that add the option to right click on stock nodes and transform them into editable C nodes that you can tinker with? tinkering is the best way to get a hacker enthusiastic for a new language i think. instant gratification is the name of the game for visual programming in my Adult-ADHD-reinforced opinion. :-)

Feature status

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for.

If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.

Read more about how Vuo feature requests work.

Votes

153 votes so far!

Who voted?

afonso's picture
zzkj's picture
mixfilet's picture
plutots's picture
rudigiot's picture
useful design's picture
cremaschi's picture
MartinusMagneson's picture
Bodysoulspirit's picture