Looking good.
Tried the sneak peak of this and man does it feel smooth! For Cardinal it needs a few kinks resolved I guess. Removing the resize handle so you don’t accidentally mess up the view.
Also it’s not possible to switch to 256 frames (which could help a bit with performance and xruns), but I’m sure that can be resolved.
@falkTX could you clarify your thinking here? I do not know what Cardinal is but how does this fit with the ModX platform. What are you exploring and why?
My extremely excited vision is you’d offer an alternative to the Mod custom hardware with using a Web browser, leveraging Wasm to allow cross compilation of existing code. Then given a URI I could load and run a board in seconds. I think it can be cached to run offline too. Then someone could fork my URI, using the existing Mod UI to edit it and save their version.
But does that fit the MOD biz plans in anyway? It’s a pivot form hardware.
It obviously requires APIs that mimics whatever OS services Mod currently uses. Plus ports of libraries. But from the above Cardinal thing I guess you think webAudio might be usable? That must be critical?
The reason I think stackblitz might be a good partner is they have worked with Browser vendors and standards to develop their WebContainer technology. While this is currently used to provide an in-browser node stack it might well be able to support WebAudio etc as required for the Mod platform. Ie a new Mod WebContainer .It might be mostly proprietary but they might be willing to collaborate - they are great guys (I discussed working with them at one time). This could allow you to work higher up the stack rather than emscriptem hacking audio drivers etc.
Cardinal is mostly unrelated, it is just one of the plugins that we can make it work this way.
I think you are confusing my intention here.
What I am trying to showcase is an alternative to how we create modguis.
Until now the only way to have a modgui was a collection of html, css and javascript.
My idea is to bring over the stuff others have built for web-assembly and web-gl and have that as the modgui. It still needs html/css/js, but the actual user interaction and logic does not happen there, the html/css/js stack on these custom web-assembly modguis are just a wrapper.
Audio never runs in the browser, and that has never been the intention. I mention “audio” being there in Cardinal just to simulate what the desktop version does and have matching animations. There is no real audio being generated with the web-assembly modguis.
And if it was not clear, none of the web-assembly related work is made on MOD working hours, it is completely unrelated to any business plan from MOD. It is 100% me being bored during holidays and wanting something exciting to do.
Got it. Thanks.
I obviously got over excited:)
Fantastic work, as usual, @falkTX. I hadn’t checked the forum over the holidays and could enjoy how things evolved over the course of a few minutes. I would have opted for the separate Windows mode, to gain more space and avoid integrating it into the MOD UI but with your last explanation it makes a lot of sense to implement it the way you did. Thanks for sharing the journey with WASM!
I’m keenly interested in this. Would love to get the infamous lushlife on mod but have been too intimidated at the thought of the HTML/java/css needed to even start. Not sure what it will take to extend your work to other toolkits, but wouldn’t mind being a guinea pig.
I made this with DPF with a custom pugl wasm implementation, so in theory anything else using pugl would be able to make use of the implementation too.
So far we only have OpenGL (or better said, GLES2 via WebGL) though I already did the work to get cairo building on wasm. Dont know how to map a cairo context to wasm, we can always just try to render into a GL texture and draw that.
The first step here would be to update your plugins to use the latest pugl. Or alternatively just convert the raw LV2 code to DPF… You get automatic cross-platform builds and several plugin formats all at once
I was wondering if drmr could benefit from this? Here you said it lacks only the UI part, and we’d have fully-featured drum machine on MoD platform. Now, when native UI can be ported, maybe it makes things easier?
drmr uses gtk for its UI, a wasm version is out of scope for that.
any anyhow the UI is not too complex, a regular html/css/js could work for that specific plugin