So like the JavaScript and GLSL patches in QC. It’s all so complicated at the moment.
I’m opening this feature request for community voting.
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 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 @useful_design, 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 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][1] 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.
Check out: https://learncodethehardway.org/c/ and fire up your terminal.
Once you have a grasp go straight into making simple Maths nodes and then logic nodes- (because then you have the same level of node that JS gave you in QC.). Good for game logic!
yes i like the Learn to Code the Hard way series. I did one of them, didn’t realise there was a C title!
the problem with the MOOC was there was so much yadda yadda chatting going on in between the good stuff. like they’re insecure or like the sound of their own voices too much!
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 @jstrecker 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!
1 Like
@alexmitchellmus, I think your reloading suggestion is covered by FR Automatically reload modified nodes.
Yeah, if we go with File > New Node > GLSL for Ability to edit GLSL shader code in Vuo Editor as planned, I expect that C nodes would be File > New Node > C.
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.
2 Likes
Yes make new node based on stock node would make it easier for begginers to start playing around. for more experienced node authurs it’s usually a good Idea to have some kind of version control process so using a text editor etc and folders probably a better approach.
1 Like
@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 voted for this. Would also make it easier to update some 3rd party Vuo 1.X nodes to 2 I guess/hope.
Just as a side effect of other changes in Vuo 2.0.0, there’s a little progress on this feature. You can now drop .c files into the Modules folder and have them immediately loaded as nodes. No error reporting or UI for editing yet.
3 Likes
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 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. :-)
I see this working like the like the ISF editor where you would go file new to make a c node. then you would save to the modules folder. the editor would mask the JSON blob for inputs and you would add inputs and outputs by publishing ports inside the editor. I think this would be great for doing some basic logic stuff that is hard with visual coding. I’m not sure how adding external frameworks and dependencies would work but still would be useful to have a raw c editor node that works with the Vuo frameworks. one that you could double click on to edit when using in a composition. I’m not so sure about all the stock nodes becoming editable though, that seems a bit destructive to me. good for learning experience but I suspect would be a lot of work to implement.