Hey devv’s
I’m curious whether it’d be possible to create a type of plugin framework for TimelinerSA, whereby we could create our own track types.
It’s just out of curiosity. no specific requirement right now, but i can see it could come in handy (re: robe/catweasels shout discussion about video timelines)
Thanks to sugokuGENKI for ask this…
The first time I createNode TimelinerSA I tried to drag a video in it, then I realized It was just a values timeline…
http://beta.codeproject.com/KB/graphics/TimeLine.aspx
When I saw this my neurons made this links:
C# -> VLC based -> user ft VLC plug-in -> YEEEEA!
I feel the possibility to make a custom e USABLE real-time Video Processing and showcontrol system, like watchout or pandoras, but with a REAL 3d engine and all the infinite potentiality of VVVV.
Dev Knows
Cheers
@sugoku: should be quite straightforward to add a track-type for simple datatypes to the timeliner. you’d only need to inherit from a baseclass and override some functions…
i’ve been considering about interactive types, and this discussion could lead onto that
e.g. if you make a type, you should inherit IViewableType
Then you define how the type will be drawn in interaction scenarios, e.g. :
e.g. Image type.
If i hover my cursor over the pin, I could actually see the image frame that was being fed (obviously this would only work for CPU based types, initially not textures)
then you could also have IBackwardsViewableType
This type instead carries the preview from nodes connected downstream.
To keep in line with general VVVV dataflow rules, we should not use the preview data in the evaluaton of node outputs, but it is useful for GUI elements
e.g. VideoControl type
The ‘standard part’ of the type contains the control signals (e.g. playstate, seek position, do seek).
The backwards viewable part ‘sucks’ video preview data from nodes downstream (e.g. a VideoPlayer which it is controlling)
It’s essentially a bit like an enum (data concerning the options are propagated backwards up the graph).
We would also need to be able to deal with:
Finally IInteractableType
Not 100% sure at all how to do this.
But ideally would want to be able to bring up a GUI element for the following operations:
Essentially an IInteractableType has a special sort of constructor, which is called in order to instantiate that type without having a node produce it. This would also lead to there being a default value (as there is for Value,Color,Enum inputs). And the value of the type could be affected through self driven GUI elements which are triggered on the IOBox/right click actions.
The separate modes of interaction could perhaps be dealt with by different interfaces.
Perhaps this could be drafted with an ITimelinerInteractableType (similar to an IInteractableType+IBackwardsViewableType above)
With the example being a VideoPlaybackControl type, for use with a video player.
(Then perhaps later extend for use with IOBoxes, other GUI interactions)
ok. bit too much all at once and definitely dancing onto the wrong side of feasibility :).
while my answer was targeting currenttime, yours is definitely pointing in the future direction.
back to simple implementation:
thanks joreg!
you’re suggesting making bespoke iterations of the existing Timerliner (p,s.i didn’t mean to say TimelinerSA).
based on the existing available source?
or saying it’d be technically possible for Timerliner to enumerate tracktypes from available classes/dlls with late binding-like behaviour via Reflection? (if that’s how dynamic plugins work?)
elliot
i was referring to working on the existing codebase (which is identical for the plugin and the SA versions) which would only allow adding types statically but should be quite straight forward.
a future implementation you outlined is technically very possible but work in that direction has not yet started.