OXT Cloud IDE v0.00000001

[OpenXTalkPaul]

I also want to look into IDBFS FS.sync function, maybe that needs to be called in order to actually write the bytes of a files in memory to an Emscripten attached IDBFS virtual file system?

IDBFS

Note
This file system is only for use when running code inside a browser.

The IDBFS file system implements the FS.syncfs() interface, which when called will persist any operations to an IndexedDB instance.

This is provided to overcome the limitation that browsers do not offer synchronous APIs for persistent storage, and so (by default) all writes exist only temporarily in-memory.

[OpenXTalkPaul]

I put up a new version of the OpenXTalk web playground that has some of MetaCard IDE included in it.

https://openxtalk-org.github.io/OpenXTalk-Playground/

Of course IDE tools do us no good if we cannot save/export our edited stack files!

[OpenXTalkPaul]

Over the weekend I started to clean up this demo stack's UI, and I did some more tinkering around with Web Speech API via Emscripten Engine:
https://openxtalk-org.github.io/OpenXTalk-Playground/

Now you can pick a voice from list retrieved via Web Speech API.
This list may be different depending on the Browser engine and version.

Even if I can't get the thing to save changes to a stack file, I still want at least some IDE functionality, I've added some of he old MetaCard IDE (because that was mostly self-contained) just to play around with this idea. You can make and navigate to new cards in the main stack, create image controls and draw on them, use menu to copy text to the browsers clipboard, and of course the previous xT and JS demo scripts (now placed into menus), but not too much else so far.

Screenshot 2024-07-01 at 10.17.44 PM.png (242.23 KiB) Viewed 11760 times

FYI: As mentioned previously, there are ways to run the Emscripten Engine without any of the files being 'online',
All the major Browsers all have some sort of method for developers to do this, and you don't even need to run a local HTTP server to do it. And of course there are a few WebApp->DektopApp wrappers around (Electron/V8/Node etc.)

[OpenXTalkPaul]

Import for Text data and image is working.
And Save to file for text in the fld works

[TerryL]

Paul, please continue with your online IDE experiment and online dictionary. I'm following your progress.

[OpenXTalkPaul]

Paul, please continue with your online IDE experiment and online dictionary. I'm following your progress.

Cool, glad to know that I'm not just talking to myself, haha!

[tperry2x]

I love the progress on this, and I'm following along too.
I don't have anything constructive to add, so that's why I'm quiet on this topic - however I do find it interesting.

[OpenXTalkPaul]

https://openxtalk-org.github.io/OpenXTalk-Playground/

Now it plays the HyperCard sound BOING!
Not only that but it plays it pitch-shifted multiple times to form a chord, and does so using only plain web-audio API.

[OpenXTalkPaul]

https://openxtalk-org.github.io/OpenXTalk-Playground/

Now it plays the HyperCard sound BOING!
Not only that but it plays it pitch-shifted multiple times to form a chord, and does so using only plain web-audio API.

I wrote a lengthy post about having updated this earlier today, but I guess I got side-tracked by RL and never posted it?

Sigh...
Updated this afternoon:
https://openxtalk-org.github.io/OpenXTalk-Playground/

Screenshot 2024-10-16 at 8.12.27 PM.png (568.66 KiB) Viewed 4641 times

So with the Emscripten engine having an xTalk<>Javascript bridge thereby enabling polyglot programming mixing the two, not only can we use it to access all of HTML5 APIs, like using web audio API to pitch-shift sound samples for use as musical notes, but now, at the low low cost of an additional 40Kb of downloading, the on-screen Piano actually outputs sound, in real-time (or close enough to it so as to be useful) using webaudio-tinySynth.js and thanks to a snippet from General Music library you can change programs (Musical Instrument Sounds) too. Webaudio-tinySynth.js is a fully functional MIDI playback synthesizer engine with 128 instrument sound bank. But don't expect it to sound like a $10K Moog, tinySynth sounds like late 1980s 16 bit Game console quality (think 16bit SEGA), and that's on it's good' setting, and on it's low-quality setting it sounds like early 1980s 'chip-tunes' 8bit game console music. But it works, it can play MIDI file data (so I can get playSentence/'PlayPMD' working on the web), and it's really tiny and self contained.
https://github.com/g200kg/webaudio-tinysynth

There's a slight lag (latency) and it could be a variety of things.
I wonder if it could be smoother without graphics compositing. You see I noticed after deploying that the Piiano's keys highlight color is actually set to be semi-transparent, you can see the background objects blending though it while the 'keys' are pressed, but needn't be. That's comes at cost of extra processing for rendering.

This code will play a MIDI file

Code: Select all

synth.loadMIDI('https://upload.wikimedia.org/wikipedia/commons/5/55/MIDI_sample.mid');
synth.playMIDI('https://upload.wikimedia.org/wikipedia/commons/5/55/MIDI_sample.mid');

--- LOAD FROM DATA URL:
synth.loadMIDIUrl('data:audio/midi;base64,TVRoZAAAAAYAAAABAeBNVHJrAAAA5wD/WAQEAhgIAP9RAwehIADAAADAAGWQXH8AwABlgFx/AMAAZZBZfwDAAGWAWX8AwABlkFZ/AMAAZYBWfwDAAGWQQ38AkEF/AJBCfwCQQH8AkD9/AMlPAJlPfwDAAACQU38AwABlgEN/AMAAZYBCfwDAAGWAP38AwABlgFN/AMAAZZBDfwDJTwCZT38AwAAAkFB/AMAAZYBBfwDAAGWJT38AwABliQB/AMAAZcAAZYBAfwDAAGWAUH8AwABlkE1/AMAAZYBDfwDAAGXAAGWATX8AwABlwABlwABlwABlwABlkDh/AP8vAA==');
synth.playMIDI();

there's also the method .loadMIDIurl() which will play a data URL (which is what I want for passing created MIDI data)

[OpenXTalkPaul]

It's just occurred to me that JavaScript can make iFrames elements and set the contents of them 'on the fly', which I suppose is a bit like having a 'browser widget' inside of a web page.

If you paste this into OXT Playground web stack 'input' text area, and then click 'Do Console Text as Javascript' inside the stack, you'll get the idea of what I'm going on about:

Code: Select all

const iframe = document.createElement("iframe");
iframe.src = "https://openxtalk-org.github.io/OpenXTalk-Playground/";
iframe.width = 1000 ;
iframe.height = 1000 ;
iframe.id = 'subpage' ;
document.body.appendChild(iframe);

That creates a new frame in the web page and loads a second instance of the web stack into that frame (but since it's of the same origin site, it doesn't need to re-download the 28mb Emscripten Engine)

Then it occurred to me that HyperSim's Engine could be embedded into our Emscripten powered 'web-stack' and then 'HCSim' based 'web-stacks' could be generated and previewed while both kinds of 'web-stacks' are live inside frames of a single browser window, which offers the chance at building a web-app-standalone-IDE for HCSim. That means no server back-end would be required in order to create HTML5/HCsim based 'web-stacks' and it would be usable on just about anything that has a modern web-browser, and the outputs 'stacks' are HTML/JS pages, which could then be wrapped in an offline web-app-to-desktop-app wrapper like Electron if you wanted an off-line desktop app. HCSim is smaller and loads faster than our Emscripten Engine.

Using this instead of the previous code creates a new frame and writes new web-page content into that frame:

Code: Select all

const iframe = document.createElement("iframe");
iframe.width = 1000 ;
iframe.height = 1000 ;
iframe.id = 'subpage' ;
document.body.appendChild(iframe);
document.getElementById('subpage').contentWindow.document.write("<html><body>Hello world</body></html>");

I know HyperSim already is its own IDE of sorts, but I'd really like to see if I could push that well beyond being a HyperCard-simulation. Being built more on web standards (at least compared to the Emscripten engine being a JS port of a 30+ year old UNIX app) means that a LOT could be done with it. I think it would be fairly easy to add things like an HTML5 video 'player control' (there's already a video on one of the cards of Dan's HCSim intro 'Home' stack). And of course the web already has full support for things like SVG (animated!), and unicode support ready for the odd ancient-Sumerian web-fonts

As much as I still want the direct 'bare-metal' hardware and OS API access of a 'real' desktop app, there's also a hell of a lot on the 'plus' side to 'piggy-backing' an xTalk 'engine' on top of JS+HTML5. Now days with JavaScript on the desktop there's quite a large ecosystem of things like Node.js , React Native, JSX (JavaScript for Automation), offline-WebAssembly, etc. Web-app-wrappers can be less 'sand-boxed' than running inside a web-browser, for example 'Electron' apps can run shell scripts (Electron was developed by GitHub for 'hackable' code editor Atom, now called 'Pulsar').

[OpenXTalkPaul]

My laptop is out of commission, needs either a new battery or a new motherboard, so I moved its drive to the old desktop I have set up to run Mohave, so I can continue work while I sort that out. (Considering Apple Silicon MacBook Air)

Anyway Mohave's Safari version is 14, I have no idea if there's any community created WebKit updates for it or whatnot, but this version of Safari 14.x does not support the method of WebAudio Audio sample playback method used in both the 'Boing' button in my Playground webstack and in HyperCard Simulator's 'play' command. FireFox 115.16.1 Extended Service Release does work correctly with the WebAudio.
Ironically(?) I used tinySynth.js with the Piano widget on the playground webStack and it works fine on either browser (not to mention it can play MIDI file data).

[Kdjanz]

My laptop is out of commission, needs either a new battery or a new motherboard, so I moved its drive to the old desktop I have set up to run Mohave, so I can continue work while I sort that out. (Considering Apple Silicon MacBook Air)

What about a new M4 mini? The power would probably blow you away!
I have a M3 Air that is perfect and superlative for me in every way once I traded in the 8GB base model that I first bought for a 16GB upgrade that runs everything that Apple is currently beta testing. The battery life is almost frightening - since when can I carry around a skinny little laptop for 5 days without recharging!!! They claim 23 hours continuous use and I believe them, but I will never push that limit.

[tperry2x]

Anyway Mohave's Safari version is 14, ...this version of Safari 14.x does not support the method of WebAudio Audio sample playback method used in both the 'Boing' button in my Playground webstack and in HyperCard Simulator's 'play' command. FireFox 115.16.1 Extended Service Release does work correctly with the WebAudio.
Ironically(?) I used tinySynth.js with the Piano widget on the playground webStack and it works fine on either browser (not to mention it can play MIDI file data).

That's a pain. Hope you get it sorted. I've got to fork out for a new MacBook Air 2017 battery at some point, although it is running without one - but laggy as the OS can't understand why a battery isn't present.

The web standards thing, you can see what I was banging on about where it's a shifting evolving standard - moreso than desktop OS in many cases. Just a few browser iterations and the online version of the webstacks stop working. In comparison, go back to an old desktop version and things are supported for longer - but arguably it's more of a headache to recompile and sort that side of things out when compatibility ceases... so, swings-and-roundabouts.

I'd want to compile on an intel mac, and probably on 10.14 as previously mentioned - just to get the compile functioning first. If I ever reach those heady aspirations, then a build trying an Arm mac would be the next 'stretch goal'
However, I do not relish the idea of having to fork out money for an M3/M4 mac mini - even an M2 would do, and the best I've seen one go for on eBay with 16GB of ram was for about £318 ($411) - whereas the equivalent one on Apple's refurbished store is currently $1099 (no thank you very much).

[OpenXTalkPaul]

The web standards thing, you can see what I was banging on about where it's a shifting evolving standard - moreso than desktop OS in many cases. Just a few browser iterations and the online version of the webstacks stop working. In comparison, go back to an old desktop version and things are supported for longer - but arguably it's more of a headache to recompile and sort that side of things out when compatibility ceases... so, swings-and-roundabouts.

I'd argue that while HTML is 'a living' standard' and in general it often takes a few (or many) versions before enough Browser vendors have all added in support for something new but once they do, the support for the features could remain used for decades. For example SVG support was standardized and eventually support added to most browsers like 20+ years ago right? While older versions of Browser or any older software aren't going to support the latest modern things.

HTML5 isn't all that old, but it is a game changing collection of APIs geared towards (eventually) enabling sort of traditional desktop apps to be delivered in (theoretically) any modern web browser on any device that has one. It has far more forward-compatibility with a wider range of platforms.

The real problem (beyond technical things like 'sandboxing') is that in reality the big browser vendors are the ones who really decide what they'll support and when they'll support it. Apple will often put new features in the developer menu marked as experimental options that can be toggled on/off. But I'd say that generally many HTML5 APIs are widely supported by most browsers in the past 7 years or so. I think it's safe to say that support for HTML5 APIs and web apps will be around for a long time.

[overclockedmind]

Moving targets... y'know. Re: The Web.

But, I could see each of us being able to build a Web browser in OXT too, supported for our host systems, soo...