OpenXTalk possible bugs, April

[OpenXTalkPaul]

I'm thinking of externals which provide functions (on all platforms) such as:

Code: Select all

GammaFade(in/out,durationinticks)

Code: Select all

GetResolution

Code: Select all

SetResolution

I don't think these are pie-in-the-sky.
GetResolution already exists as the screenRect and the effective screenRect. I haven't used these a whole lot so there maybe some limitations I'm unaware of?
SetResolution I think would need to be built.

Code: Select all

[code]Play(soundfile, pitch/notes, tempo)

YES! This is ma JAM! This is the playSentence form of the Play command that never made it into MC/RR/LC.
This will absolutely be incorporated into OXT along with multiple playback engines, including the wrapper-already-built and cross-platform tested libFluidSynth. Most of this is done already! However it won't be "soundfile" it will be something like "soundFontFilePath/programName/bankNum", defaultTempo, notes/playback string (which can override programName and Tempo in the middle of the string), but don't worry it will be HyperTalk compatible (but also greatly extended) and I intend to include a HyperCard SoundFont that includes "Boing","Piano","Harpsicord" as well as some other samples I made back when, and also a small GeneralMIDI/GeneralStandard (GM/GS) compatible soundFont. It may be possible to add the ability to load any .wav/sound file to use as an instrument. I'm pretty sure that FluidSynth 2.x has this capability (the FS wrapper is currently incomplete) and I've already done this on macOS with my Apple AUSamplerInstrument wrapper.

Code: Select all

7ZFile(filename,destination)

.

Code: Select all

Un7ZFile(filename,destination)

(I mention 7Z as I think it's open source, so would be a universal way to add a compressor, decompressor into OpenXTalk)

This could be done. An extension would be better integration, but you could probably do it this with the shell() function or open process right now. I like 7zip because it offers much better compression than regular old Zip but it seems a bit CPU intensive.
I forgot to mention: besides Extension Builder language, you can also build Library Extensions using normal Script. It's similar to making an IDE plug-in.

Code: Select all

ReverseString(thestring)

Can easily be done as a regular script function, but I suppose we could include a library of functions like this.
We could including some common functions, like getStackDirectoryPath(), stringToAllCaps() stringToLowerCase, etc.

Code: Select all

GetFrameRate

Code: Select all

SetFrameRate

FrameRate for what? Video files?

Code: Select all

Put ShellNonBlock("ls -a -r ~/") into cd fld "output"

(Non-blocking shell commands)
This can be already be done with "open process" although that can be a bit tricky I guess.
I've been playing around with OpenXION from within OpenXTalk using "open process for binary update".
Maybe we could have a simplified non-blocking shell method for a single activity CLI that calls back when it's done?

Integration with other languages:
I'm aware you can obviously run shell commands with:

Code: Select all

get shell("mkdir ~/test")

and run Applescripts with:

Code: Select all

do script (myvariable) as applescript

but, would it be possible to:

Code: Select all

do script (myvar) as pythonscript

Code: Select all

do script (myvar) as rustcode

Code: Select all

do script (myvar) as javascript

Code: Select all

do script (myvar) as parsePHP

shell() is probably how this is implemented behind the scenes, I think this is why they're blocking.
'As javaScript' sort of already exists in the browser widget.
I would like very much to embed Lua as an extension (Apparently there was already a Lua external available at one point).
'as python' is available in OpenXION, which is cool!
I'd like to offer as many opportunities as we can for expanding the possibilities for xTalk scripters, but anything like that would probably have to wait until later.

Also, simplification of the network packets and sockets would be good.
Something like:

Code: Select all

SendNetworkData(ipaddress, port, TCP/UDPprotocol, thedata)

and

Code: Select all

get SendNetworkData(listening-for-ipaddress, listeningport, thedata)

And, while I'm there:
GetTotalBytesOfFile(pathtofile)
SendNetworkFile(ipaddress, port, TCP/UDPprotocol, entirefile/bytes-from-and-to)
GetNetworkFile(ipaddress, port, TCP/UDPprotocol, entirefile/bytes-from-and-to)

I'd like to make a CURL or similar wrapper library with more features then the currently available to OXT.
It could be integrated with libURL in the same way that the commercial offering tsNet external is used by libURL if it is available. But again I think this would have to wait until later down the road.

[tperry2x]

I don't think these are pie-in-the-sky.

Code: Select all

GetFrameRate

Code: Select all

SetFrameRate

FrameRate for what? Video files?

That's cool. Thank you for listening to my suggestions and taking them on board.

For the framerate thing, I wondered if it would be possible to:

Code: Select all

setFrameRate(30)

Meaning then that animated gifs for example, play back at the same speed on all platforms.
This would mean that the card / stack refreshes 30 times per second, so if you were loading in a series of images for animation:

you could then use:

Code: Select all

on tanimate
setAnimFrame(cd btn "player" of this card to image "frame1.png" of card 1 of wd "spritesheets")
setAnimFrame(cd btn "player" of this card to image "frame2.png" of card 1 of wd "spritesheets")
setAnimFrame(cd btn "player" of this card to image "frame3.png" of card 1 of wd "spritesheets")
setAnimFrame(cd btn "player" of this card to image "frame4.png" of card 1 of wd "spritesheets")
if exitanim is true then exit tanimate -- the exitanim is a global true/false variable
if not (the pendingmessages contains "tanimate") then 
tanimate
end if
end tanimate

The idea is that setAnimFrame would respect the setting of setFrameRate(30), and would ensure that the image sprite in this button was always hitting 30fps, irrespective of whatever else was happening in the stack or pendingmessages.

[OpenXTalkPaul]

The idea is that setAnimFrame would respect the setting of setFrameRate(30), and would ensure that the image sprite in this button was always hitting 30fps, irrespective of whatever else was happening in the stack or pendingmessages.

Ah, so sort of setting a default frameRate for anything that uses frame rates type timing. I say 'anything' because MIDI can also use timecode (instead of Beats/MIDITicks) with frame rates (24,25, or 30).

Not sure how this would be enforceable or if we would even want it to be enforced in a broad generalized way. For example sometimes, on slower old machines with modest GPUs, and with large animations, I've found that 30 FPS sadly isn't easily achieved in LCC/OXT.

And thanks for the suggestions / input, it's really good to hear other people's thoughts. I mean there's so many possible uses for this thing, and I know I have very specific personal interests, so I really appreciate the input from other users.