VL video player design



hi all,

atm I’m repatching an older project in VL to get the hang of it.
a spreadable videoplayer with loop selection and file management.
I am wondering if am still thinking too much vvvv spreads here… what would be the best practice to implement the videocontrols?

having a spread of videoplayers objects and a gui that edits the data of the selected player - or videoplayer objects with integraded functionality to check for hitdetection and store the values?


general rule is, design one “pure” video player with all functionality and state but no UI.
the UI part is then a different thing, it should be designed independent from the player and be connected to it with a 3rd element, e.g. VideoPlayerController.

you can then go both ways, put player and UI in the controller, spread the whole thing with a loop and only render the ‘active’ UI or have one UI and ‘set’ a player so the UI adapts to the state of the current player.

does this answer your question?

also, did you see the recent update to GStreamer video playback in VL?


@tonfilm et al
A while ago I was reading up on design patterns (only understood half of it and have forgotten most of the rest by now ): But reading your post I was wondering:

  • if and how MVC, MVP, MVVM etc. can be applied in VL
  • if you (the devvvvs) have specifically tried out different patterns
  • what you currently consider to be the “best fitting/working pattern”. Or does it only come down to personal preference?


one gui adapting to the active player, that answers my question.
good to know I designed it correctly. even without knowing the patterns :)


MVC might be a bit oldschool but is the most common and easy to understand. it already works even with vvvv, see @robotanton’s molecule viewer in girlpower/games or:
also of interest:

we also used this pattern in Ocean of Air and it works very vl. visual programming allows you to even see the pattern in the patch structure as in the second picture here:

MVVC is something we are currently looking into, the key feature for that is called “data binding”, which automagically connects the UI elements to properties of the (view) model. one or two way data binding is the power of WPF and other UI frameworks the like, and the most difficult/messy to patch. if we find a nice way to express this in vl we’ve done the biggest step.

however, implementing software patterns is only easy if you understand the pattern and basic programming concepts. so in VL you can already implement most of these if it doesn’t make heavy use of inheritance or reflection. we don’t have these (completely yet).

for not so complicated things is would still go for the data oriented vvvv style of patching, which is much nicer in a visual language than in textual code. many patterns only try to organize data and functionality in an understandable way, but visual programming removes a lot of pressure on that since you have a higher level view on the application already.