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.
@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?
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: x.com
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.