tweakable constants
category: code [glöplog]
Quote:
My understanding is that both happen: you have the tool for cameras/moving things around and animate them but use C for slightly more complex things. Only I can't see where the line is drawn.
isnt the point of having both worlds (i.e. a tool with programming hooks) is not to have a line at all?
Quote:
Navis: (Shameless plug) It's even faster to use GNU Rocket!!! That way you define the "variables" (or, tracks as they really are) once in the code, and edit any one at any time without any recompiling to switch tweak-parameter, or any need to paste in the values into the source code. You should really use it, there's no reason not to ;)
Not surprising to anyone, but: seconded. From a non-coder point-of-view, it is also brilliant.
What is GNU Rocket and what can it do?
Thx for the link iq :)
After having released polydraw (which is a opengl script compiler with instant feedback behavior) someone suggest me to add support for a midi controller.
Having more than 128 values that can be change independently by hand with direct screen results sounds delicious, unfortunately I dont have a midi controller at home or such to implement and test it.
I made some search on the web to find something similar in software but was unable to find anything interesting.
Since code for handling midi stuff is pretty small, i think this can be a very good way to change constants, (faster than opening / change / saving a script)
After having released polydraw (which is a opengl script compiler with instant feedback behavior) someone suggest me to add support for a midi controller.
Having more than 128 values that can be change independently by hand with direct screen results sounds delicious, unfortunately I dont have a midi controller at home or such to implement and test it.
I made some search on the web to find something similar in software but was unable to find anything interesting.
Since code for handling midi stuff is pretty small, i think this can be a very good way to change constants, (faster than opening / change / saving a script)
gargaj: exactly.
the tool just helps you perform a lot of common tasks more easily and in a more intuitive way.
if you had a demo that was best off hardcoded, you can do that in our tool - just code it all as one big node. there's no predefined forced "way" to make things with the tool. just because you have a tool with some existing nodes, doesnt mean you are forced to use only those.
the tool just helps you perform a lot of common tasks more easily and in a more intuitive way.
if you had a demo that was best off hardcoded, you can do that in our tool - just code it all as one big node. there's no predefined forced "way" to make things with the tool. just because you have a tool with some existing nodes, doesnt mean you are forced to use only those.
Tigrou: try OSC (there's midi <-> osc converters around), plus an ipod touch with the OSC app - instant fun controller ;)
I don't want to bring an old debate or hurt anyone. But here is why I don't really want to build a tool.
Mostly because there is a lot of tricky points to get right with modular environments (nodes and connections):
1. How long does it take to add a node type ?
2. How long does it take to add a parameter to a node type ?
3. How long does it takes to add a new data-type shared between nodes ?
4. Can one take a set of nodes and make a meta-node out if it ? (like Max/Msp or Reaktor do)
5. Can a node have custom routing (pulling some results from other nodes before/after computing something)
6. Can one map parameters in a way which is both expressive and generic enough ?
7. Can multiple occurences of a sub-graph happen with dynamically-bounded values ? (like different voices of a soft modular synth)
Some times ago I made a little audio modular environment and realized it was lacking 3, 4, 5, 6, 7.
I don't feel like I've enough time and knowledge to get that right.
Even if I get that right, I'd be somewhat reinventing a dynamic programming language (but making the call graph with my mouse):
1. Adding a function
2. Adding a parameter to a function
3. Adding a typedef
4. Adding a data type
5. Calling a function before/after computing
6. hard-coding Navis style and reuse
7. Calling a function
Mostly because there is a lot of tricky points to get right with modular environments (nodes and connections):
1. How long does it take to add a node type ?
2. How long does it take to add a parameter to a node type ?
3. How long does it takes to add a new data-type shared between nodes ?
4. Can one take a set of nodes and make a meta-node out if it ? (like Max/Msp or Reaktor do)
5. Can a node have custom routing (pulling some results from other nodes before/after computing something)
6. Can one map parameters in a way which is both expressive and generic enough ?
7. Can multiple occurences of a sub-graph happen with dynamically-bounded values ? (like different voices of a soft modular synth)
Some times ago I made a little audio modular environment and realized it was lacking 3, 4, 5, 6, 7.
I don't feel like I've enough time and knowledge to get that right.
Even if I get that right, I'd be somewhat reinventing a dynamic programming language (but making the call graph with my mouse):
1. Adding a function
2. Adding a parameter to a function
3. Adding a typedef
4. Adding a data type
5. Calling a function before/after computing
6. hard-coding Navis style and reuse
7. Calling a function
well I meant
4. Calling a function, but points 4 and 7 are similar
4. Calling a function, but points 4 and 7 are similar
who cares about some stupid values, with dynamic loader you can have tweakable code :)
Let's get into the werkkzeug4 cheering crowd... strange thing is, I never really liked our tools so far up to the wz3. Which has changed with 4, because:
1. Add an "operator" which has a few parameters and a function -> minutes
2. Add a parameter to the operator definition -> seconds
3. Really depends. You can do a simple helper type in minutes, but "the engine" is also simply a data type. Which means you can have several completely independent engines/renderes running at once. Nice. :)
4. Yep.
5. No problem.
6. Thanks to a good set of parameter types which are all ediatable and scriptable: Yes.
7. You can't create/delete instances of subgraphs dynamically but each subgraph can have its own set of parameters, so let's say: yes.
And first of all, it doesn't get in the way whan you simply want to hardcode anything. And it has MIDI support. In the end, the wz4 currently kind of succeeds to get myself back into demo coding, which is a feat :)
1. Add an "operator" which has a few parameters and a function -> minutes
2. Add a parameter to the operator definition -> seconds
3. Really depends. You can do a simple helper type in minutes, but "the engine" is also simply a data type. Which means you can have several completely independent engines/renderes running at once. Nice. :)
4. Yep.
5. No problem.
6. Thanks to a good set of parameter types which are all ediatable and scriptable: Yes.
7. You can't create/delete instances of subgraphs dynamically but each subgraph can have its own set of parameters, so let's say: yes.
And first of all, it doesn't get in the way whan you simply want to hardcode anything. And it has MIDI support. In the end, the wz4 currently kind of succeeds to get myself back into demo coding, which is a feat :)
Ponce, from my experience programming with quartz composer on mac (again, not really a demo tool, but there's not a whole lot of difference):
1. existing node, as long as it takes to find it. New node, as long as it takes to code it (a little more than it would take to just code the effect, but not much).
2. the parameters should be hard-coded for most nodes (e.g. a cube: you need colour, size, position etc., these can be fixed). Otherwise, for a programmable node you should declare inputs at the start of the code (they then appear on the graph), or for a variable inputs type node (e.g. a multiplexer), you should have a setting on the node for number of inputs.
3. the data types should really be fixed when you start writing a tool like this i think. In QC, you have very generic types (number, bool, structure, image, mesh...) It's possible to add new types where you need it, but you'd have to either limit the new type to a few new nodes, or add the code for the new type to all existing nodes (or write a translator maybe)
4. yeah. Select a group of nodes, "create macro". It appears as a meta-node, but you can enter it to edit the contents at any time. From inside it, you can publish inputs/outputs, these then appear as in/outputs on the metanode. If you save the macro to a repository folder on disk, it's available as a new node at any time, and editing the macro updates the graph in all files that use it (powerful, but you have to be careful ;)
5. Depends on the graph type I think. It's hard with the werkzeug type graph, as everything flows down the graph and can't really flow back up it. Where you have freely placed noodles (like QC and some of the demo tools I've seen), you just connect a noodle back down the chain. This way feedback is easy - pass an output of a shader back to the input.
6. With noodles and macros, I think yes. You can lay it out how you want. QC uses colour coding for things too, which helps - different node types have different colours (for generators, programmable nodes, consumers etc.) and noodles change colour depending on how it's used. E.g. if you connect an image output to a bool input, the noodle turns red as a warning - it will work (no image = 0, image = 1), but wrong data type.
7. yeah - either copy + paste, then reconnect the inputs how you want, or place it into one of the various 'replicating' nodes (iterator, replicate in space, replicate in time, ...)
1. existing node, as long as it takes to find it. New node, as long as it takes to code it (a little more than it would take to just code the effect, but not much).
2. the parameters should be hard-coded for most nodes (e.g. a cube: you need colour, size, position etc., these can be fixed). Otherwise, for a programmable node you should declare inputs at the start of the code (they then appear on the graph), or for a variable inputs type node (e.g. a multiplexer), you should have a setting on the node for number of inputs.
3. the data types should really be fixed when you start writing a tool like this i think. In QC, you have very generic types (number, bool, structure, image, mesh...) It's possible to add new types where you need it, but you'd have to either limit the new type to a few new nodes, or add the code for the new type to all existing nodes (or write a translator maybe)
4. yeah. Select a group of nodes, "create macro". It appears as a meta-node, but you can enter it to edit the contents at any time. From inside it, you can publish inputs/outputs, these then appear as in/outputs on the metanode. If you save the macro to a repository folder on disk, it's available as a new node at any time, and editing the macro updates the graph in all files that use it (powerful, but you have to be careful ;)
5. Depends on the graph type I think. It's hard with the werkzeug type graph, as everything flows down the graph and can't really flow back up it. Where you have freely placed noodles (like QC and some of the demo tools I've seen), you just connect a noodle back down the chain. This way feedback is easy - pass an output of a shader back to the input.
6. With noodles and macros, I think yes. You can lay it out how you want. QC uses colour coding for things too, which helps - different node types have different colours (for generators, programmable nodes, consumers etc.) and noodles change colour depending on how it's used. E.g. if you connect an image output to a bool input, the noodle turns red as a warning - it will work (no image = 0, image = 1), but wrong data type.
7. yeah - either copy + paste, then reconnect the inputs how you want, or place it into one of the various 'replicating' nodes (iterator, replicate in space, replicate in time, ...)
wow. (actually i haven't encountered 7 anywhere)
Rouquemoute: GNU Rocket is kind of a tracker for demo-variables. You define a set of variables (from the demo-code), and read them at a specified time. Then you have a tracker-like GUI that allows you to change the value at specific times, with simple interpolation support. It's not a complete demo-editor, instead it's a "tweak whatever values the coder decided needed tweaking"-tool.
I guess the 'replicating' nodes of QC are 7.
Actually, time handling in QC is seriously cool. There's a global timer that drives everything, but every time-dependent node has 3 time settings: gobal (use the global timer), parent (get the time from the macro this node is in, so you can have custom time for a whole macro), local (adds a 'time' input to the node).
The time input is just a number, so you can connect anything you want to it. Repeating timers make repeating effects, timelines give you keyframable time control for easy cuts, rewind etc.
The time input is just a number, so you can connect anything you want to it. Repeating timers make repeating effects, timelines give you keyframable time control for easy cuts, rewind etc.
@psonice
sounds pretty cool
+ the fact the interface is easily customizable
i searched long time for same stuff for midi but only find complex and expensive software. openproject or freeware should exists
sounds pretty cool
+ the fact the interface is easily customizable
i searched long time for same stuff for midi but only find complex and expensive software. openproject or freeware should exists
tigrou: i thought it was free.. well, maybe it was originally. Still, £3 is not huge money, and it seems well liked (i've not used it, but I know people who've used it for live visuals).
We've been working on a sensor-enabled port of Fingerplay for Android, which enables you to use sensordata (orientation, acceleration, light, magnetic field, sound etc.) for OSC & MIDI messages. My next demoengine will most definitely support OSC controls by default, as I've found it to be the most versatile for MIDI-like intersoftware messaging.
some page comparing 2d/3d visual programming tools (like quartz or werkkzeug) :
http://opcoders.com/articles_about_graphics/compare_products.html
http://opcoders.com/articles_about_graphics/compare_products.html
Quote:
iq, did you actually READ that article? THROUGHOUT? :D
I don't know what you mean, and I'm not sure what I read, the page you linked to contains no more than 3 or 4 paragraphs and no explanation at all...
tigrou, i like the first item on the list - which is made by the author of the list :-)
it's neoneye's site (he's a scener) - probably a list of stuff he's researched while making his GDT software.
ah yeh, now i recall. i met neoneye last year
YES.. it's a list of inspiration for UI and ways to build things. There are surprisingly many ways to do it. IMO most interesting are werkkzeug and apple shake.
