demo at http://mediaplayer.tiddlyspot.com/
On Saturday, January 24, 2015 at 7:29:53 AM UTC-6, BJ wrote: > > Here are some note about the design of the media player plugin. > > Objective: to play media tiddlers that are linked to remote media, that > are sequenced via playlists. > Non functional considerations: controls must react in real-time, ie they > must feel responsive. Play must not be interrupted. > Assumption: Tiddlywiki5 should be usable on as many computers as twc, ie > not just for the latest (fastest) computers. > > tw5 has three devices for widget interactions, the refresh mechanism(RM), > widget-tree messages(WM) and invokeActions(IA). > WMs operate from a node in the tree towards the root - for a tree with N > nodes it takes a max of O(log(N)) operations to send a message from a node > to > one of its ancestors. At each widget the message is either forward or > examined and then possibly forwarded. > RM does a depth first transversal of the whole tree and is O(N). In > addition each widget recalculates its parameters when visited. > IA are applied to only immediate children and are O(1) > So IA gives the fastest response, then WM. > > Up to now user interactions (via buttons etc) result in mainly RM as > changes to the ui are mediated by modifying tiddlers, on an atom based > notebook there is a perceivable delay between clicking a button and the > resultant action. With a mediaplayer application, delays between user > actions and results are very noticeable and give a poor user experience. > > The fastest design for a mediaplayer would be to have all the logic within > a single widget. Players are embedded in the dom and respond with dom > events. It would be possible to have the dom 'finished playing' events > directly trigger logic that would select the next track to play. Such a > system would not be very flexible/extendable. It is more flexible to split > the media player into logical components and to represent these components > are widgets, allow a variable number of players and allowing other elements > to be associated with the players (eg text and photos with mp3 tracks), as > the user desires. > > The media play can be split into a sequencer (of a playlist) and players. > Players respond to events generated by the sequencer or by user interaction > (eg play pause), and generate events, some of which (eg finished) need to > be sent to the sequencer. > > As there is one sequencer and many players, it seems logical to have the > players as children of the sequencer. The device that gives the quickest > possible inter-widget communication from the sequencer to the players is > the IA. (Also, when action widgets are used with the button widget they > separate the source of the event from the actions - this is a similar > pattern). Likewise the quickest inter-widget comms from the players to the > sequencer is given by WM. > > Players also respond to user input - different players may different > controls - (eg fastforwards for video) - having controls as children of the > players allow for a natural encapsulation. > > all comments wellcome! > > cheers > > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
