Buttons and controls that reflect the curent state

vvvv beta general
1

Hello,

I am struggling with the following:

a common thing in software is a button (or checkbox or slider or input box with a value) that also reflects the current status. If you use the keyboard or midi or any other means to toggle or change that status, the screen will show the new status, BUT you could as well use the control on the screen to toggle the status.

In vvvv, a toggle or bang node either receives its state from somewhere else, OR can be toggled. In the first case, I could use it to reflect the current status on the screen, in the second case, I could use it to toggle some value, but in that case, the status of this toggle on screen doesn’t reflect the current value (for example when I toggle it again this time using the keyboard).

I made some patch that can ‘update’ an input nodes value, but that is slow, since it uses xml rewriting.

  • Did I make myself clear?
  • Isn’t there another way of doing this?
  • And, am I the only one who gets frustrated by this?
2

this was asked many times and there is always the same answer, vvvv IOboxes are not meant to be your application gui, they are part of the code, representing constants/settings or displaying data.

when you want to set up a gui, have a look at the Gui2d nodes…

3

@ft:
long time ago i also wanted that.
but the larger my patches get the more i appreciate that nothing else than me can toggle my IOBoxes.
otherwise it would drive me mad in bugtracking.

@tf:

vvvv IOboxes are not meant to be your application gui

but you have to admit that our IOBox (Value Advanced) with it’s manyfold options (see helppatch and “IOBoxes more”) somehow invites us to use it as GUIelement…

i love all that features…

btw: is it possible to have UIfeatures within plugins?
e.g.
a simple GetSlice with an integrated “MiniIOBox” that shows the current slice Index?

4

the trivial workaround might be an tiny boolean configuration pin like “override upstream value”.

it could even have a graphical representation.

this will also make testing subpatches much cleaner.

the great thing is that is will attract people to write cleaner code, as named IOBoxes for showing intermediary results and Parameters will make much more sense for debugging.

And its a better way than the usual “always-have-Two-IOBoxes-on-top-of-each-other-with-a-short-connection-to-break”-pattern which is the classic workaround.

5

Sorry for my late reply, but I needed some time to think about all the answers…

@tonfilm

… 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?

6

yes, you are right with that, and i would draw the line so, that i would call the IOBoxes a developer GUI. but never an application or enduser gui. open this patch, drag both sliders and watch the framerate:

slider_test.v4p (15.4 kB)

7

btw whats the reason changing values in the patching gui slows down the patch so much?