Sorry for my late reply, but I needed some time to think about all the answers…
… representing constants/settings …
Actually, that is what I want to do, except for the fact that these settings can change over time (if you think in different ‘scenes’). You could ask he question if what I want to do belongs to programming a patch or not, but since vvvv only offers 1 mode, run-mode, the border between programming and ‘using’ the patch is vague by design and can be argued about.
Besides, the existing GUI elements are amazingly limited compared to the possibilities the IOBoxes give you (as Kalle also points out).
Isn’t it frustrating that the GUI of the programming language is so advanced, and the means offered to build your own GUI are so limited?
Another argument against the fact that IOBoxes are meant only for parameterizing and not for a GUI, is that in every helppatch you will find a bang or toggle button that says ‘click this and that should happen’. Now to me, that is a GUI :) The theory sounds nice, but I just don’t think it reflects reality… In a graphical programming language, where do you draw the line between programming and GUI? (ok, theoretically, GUI should happen in a renderer)
Now back to my initial problem, I think I am not the only one that has been searching for an easy way to accomplish this, for I can find on the website kalle.Modules.Sequencer by Kalle, StepSequencer by sven, StepSequencer w/ binsize by diki, and I have rewritten someone else’s module (don’t remember who wrote it) to create my own sequencer.
In my experience, you want to be able to load these values, but I am pretty sure that some other people will also have wanted to fine-tune their settings, which means recalling one step of the sequencer, and editing these values. That is, NOT copying every single value (possibly from an IOBox containing a large spread), and then editing the one you want to change, and pressing ‘record’ again to store the slightly changed values.
When I hear people talk about ‘workarounds’ it sound to me as if it would be a great feature, but because it doesn’t exist yet, they need to do it the hard way.
Now I can see that you want to be sure that if you use an IOBox, nothing unexpected will happen to it. But in your main-patch (that is the place where I would want to have parameters, you don’t put parameters tucked away deeply in a patch somewhere I’d think), it would be such a cool feature.
So I started thinking, wouldn’t it be cool to have something like a “Last-Takes-Precence-IOBox” (LTPIOBox)? That would mean every IOBox is untouchable, except for the ones you need to be editable. As for an R node that has 2 S nodes sending to it, the R node will output the values of the S node that changed last… In the LTPIOBox case, as soon as the input changes the output would equal the input, but if the input doesn’t change and you edit the value of the LTPIOBox, the output would be the value you set. And the output would ALWAYS be equal to what is shown on screen.
Or does everybody prefer the workarounds?
@oschatz: do you have a simple example patch of what you mean?