GUI modular

the basics of vvvv modular DX GUI

main page

if you like the concept, please join and contribute.

o_0!

very interessting. I would love to have a module, which automatically renders gui elements for selected IOBoxes (or even better all IOBoxes with Descriptive Names) of a certain patch and sets their new values with setpatch…

I am afraid about the complexity of such a module though. a while ago i patched the web interface (girlpower folder) and i felt it is ways to much for such simple operations. so i would say, better very basic and powerful than fancy.

A lot better looking than they Gui’s I build! Well done!

Nice idea :) Great one with the mouse popping back after using a wheel.

It is hard to make a clean GUI, we all know that.

I also would like an input pin to set the wheels at some presets.

That is why I always have my GUI like this:

1 Transforms (location)
2 Check if the mouse is above (hoover) or clicking (moving something)
3 The part that decides what to do, toggle, slide, bang, turn only one on from a group, set a preset for other sliders/buttons etc…
4 Display the result.

So step 3 is the entire logic behind my interface, and step 4 is the way it looks.

Trouble doing it my way is that addeding/removing buttons isn’t easy or noOb-proof.

So because you want buttons to work together (“if I turn on de DVD, I want the Radio to be switched off, and visa versa”) it is realy realy hard to make one super module.

@david:

yore right about complexity problem. (and your web interface patch is on my “learn vvvv” list!)
i also think that it is much better to have modules that send and receive data you could connect right after IOboxes you want to control, and that is possible in this system.

@west
you can see that outputs of the system can be connected back to inputs. this was the basic thing i did to make SpreadControl modules work. once you change working slice - only that control is updated (it takes two additional frames to do that though). so it is possible to make logic between certain controls and make them influence each other.

GUI CS module still doesn’t support buttons… this is on the way.

i also need to write some description about how system works…

Pointer module has a bug!

quad inside should be drawn in Projection space (not World!) so please change it.

@David, trouble with set patch is that you get a tick in the output when using it so it isnt ideal for smooth running gui’s. I’ve also killed a few patches through unwise use of set patch too!
I tend to make my interefaces on a per application basis for similar reasons to west, most of the tricky bits are saving and retreiving presets.
I do rather like your using slices on the sliders, I’ve tended to use banks and switch between them via buttons, nice touch

saving and loading presets is no problem with single slice values and it wouldn’t be a problem with spreads if we had this.

now, when i think about saving and loading presets, this could be done by writing to, and reading from XML file.

anybody did something like that before?

Yes, joreg did a module for that
keymaker

I use xml for presets too, just whatch for nulls onopen, you have to let the patch load the do a read file hit to ensure the file is correctly loaded, I’ve had some major errors kiiling vvvv when I’ve failed to do that, I tend to use the xml file as a kind of framedelay or feedback loopto ensure all sliders/buttons get the right values!

preview of GUI CS functions

  • Control Properties
  • Control/CTRL Map usage

Enumerations are pain in the… hope we will get fix soon.

I think this approach could cover a lot of different setups.

Modes (or control types) notes:

  • Copy mode is for controllers like MIDI and DMX (permanent bound)
  • Slide is for mouse like controllers
  • Push-Pull - for mouse, pitch bender or touch screens…

Still lot to patch.

GUI CS v0.5.zip (10.1 kB)

here is the working demo:

GUI modular demo1.zip (114.43 Kb)


Firstly I patched separate MouseCTRL modules and HoverCTRL was listening to choosen CTRL channels, but in this demo Hover controller is patched differently - with separate inputs for X, Y and Click. It is less demanding and OK for mouse setups. Still it can be combined with other controllers as well.

Display modules (like gauge.v4p) can also be stacked now. Using several display modules requires Transform Matrix pins to be interconnected, and finnaly SetMatrix should be used before connecting to HoverCTRL. This feature is not polished yet.

Controls in ‘Slide’ and ‘PushPull’ mode now listen to controller that is allready sending offset value. That means: as soon as offset controller is mapped to certain control its value is 0 (HoverCTRL takes care of that) and offset is just added to ‘Slide’ controls or to a speed of ‘PushPull’ controls.

It might be better that GUI CS would take care of offsets as soon as any controller is mapped to ‘Slide’ or ‘PushPull’ control.

I think this should be changed.

It might be possible to improve the system for what david is suggesting.

Output values could be copied to input via SetPatch every time the control is released in the Control/CTRL map.

In Control Out spread every third slice is boolean showing if the control is selected in map. So we would have to watch for Down Edge of it.

Values would be copied to original input value IOBoxes and since those values are not passed to GUI CS until Update is banged we might avoid the ‘ticks’ catweasel mentioned.

Changing values in input IOBoxes manualy would have to bang Update for channel in question.

I didn’t use SetPatch things yet. Can anybody try to patch something like this?

OK girls! Here it is.

GUI modular demo2.zip (177.94 Kb)

<showoff>
I have found a book: ‘XML in a Nutshell’ Third Edition by Elliotte Rusty Harold & W. Scott Means laying around. XML rocks, you know. So, I patched the last idea…
</showoff>

Now, all IOBoxes connected to Cons node named ‘FOO’ are updated by Patch Feedback node.

Yo can control the apperance of the teapot either by IOBoxes or by GUI controls.

Still, no Patch Feedback for spreads…

Status module seems to slow down the rendering and all… Need a replacement!

o_0!

thanks for sharing your module majortom ;D

Please help me out.

Till now I have tried to built everything I found usefull for controling GUI elements inside the GUI CS module.

Now I have different SpreadControl and ColorControl modules with and without Patch Feedback option. This is OK cause modules without PatchFeedback are less CPU demanding and it is good to have such choise.

So, I am thinking:

Would it be better to separate GUI CS in several modules to ease on CPU a little?

For example, different types - modes of control (Copy, Slide, PushPull…) or slice change part could be in separate modules.

Does displaying of Status in last demo make rotation of teapot jerky on your machines?

tnx