The position of the media is important, as the refresh mechanism can rerender HTML, thus halting any media that is playing. This is on the assumption that the user wants to go on and do other stuff in the tiddlywiki while he is listening to stuff. But maybe that isn't a real big deal. It should only happen when certain tiddlers get edited. I don't know much about how libraries work, but I would think that would be something to look into. At least for audio. Video would probably be more embedded within the content, but maybe someone would want that for video too. Just a thought.
On Sat, Jan 24, 2015 at 8:29 AM, BJ <[email protected]> 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. > -- 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.
