tperry2x wrote: ↑Tue Dec 05, 2023 6:56 am
OpenXTalkPaul wrote: ↑Mon Dec 04, 2023 11:15 pm
...I should build my own generic 'player/transport controller'. Which is something I've been thinking about trying for a while now.
Would that be based on a VLC back-end? If so, could it be cross-platform-savvy?
What I was thinking of was a 'Player' widget that is completely detached from any playback engine, so this same controller could be used to play, control play of, set 'marker points' on its timeline, and display progress of 'playing', etc, so that for example the same controller could show the playback of a MIDI file that's actually being played using AVMIDIPlayer or FluidSynth just the same, or edit card of a stack for a flip-book card-animation or edit the frames of an animated GIF just the same, or it could be used to set up the trimming of an uncompress Wave file on disk or trimming a compressed Mp3 using two different shell() commands – depending on file format used – to actual apply the edit(s). This widget would fire off standard messages like 'playbackFinished' and also be able to set times (via marker point) for the 'PlayController' to fire off customizable, arbitrary messages back to the scripting engine (callbacks), that you would then do the appropriate action using whatever the playback engine is. Perhaps these user-timer-events could even allow to trigger, evaluate, or execute xTalk scripts. Basically a generic visual timeline controller / editor, and as a plain old widget that would be inherently cross-platform.
Of course once that UI work was done, it could probably then be expanded on to include some 'native layer' display and some FFI hooks into some playback engine API (FFMPLAY!) to have a new Player control on-par with (or hopefully better than) the current 'classic' Player control.
VLC is built on and includes a bunches of libraries and so that would probably involve wrapping all of those, creating lots of FFI binding strings, not that it couldn't be done, its just LOTS of work.
I think I'm more in favor FFMPEG/FFMPLAY which I beleive depends on many of the same libraries that VLC does, but it also has nice command line builds that can be controlled with CLI params/switches and could maybe be run as subprocess(es) (in their own threads).