ScriptNode Feedback After a Month of Heavy Use
-
@Christoph-Hart oh yeah this is much faster now. Awesome.
No issues so far with existing networks, adding, removing etc. I'll report if anything happens.
The cabling tooltips and the source highlight is also great. Thanks.
Another issue is now brought forward: since it's now 100% desired to fold down everything not worked on right now in big networks, the folded node visuals are rather unclear. The text is cut off because the node is forced into a preset small width.
Other than the aesthetics of a network with folded nodes, is there a reason why the node width doesn't automatically adjust to display the entire Name property?
Comments could tackle this somewhat, but only for one orientation: swapping orientation doesn't swap comment position, so putting comments on nodes in a horizontal chain makes it that much longer. https://forum.hise.audio/topic/9816/put-node-comments-above-below-nodes-when-the-container-is-laid-out-horizontally
One other thing: the change you pushed a few weeks ago where the Name property was introduced to prevent us from messing up ids, the node's core id has gone missing. So there's no longer a way to tell what is the base name of the node / node type. This is highly problematic for newbies that open existing snippets which have had the node names changed, and somewhat problematic for devs who have a small amount of RAM in their head and commonly find themselves in "what the fuck did I do here" situations.
Do you think adding a non-editable property that mentions the base node name (e.g. container.chain ) somewhere in the node properties window, perhaps right above the new Name property?
-
@aaronventure said in ScriptNode Feedback After a Month of Heavy Use:
So there's no longer a way to tell what is the base name of the node / node type.
The tooltip will show the type, ID and name if you hover over the header.
-
Alright, the folded (and unfolded) width should now take the length of the node name into account so it won't truncate it anymore.
-
@Christoph-Hart Amazing.
To recap this thread, the only unsolved issues from my original post remain:
- comment location in horizontally oriented nodes (though I understand if this would mess up node ordering as the cables run in the top and bottom)
- navigation (auto-scroll on screen edges while holding left click drag to modulation target)
From my wishlist, it's just:
- logic operators
- unscaled clamping
- variables (which you already laid out the plan for).
Everything else has been addressed, thank you.
-
@aaronventure @Christoph-Hart Couldn't the comments be shown in a floating tile when hovering a specific area/icon on the node?
-
@aaronventure said in ScriptNode Feedback After a Month of Heavy Use:
If you have 200 nodes...
I'm sorry I'm new, but I'm trying to understand how something complex can be done with 200 nodes :)
In my first attempts, I worked with a maximum of 20 nodes :)
-
@Christoph-Hart
Oh hell yeah. Will it also work for when you enable the cpu usage label? That often gets cut off for me -
@JulesV a lot of parameters driving a lot of mini-algorithms that all talk to each other. It adds up very quickly.
-
Alright, I spend a bit more time on the scriptnode UX front:
- added "variables". However I went against your objection and named them
local_cablesbecause I think that's exactly what they are. Variables would suggest that they store data, which isn't the case, they just forward any value you send into it (just like a normal cable does but without the serial killer vibes when you use them in a big patch). There are a few helper functions that lets you convert cable connections to local cable nodes and vice versa (and on compilation all local cables will be replaced by normal cables so I don't add complexity to the C++ builder). Docs are here - added a toggle button for hiding all help texts and replace them with a comment button. If you click on the comment button next to the node it will expand the comment (and hovering over the comment button will show the first line of the comment as tooltip).
- changed the layout of the help with flipped containers to be below the node.
- added a few items to the DSP node list component (to the left of the network editor). Local cables are listed now at the top with the same appearance as global cables do in the global Patch browser.
- the root chain parameters are now also listed in the Node list alongside with a slider that you can use for quickly inspecting / changing the value, a label to rename it (double click!) and a drag element that lets you create connections
- parameters of a chain have now a fixed UI element for dragging to create connections. Before you always had to enable the weird edit mode (which is now solely used to delete parameters).
- added some funky drag animation because why not.
- added "variables". However I went against your objection and named them
-
@Christoph-Hart Nice additions there!
I know it's already a real nice improvement, but I'd like to add two things:-
Adding a default value property to parameters for easy reset (double-click or modifiers). I miss this all the time when developing SNEX nodes, but with stock nodes too
-
Make the zoom sensibility adjustable as it is a nightmare on mac. This has been asked a long ago already but I imagine it slipped through. This would probably be a global setting though because the story is the same with the Interface Editor
-
-
@ustk said in ScriptNode Feedback After a Month of Heavy Use:
Make the zoom sensibility adjustable as it is a nightmare on mac. This has been asked a long ago already but I imagine it slipped through. This would probably be a global setting though because the story is the same with the Interface Editor
Can you reference the forum topic where we discussed this? I can't remember it but for my the zooming works fine on macOS.
Adding a default value property to parameters for easy reset (double-click or modifiers). I miss this all the time when developing SNEX nodes, but with stock nodes too
Yes this is reasonable, it's not entire trivial because I have to account for the possibility of people changing the range so that the initial default value lies outside the limits, but nothing impossible.
-
Alright, double click to return works now. A few notes:
- it will be stored as separate property in the value tree
- if there is no
DefaultValueproperty present (like when you load older networks) it will use the current value as default value - when you save the network it will remove all
DefaultValueproperties that are equal to their value (so that the XML tree will not get poluted with too much redundant noise) - There's a new item in the popup menu of the range editor that lets you store the current value as double click value (Set as default value)
- if you change the range so that it's doesn't contain the default value, the double click feature will be deactivated until you set a new default value that's in the range).
-
@Christoph-Hart said in ScriptNode Feedback After a Month of Heavy Use:
Can you reference the forum topic where we discussed this? I can't remember it but for my the zooming works fine on macOS.
Youhou! Back in time!
https://forum.hise.audio/topic/2577/faust2hise/20?_=1728381692975 -
In the spirit of continuity and information availability, here's one more suggestion: make the new feature where we see sources on hover along with parent node names available in the right click node properties. The connection part should also display the same level of info.
For the main network parameters, it should always displays the full node location (with all the parent nodes) for the targets. In large projects, some parameters can have lots of connections and it would be very helpful to be able to see all the targets and know exactly what they are with a single glance at the right click properties, especially while most of the network is folded.
-
@Christoph-Hart I'm reading through this thread again and the one thing I never got your opinion for are the logic operators.
Currently this is only possible by creating a SNEX file, because the expr nodes can't have multiple inputs.
If the logic op (or a new node) could do >, >=, <, <=, ==, !=, then a lot of new interesting things become possible in scriptnode, including custom splitting of a the parameter range (simply by setting the other input of the < / > which is plugged into the input toggle node), which in turn enables custom dynamic flex envelopes and many other things.
As I mentioned in the original post, the groundwork is all there, you'd just have to add these operators to the logic_op node to be used for comparison between two inputs.
-
@aaronventure @Christoph-Hart I got your reply in the email notification, but it seems to be lost in time to forum updates. Thanks for the new node, I'll be checking it out now.
-
@Christoph-Hart Would it please be possible to make it so that the compare node (and logic_op) can be plugged into soft_bypass node's switch?
