The player object has been broken for how long?

[tperry2x]

Interesting that in RunRev 1.1, the player icon did not work either.
Won't play a 'gosh-darn' thing.

Screenshot at 2024-01-04 17-58-48.png (1.22 MiB) Viewed 2905 times

Funny how I can run OXT Lite via wine, and I can play the movie.
(sample movie from https://filesamples.com/formats/mov)

hybrid-fun.png (643.11 KiB) Viewed 2900 times

But, on the exact same machine (xubuntu - xfce), no dice:

nowt.png (689.24 KiB) Viewed 2900 times

Seems like it's an engine limitation rather than anything else, given how I can play it on the same computer in Wine.
It's not that this machine can't play it back at all. (and of course, VLC handles it beautifully)

Going through the dictionary (as I am), I note it might have been this way for a while.

basically-not-much-cop.png (174.09 KiB) Viewed 2900 times

So reading that comment in the documentation, the 'player' object is a bit useless on Linux in it's current form then.

[OpenXTalkPaul]

Moved this to the Workshop forum

(sorry to directly edit your post Paul).
I moved this back as I'm talking about xTalk implementations. If you want me to move it again, that's fine - but I'll remove the 'shadow topic', otherwise we end up with duplicates.

[OpenXTalkPaul]

There is a command to change the player command (to something other than MPlayer) but that might only effect the Play VC tVideoClipFile (and of course AC AudioClips too) syntax. Play [VC/AC] File syntax may not be as inline or may even be blocking, but if you just want to play some mp3 in the background or short video clips it may be good enough.

They may have chosen MPlayer because IIRC that has it's own built-in transport controller UI and FFPLAY didn't exist at the time (?). IIRC, there was a demo someone put on the LC forums of getting MPlayer to bind to the stack window and basically fulfilling the role of a player control on Linux. I'll have to go looking to find it again.

I'd shoot for supporting FFPLAY which is part of FFMPEG nowadays (and uses some of the same libraries that VLC does). In fact I really want to write a wrapper library for that and for ImageMagick, both of these packages are widely available across platforms and both can do some wonderful things with media files. ImageMagick even has it's own graphics scripting system, and FFMPEG/FFPLAY, depending on how it's compiled, can not only play most audio/video formats but it can do audio and screen recording, muxing/demuxing, generate wave form images for audio, and all sorts of other cool things.

So my thinking is that we create abstractions or use pre-existing (but no longer functional) abstractions that call on other libraries that implement the functionality in a platform or otherwise back-end specific way.

This is the same Idea as the unified Speech library that is a commerical LC feature (kind of ridiculous to make that a commercial feature IMO). So for example on macOS we have the 'built-in' (it's an external) revSpeak which on Mac uses NSSpeech API I believe, or I can use AVSpeech Synth (newer API available on iOS too) via Extension wrapper, or I can still use (for now) NSSpeech API to do text to speech (my extension for this can do some tricks that revSpeech can't), and from FOSS world there's eSpeak and others that can be used on Linux/Mac/Win etc, or if we're running our xTalk in a browser we can call whatever native speech API is via JS HTML5. With a unified abstraction library we could just call a generic 'Speak' syntax and this library would forward the approriate commands to the best available or user specified implimentation(s). 'Speak' is the original command (not revSpeak) in HC and other xTalks, but it's not a reserved word in OXT Engine so we can easily use it there for an OXT unified speech lib.

This is also the idea behind the OXT General Music Library's 'PlayPMD' command where it will by default use AVMIDIPlayer on macOS, but it defaults to lib FluidSynth extension on Linux and Win, and can also use videoClip player (works great for basic MIDI playback on most Android devices), or MCIStrings to play MIDI on Windows (like going back to Win95 ) and lastly it can also use a provided command line player on any platform. The bottom line is that it always tries to work if there is any method available, and I've tried to make sensible defaults that require as little input from the scripter as possible. For example it automatically looks for default soundbanks in locations appropriate for the OS, if it doesn't find one it still tries to work, but if the user wants to pass the path to an alternative SoundFont file it will try to use those sounds for playback if there is an API available that can load sound banks (both AVMIDIPLayer & FluidSynth can), if not it will just send the MIDI data without specifying any soundbank.

I want to do the same with FFMPEG for the other media stuff ( want functional 'Answer Record' syntax on all platforms). I really want to abstract as many things as possible really. As we've discussed even the UI itself is / could be more abstracted away from the scripting language.

[richmond62]

Funny, that, as I was using Quicktime movies with RunRev 2.1 to display throat and mouth movements for phonetics in 2002.

[tperry2x]

I don't have a copy of 2.1 unfortunately.
My ramblings about RunRev 1.1 was only because I wondered how long it'd actually been broken for. So, interesting - there was a point in time when it worked then

Additionally, to the above
https://youtu.be/kuZIzL0K4o4?feature=shared
cross-compiling with zig.

I also need to get my head around this when it becomes ready, for native UI generation
https://github.com/capy-ui/capy

And ChatGPT can be used (okay, this is only a blank window, but it knows zig)

ChatGPT.pdf

(35.58 KiB) Downloaded 96 times

[OpenXTalkPaul]

I'll say t again... JAVA is NOT web technology although, much like Adobe Flash or SuperCard Roadster, there was Java web plug-ins for running Java in a browser (now days you could compile the whole of a JVM using WebAssembly to run inside a browser, just as has been done with CPython and other 'engines'). I think that you're thinking of JavaScript (ECMAScript) which, despite the similar names, is actually completely unrelated to Java.

Java is virtual machine technology which has always had platform agnosticism as its reason for existing. "Write once, deploy many" has proven to be largely truthful advertising. When was OpenXION written? A decade+ ago targeting JVM 1.4 or 5 for macOS classic and OS X and yet it runs fine on v19 and 20 (on Win, Linux, BSD) so I think it's fair to say JAVA is fairly 'future' resistant and intensely cross-platform. There is some speed trade-off for sure when compared to C++ compiled for a specific hardware, but It also wouldn't need a full time Software Engineer to maintain (since the 'engine' has been supported by some behemoths like Oracle since it first came out in the mid-1990s). And JAVA was good enough for Google to build Android APIs on so that's a pretty good endorsement I think.

Java code can be interpreted OR compiled, it's sort of half-compiled in that it's compiled code targeting the vitual machine not a bare-metal actual machine, and so there is another layer in the execution that can slows things down slightly, but I think it is certainly as capable as our current 'virtual machine' / engine. Which has to interpret most of code in our stacks (or ahead of time or just-in-time compiled) any way. I don't think running on a JVM makes us any worse off really. And I certainly have seen some decent 30+ fps 2D games (like a Star Castle clone I played recently that was written decades ago that still runs on modern JVM) and use some relatively snappy utilities built on Java. Probably the Java apps I've used the most have been the BitTorrent client called VUZE, jDownloader (a general DL Manager), and JBidder (an eBay auctions tracker and bid-sniper). I've used those for literally decades. They're cross-platform, and essential software for me. I believe those use the Swing UI widgets library. https://en.wikipedia.org/wiki/Swing_(Java) or its successor JFX.

I also find Java appears more readable to me as time has gone on (and I've since spent a lot more time looking at far more cryptic looking languages. In fact I think Extension builder may have more in common with Java than it does with xTalk, Pascal or anything else.

[OpenXTalkPaul]

Does that OXT DPE AppImage have these player problems?
I can't check right now but thought I remember playing back the MPEG sample file with player control on Linux without a problem?

I really need to get back to working on Linux side of things, it needs the most help and might even have the most potential. I think some Extension Building could help a lot on that platform, it looks easy enough to get a handle to a stack window for external code could render it stuff on top of.

[tperry2x]

I just thought the idea of using zig over anything else looked far easier, but okay, I'll shut up then.
For anyone else who might care, read the bottom part of this comment please
https://www.openxtalk.org/forum/viewtop ... 5544#p5544

[richmond62]

Downloads for RunRev 2.0 are all available here:

https://web.archive.org/web/20030605125 ... loads.html

[OpenXTalkPaul]

I just thought the idea of using zig over anything else looked far easier, but okay, I'll shut up then.
For anyone else who might care, read the bottom part of this comment please
https://www.openxtalk.org/forum/viewtop ... 5544#p5544

Oh no, don't shut-up! Anything cross-platform or platform agnostic like that I find very interesting.
Similarly there's a C library called Cosmo library that can compile actual cross-platform portable binaries:
https://news.ycombinator.com/item?id=26292166

[tperry2x]

Oh no, don't shut-up! Anything cross-platform or platform agnostic like that I find very interesting.
Similarly there's a C library called Cosmo library that can compile actual cross-platform portable binaries:
https://news.ycombinator.com/item?id=26292166

Excellent, I'll have to check that out.
That is what I'm doing with Zig though, to be clear. This cross-compiling idea wasn't mine:
https://youtu.be/kuZIzL0K4o4?feature=shared&t=317
It's funny how enthusiastic Gary gets in this video when it comes to the cross-compiling, but it is a really good feature in a geeky kind of way. I also thought this might help anyone installing Visual Studio, (and not having to download 4GB+ of supporting C++ libraries and compilers).

While I have your comment I can reply to, I've sent you a message about adding a LCB plugin.
Also, I wondered - is there a more efficient method of building an xTalk interpreter?

At the moment, I'm doing the following:
Producing a list of definitions / lexicon > Tokenising typed xTalk input, so they are all split up > Analysing each token statement using if/else logic > reinterpreting them at my engine-level using zig > executing the translated code.

If there are responses handled back, this process has to run in reverse. I can't help thinking there is an easier way when producing an engine?

[OpenXTalkPaul]

I booted into my Ubuntu Studio install last night and sure enough the 'player' control is broken, you can't drag-drop a new instance from the Tools palette, but you can 'create' from the menu, just like the issue with the other externally-rendered Linux widget, the Browser Widget. Interestingly, when you set the players 'filename' prop, it does render the first frame of the test movie (a small MPEG file) but doesn't play and then the Engine starts lagging badly or locks up completely.

I forgot to test the 'play videoClip' playback. Maybe this weekend.

Of course on Linux we COULD always use shell script to call whatever CLI player as a slave subprocess and pipe textual commands into it to control playback. If you use shell() with simple command it would blocks execution until the external player quits and returns a result code (an integer exit code), but there's other more elaborate ways to do it where it would be non-blocking.

So what do think about creating an abstraction library for 'movies'?

'movie pMovFile' was the original HyperCard syntax when it added support for playing media file with QuickTime (I say 'media files' because QuickTime could display or play non-video video files; sounds, still images, MIDI files, QuickDraw3D scenes, etc.). So that seems like a likely choice of keyword to use.

Alternatively it could use syntax something like playVIdeo, playAudio, recordVideo. recordAudio, Answer Record (record settings dialog)...

We could likely easily support multiple commonly found CLI video payers / recorders / editor. Most of them just require only a minimal single file path parameter to play do their thing using default settings.

So I did again look into how to bind MPlayer to a widow, and I can't seem to find it, I swear I've seen that you could do that trick, but maybe it actually used some X-Window too work?

So the three I'm looking at are...
With MPlayer, at a minimum you can set the topLeft and Height/Width of the Mplayer widow from switches.
MPlayer has no OSD (on screen display) meaning it doesn't have a built-in playback/ transport overlay controller.

FFPEG's FFMPlay can has similar CLI switches but can display an overlay play controller (and has additional really-cool features). I already did some of the experiments using FFMPEG a while back.

MPV may be the most interesting, it also is available compiled as a dynamicly loaded library that you can embed into your apps (or build an extension wrapper for). I would note that any extension or app that's includes full-blown multimedia playback or play/record engine is going to be significant larger. I'm not sure about libMPV, but FFMPEG's suite of 3 CLI apps compiled with all the options (codecs, file formats support, etc.) is more than 150MB additional binary data we would be adding. Better to have user fetch/install binaries if they need them (it's easy enough to install these from most distro package managers). MPV has it's own scripting language and a built in playback controller that is customizable via ini file.

GStreamer: I thought this video playing library was only available on Linux, but it's actually can be compiled for most platforms. This is a C++ library, I don't think there is a shell-command binary, so using that would require a built Extension/FFI strings in order to wrap it in xTalk syntax.

VLC is an essential crsss-platform app to me, but it isn't currently on my list to consider for this role because it's basically a UI that uses a bunch of other libraries underneath, some of the same libraries that FFMPEG uses, but FFMPEG can do a lot of additional cool things and has the CLI interface for shell scripting it.

[OpenXTalkPaul]

OH I knew I saw that someone had worked out something useable for Linux media playing, it was MaxV:

https://github.com/angerangel/playerwidget

[richmond62]

Well, well, well: what a wonderful thing:
-

Screenshot 2024-01-13 at 21.57.21.png (70.45 KiB) Viewed 2035 times

-
Especially with the bits I have drawn red lines round.

Does that mean . . . that it can be twiddled to work with MPlayer on MacOS and Windows as well?

Aha: No, I am afraid to tell you that using MPlayer may land everyone in the brown stuff:

https://mplayerosx.ch/

"MPlayer OSX Extended has been retired and won't receive any future updates."

[OpenXTalkPaul]

Well, well, well: what a wonderful thing:
-
Screenshot 2024-01-13 at 21.57.21.png
-
Especially with the bits I have drawn red lines round.

Does that mean . . . that it can be twiddled to work with MPlayer on MacOS and Windows as well?

Aha: No, I am afraid to tell you that using MPlayer may land everyone in the brown stuff:

https://mplayerosx.ch/

"MPlayer OSX Extended has been retired and won't receive any future updates."

I don't know what MPlayer OS X Extended is (some Mac OS X specific fork I imagine) but I just installed Mplayer the CLI binary, built from source on mac via 'Homebrew' with no problem at all. MPlayer, like TONS of other software and Libraries commonly found in Linuxes, is available in a MacOS build via package manager (I've use HomeBrew and MacPorts).

However I am starting to think the venerable MPlayer might not be such a great choice for the modern day. Apparently embedding a Mplayer window as a sub-window inside another window (which I'm pretty sure is what the player control does on Linux) can cause problems with Wayland and certain Window managers.

I'm looking more at FFMPEG (FFPLAY), and/or MPV - libMPV (which are based on MPlayer + MPlayer2) and/or at GNOME GStreamer (all three of these are available for macOS too). I'm leaning towards GStreamer because it's newer, part of the GNOME system, and has recording, editing, sequencing flow graphs capabilities. GStreamer is more of a full-on Multimedia eco-system, similar to QuickTime or newer AVMedia APIs.

I did do some more testing on Linux over the weekend and I actually I did get the player to work on my Ubuntu Studio install. I didn't even need MaxV's stack, which sends commands to MPlayer cli via a file pipe, but could only get 'Play' working (Pause/Stop don't work) and the MPlayer built-in OSD (On-Screen-Display Timeline/Controller) does not display. I'm sure this could be made to work better in an Open-Process/Interactive shell setup instead of just a basic 1-liner shell() command, but I'd much rather build something into a LCB Widget with FFI to do things proper using available system APIs.

Of course if you just need to simply play a movie full screen while blocking anything else from happening until it's done then you could use most of these options via simple shell() command just fine.

[OpenXTalkPaul]

could only get 'Play' working (Pause/Stop don't work) and the MPlayer built-in OSD (On-Screen-Display Timeline/Controller) does not display.

I guess you could always use a 'kill' shell command to force-stop the MPlayer process that's doing he playing, but that's a bit hackish.

I'll have to find the engine source relevant to the player on Linux to better understand the way it currently works (or rather doesn't work).

There's other Player problems I've noticed on macOS, particularly with audio-only (no video track) media files.

The non-player-control 'play' command has issue with playing mp3 file, it tries to play it but fails making horrible noise instead, I believe that is only compatible with older (and/or uncompressed) audio formats: WAVE,AIFF, or .AU formats.

Apparently setting that videoClipPlayer global property doesn't actually switch the CLI player that the play command (or player control) uses for playback. It's one of those features that was quietly marked 'deprecated' (no-longer maintained), it's not used for any functionality anywhere else in the Engine source.

This all has me thinking again about a 'player' widget control that has all the UI functionality of Quicktime and the like, a timeline-controller bar but that is NOT attached to any one media playback API, then we could use that help abstract media playback and editing from the underlying implementation which (as we've seen in the past with QuickTime) could change any time.