Use Godot for the user interface and input

[TechnoPorg]

Enhancement Summary

I propose that LMMS should switch to using Godot, rather than QT, for its user interface and input handling. Possibly audio as well, although I'm not sure if Godot's sound system would work well for what LMMS needs. The backend code would become a GDExtension plugin. I would recommend going with 4.0.dev right away, even though it's not stable, to avoid porting everything from 3.x to 4.0 later.

Justification

There are several reasons why I believe this to be a good idea:

• QT is massive. v5.15.12 for Windows, which I have installed currently, is 2.28GB. Godot 4.0.dev (https://github.com/godotengine/godot/commit/77721b35ba21f2e7e8bb42cf415fccb018517843) with debug symbols is only 193MB.
• With Godot the UI could be edited with an editor, rather than through code.
• UI/UX elements could be handled in a GDScript, a higher-level language designed specifically for Godot, if desired. QT does have QML, so this point on its own isn't a win for either option.
• However, Godot makes application plugins incredibly simple. All you have to do is load a .pck containing a plugin scene, instance said scene, and the plugin is running with full access to the UI elements. This plugin would likely be written in the aforementioned GDScript, which is easy to use.
• It would fix the situation where LMMS has to be installed on Windows in order for the executable to have access to the assets.
• It would be a logical point to implement a whole bunch of big UI changes, notably #1911. If this proposal is accepted I'll gladly try implementing it and overhauling the UI.

  Mockup

  Sorry to inflict my lack of art skill on your eyes :)

[irrenhaus3]

Pretty interesting idea to use a game engine for the UI layer, although I can imagine a few performance issues arising from the fact that these usually run on a constantly iterating game loop instead of updating on events only. But maybe that's not too much of a concern. It is true that the QT Widgets library is rather old and makes UI design more cumbersome than modern app development is used to, and LMMS would definitely benefit from adaptable frontends in the long term. Take note though that replacing the frontend implies a massive refactor that for now is very likely unfeasible. There is an idea to separate frontend and "business logic" on the binary level by moving core functionality into a library and implement the UI in the actual executable file, that then calls into the core library. We're still pretty far from being able to do that, however.

Long story short: Interesting idea, but probably not possible right now.

[Veratil]

@SeleDreams has already worked with some mockup stuff using Godot.

[midi-pascal]

Something to worry about: on github the Godot project has 5,380 open issues today. Personally I would not base any of my own projects on such an unstable platform.

[Veratil]

Something to worry about: on github the Godot project has 5,380 open issues today. Personally I would not base any of my own projects on such an unstable platform.

That doesn't mean it's unstable.

[midi-pascal]

So remove the word "unstable" :-)

[Veratil]

Well then we shouldn't use Qt either since it has 19,418 bugs open. Your argument is moot.

[irrenhaus3]

And while we're at it, let's talk about Javascript. ;-) Just to be clear, the possibilty of multiple different LMMS frontends is a good idea in my book. The main point why it's not feasible right now is the tight coupling in the codebase, not the viability of the frontend platform. Once we can refactor the codebase to remove this coupling, whoever wants to implement a frontend should be free to do so. Just needs a lot of preliminary work to be completed first.

[SeleDreams]

so, when it comes to godot, godot actually has a mode meant to allow software development that can be enabled that makes it run in low processor mode and the UI nodes can be refreshed only when content changed without having to refresh them every frame

I at least have the basis of a piano roll made on godot

(it's a piano roll originally meant for a vocaloid-like editor which is like i have lyrics on the notes)

[ca3games]

Oh yes, this will make it so much easier to make scripts for LMMS. I will love if this happens.

@irrenhaus3 godot can easily run in low processor mode, which means it will only redraw when there's an event in the game. @midi-pascal I've found godot to be quite stable, and most of those bugs gets fixed very fast, godot is now a big project and development is going pretty fast right now.

[ca3games]

@TechnoPorg Do you think it would be possible to make some port to Godot, I'm a godot user, so maybe I can help with that. Even though I can't code with C++

[Daniele71]

What about using libSweell ? Guys, Reaper it's just 100Mb (a bit more).

[Veratil]

What about using libSweell ? Guys, Reaper it's just 100Mb (a bit more).

I can't seem to find anything named libSweell. Can you provide a link?

[Daniele71]

What about using libSweell ? Guys, Reaper it's just 100Mb (a bit more).

I can't seem to find anything named libSweell. Can you provide a link?

Should be here: https://github.com/justinfrankel/WDL/tree/master/WDL/swell

[TechnoPorg]

Do you think it would be possible to make some port to Godot, I'm a godot user, so maybe I can help with that. Even though I can't code with C++

@ca3games A port to Godot will absolutely be possible in the future, but not with how the UI stuff is set up right now. @irrenhaus3 you had said that core/frontend elements need to be decoupled before any major UI changes can be made, is there any way I can help with that?

What about using libSweell ? Guys, Reaper it's just 100Mb (a bit more).

@Daniele71 I feel that Swell isn't the best option to make a frontend for LMMS, because as far as I can tell there's no editor, just C++ code, which is pretty similar to QT. Also not a lot of people have ever heard of it, me included before today, which makes it more intimidating for new contributors. Lots of people know Godot, and thus would more easily be able to contribute.

[Veratil]

@irrenhaus3 you had said that core/frontend elements need to be decoupled before any major UI changes can be made, is there any way I can help with that?

Check out #5592

[Daniele71]

@TechnoPorg I'm not a developer, so I don't know if and how is useable but damned, inside Reaper it'a just 700Kib !

[SeleDreams]

I think one advantage of using Godot could be thanks to the huge community of Godot Engine, I think improvements to the Godot Engine could benefit LMMS, while improvements to LMMS could benefit the Godot Engine, as often Godot developers want to improve the workflow of open source asset creation tools with Godot

[qnebra]

Lmms ported to GTK just for porting it to GTK. I am in.

[Veratil]

Let's focus on getting the core split from Qt and then we can have fun with frontends. 😁

[hobyst]

Rather than going for the route of using a game engine as a framework you could just go away from QT to then split window and input handling from UI description and rendering. In order to do this, using Dear ImGUI with one of the existing renderer backends plus using something like GLFW for the window and input handling would essentially do the same as using Godot as a development framework without having to deal with a whole game engine being a part of the build and development process when there's no need to. At least that's what I think so, as here are a lot of open source applications that have suffered from having their code base attached to a certain development framework and leaving Qt to go for Godot or even GTK would be getting out from one rabbit hole just to dig into another one.

[rdrpenguin04]

There are so many options; the point is not to switch frameworks but to make it possible to use other frameworks. I don't see LMMS fully leaving Qt anytime soon, but I do see other options becoming available and possibly standard as well (more akin to Freeciv).

[allejok96]

And Qt is used for so much more than just GUI. It provides memory cleanup and the signal/slot mechanism. Plus some other silly stuff like XML, I/O, timers, smart pointers, threads, vectors, string translation and debug messages. All of this can be done in some other way but someone's got to do it.

This little experiment tells us we have 12362 cute problems to fix, and 1792 of them are in src/core:

grep -rE "\W([Qq][A-Z]|Qt::|Q_)[A-Za-z]+|\W(dis)?connect\(" --include=\*.{h,cpp} --exclude-dir={carla,3rdparty,zynaddsubfx}

I'd say if someone wants to improve LMMS - roll up your sleeves, learn C++ and Qt and help us make the best of what we have.

[SeleDreams]

ngl the advantage of godot wouldn't reamly be about not having to learn Qt or C++, which I already know

the advantage is more in portability, godot is ultra portable, so making it work on all platforms is way easier

Le lun. 25 oct. 2021 à 17:38, Alex @.***> a écrit :

And Qt is used for so much more than just GUI. It provides memory cleanup and the signal/slot mechanism. Plus some other silly stuff like XML, I/O, timers, smart pointers, threads, vectors, string translation and debug messages. All of this can be done in some other way but someone's got to do it.

This little experiment tells us we have 12362 cute problems to fix, and 1792 of them are in src/core:

grep -rE "\W([Qq][A-Z]|Qt::|Q_)[A-Za-z]+|\W(dis)?connect(" --include=*.{h,cpp} --exclude-dir={carla,3rdparty,zynaddsubfx}

I'd say if someone wants to improve LMMS - roll up your sleeves, learn C++ and Qt and help us make the best of what we have.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/6194#issuecomment-951053581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4UF4PP256ZSQPJFAAZRADUIV2X7ANCNFSM5F237PUA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[j0hnys]

That would be very nice to do. I am using Godot now for making UIs for non-critical applications and I can say that it is a nice experience so far. It has the potential to scale as I have seen other applications using it in bigger projects.

I wanted to work on LMMS codebase a few months ago in order to make a custom UI so I can drive the various knobs on instruments using grid canvas, mouse, keyboard but the thing that stopped me was the size of Qt and setup. Also I looked at Qt project and it kinda seems that they fade out the open source version which is a major no for me. In the end I made the app outside of LMMS and interact with it through MIDI.

If my experience is relevant to someone new to LMMS codebase then leaving Qt for something else (hopefully Godot) can possibly increase the amount of new contributors.

(I am lurking in this repo for quite a while now but never participated in anything as I am not familiar with the context. This issue spoke to my heart and I thought that my input could be helpful now.)

[e792a8]

Doubting whether Godot is a good choice for such a big application... I was eagerly looking for a flexible UI layout with the docking panels, like Visual Studio and Eclipse and also mentioned in an issue 6 years ago here: https://github.com/LMMS/lmms/issues/1911#issuecomment-88131481 I consider the docking should be a basic UI feature for big applications - even VC++6.0 did this better than most of others - and with Qt this mightn't be too difficult since we have QDockWidget: But Godot seems not intended for applications with complex UI. I haven't found any supports in Godot even for multi-window. The fact seems seldom anyone care about this. Even QtCreator itself does not support dockings. Even, we have few to choose from except Qt... Maybe currently we should just focus on detaching core part from UI/Qt?

[SeleDreams]

Godot actually supports multiple windows, however it uses virtual windows in the main program rather than OS ones as it is made to be fully portable so not relying on any OS stuff, same for the file explorer it allows to have an open file menu etc but it relies on its own file browser

Le mer. 27 oct. 2021 à 19:26, zhou u74a8 @.***> a écrit :

Doubting whether Godot is a good choice for such a big application... I was eagerly looking for a flexible UI layout with the docking panels, like Visual Studio and Eclipse and also mentioned in an issue 6 years ago here:

1911 (comment)

https://github.com/LMMS/lmms/issues/1911#issuecomment-88131481 I consider the docking should be a basic UI feature for big applications - even VC++6.0 did this better than most of others - and with Qt this mightn't be too difficult since we have QDockWidget:

https://camo.githubusercontent.com/6d56d2c119837efca1b1c5eb6f9e65085c099c6516477e68e919c1e58a528700/68747470733a2f2f696d672d626c6f672e6373646e2e6e65742f3230313630343232313433343035333830 But Godot seems not intended for applications with complex UI. I haven't found any supports in Godot even for multi-window. The fact seems seldom anyone care about this. Even QtCreator itself does not support dockings. Even, we have few to choose from except Qt... Maybe currently we should just focus on detaching core part from UI/Qt?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/6194#issuecomment-953148543, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4UF4K45HVIBQCJ74MLR3LUJAY3LANCNFSM5F237PUA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[qnebra]

Maybe currently we should just focus on detaching core part from UI/Qt?

Exactly. It wouldn't be possible to made GTK, Godot, whatever framework version of LMMS with QT being in core.

[eagles051387]

From what I saw on the godot website its geared for game development more than anything or am I mistaken on that front?

Edit (Spekular): removed email stuff

[j0hnys]

@e792a8 @eagles051387 Yes, Godot is geared towards game development but even the co-creator of the engine has acknowledge the fact that UI for general purpose applications is a use case that is being seen more and more and that trend is increasing.

Generally Godot has a special mode which only refreshes the UI per user input, like a traditional UI toolkit, and it is made for that reason. That is because the UI in the engine is made by the engine itself.

Additionally Godot already has a mechanism in which you can build the engine with a selection of components in order to reduce the executable size. Currently there is no mode for the UI only AFAIK but that can possibly be added.

My thinking with Godot (and the reason for looking into making UI with it) was like this:

I can create UI easily that is themable and organize it the way I want with a MIT open source engine with proof that it can be used in relatively large applications. The UI is "super" cross-platform in the sense that it does not only export for desktop, mobile and web but for game consoles as well which is something that no other UI toolkit is capable of doing AFAIK. Also we have VR and AR coming in the future and the UI toolkits might need the capability of complex interactive 3D renderings which it already does.

Another fun fact is that the Tesla mobile app (for the car) uses Godot.

Sorry for the long post, I am generally excited with Godot for many years now. Of course I can not persuade everyone to use Godot and LMMS developers know what's best for the project. I can only state my reasoning and why it might be a good thing to investigate that solution.

[Gabrielxd195]

I don't know anything about programming but I love godot, but researching about the subject I found this:

https://kivy.org/#home

I don't know guys I got excited, but maybe this could be of help.

[SeleDreams]

I don't know anything about programming but I love godot, but researching about the subject I found this:

https://kivy.org/#home

I don't know guys I got excited, but maybe this could be of help.

It's python, this isn't appropriate.

Godot although it has support for higher level languages is fully programmed in C++

[rdrpenguin04]

I mean, a potential UI could be programmed in PERL for all we care. Python isn't necessarily a bad choice, but there should be at least one UI available in C++.

Probably. I'm not an expert here.

[SeleDreams]

I mean, a potential UI could be programmed in PERL for all we care. Python isn't necessarily a bad choice, but there should be at least one UI available in C++.

Probably. I'm not an expert here.

I could understand an UI in C# or co, but python is a very high level language with dynamic typing, interfacing with the C++ source would be a pain and would lead to performance issues

[Marzin-bot]

I think it would be better to use a web interface like Electron. It has therefore proven its worth in software design. (Discord, Visual Studio, ...)

[Marzin-bot]

And then for the critical aspect we can use wasm.

[RiedleroD]

If LMMS switched to electron, I'd have to switch to a different DAW. Discord is already hardly navigatable for me, and I think using electron in general would be a massive downgrade to the current Qt5 GUI.

[wwderw]

As someone that does use Godot for regular application developed, it does make for a stable SDK for such.

Keep in mind, Godot UI itself, is also using the engine (eating one's own food so to speak).

There is a low processor mode, it does allow for manual memory management as well. Just try to stay away from delta time type of coding (or make sure to manually handle the memory) and it should be good.

Can use other langues (C++ and even Rust, I like Nim myself, but I digress) as well if don't want to use GDScript as much.

Godot will still be less resource heavy compared to Electron, so keep that in mind as well. Pixelorama and Material Maker are good projects that are made using the Godot Engine (and Pixelorama to my knowledge is still all GDScript).

[Marzin-bot]

Si LMMS passait à l'électron, je devrais passer à un autre DAW. Discord est déjà difficilement navigable pour moi, et je pense que l'utilisation d'électrons en général serait une rétrogradation massive par rapport à l'interface graphique Qt5 actuelle.

You have to distinguish between the ease of use of a web application and the technology it uses. I don't see why we shouldn't use electrons just because Discord is "hard to use". This argument does not hold water. In addition, I do not see how it will be a downgrade on all the advantages of the web with the webkit optimizations. Without forgetting the management of the user interface. You can imagine that Webkit is very optimized. Qt5 is simply less powerful than Webkit / Electron.

[Marzin-bot]

En tant que personne qui utilise Godot pour le développement d'applications régulières, cela constitue un SDK stable pour cela.

Gardez à l'esprit que Godot UI lui-même utilise également le moteur (manger sa propre nourriture pour ainsi dire).

Il existe un mode processeur faible, il permet également une gestion manuelle de la mémoire. Essayez simplement de rester à l'écart du type de codage à temps delta (ou assurez-vous de gérer manuellement la mémoire) et cela devrait être bon.

Peut utiliser d'autres langues (C++ et même Rust, j'aime bien Nim moi-même, mais je m'égare) aussi si je ne veux pas autant utiliser GDScript.

Godot sera toujours moins gourmand en ressources par rapport à Electron, alors gardez cela à l'esprit également. Pixelorama et Material Maker sont de bons projets réalisés à l'aide du moteur Godot (et Pixelorama, à ma connaissance, est toujours entièrement GDScript).

To say that godot takes less resources than electron is far too easy. WHAT if you code a big 3D game in Godot? you're just going to take a lot of CPU and GPU power. Likewise, if you are using Electron to display big CSS shaders, that will also take a lot of resources.

What I mean by that is that Electron's resource consumption depends on what you are actually doing. Electron takes fewer resources if you compare the power required to run VisualStudio (based on the Electron) and Godot, you will find that Visual takes several orders of magnitude in fewer resources than Godot.

In addition, the rendering of the user interface is set if there is nothing new to display and this is done internally (WebKit optimization). Not to mention CSS which is much more powerful than Godot's UE. These are the web-based technologies and therefore many developers are proficient in them. I can see many contributors creating LMMS addons in JS / WASM. The advantages are simply enormous and believe me if we could create a text editor such as Visual Studio is that Electron does not take a lot of resources.

The advantages of using Electron over Godot are simply huge.

[wwderw]

What I mean by that is that Electron's resource consumption depends on what you are actually doing. Electron takes fewer resources if you compare the power required to run VisualStudio (based on the Electron) and Godot, you will find that Visual takes several orders of magnitude in fewer resources than Godot.

I don't know about this. And it also may depend on the host platform I think it all depends on what you are using within VSCode as well versus Godot. On Linux, I see far significant less resource consumption with Godot versus any Electron app that I have created or have used created by people that probably did things better compared to myself (coding wise).

I could see more with using Webview compared to full blown Electron. Node and even customized Chromium is a lot of resource usage before getting to the app itself. While I am not a fan of GTK and personally prefer Qt over it, Webview would, in my opinion, be better compared to full on Electron. Now the one argument that you could have with Electron versus Webview is that don't have to do much CSS/SVG work to make sure everything renders the same on all platforms. It's not to bad to do that with Webview with SVGs and use those instead of the default renders of the platform.

Using Webkit (not Electron) over Godot, maybe, it all depends on what one is trying to do.

Using web-browsers (be it stripped down webview or custom chromium/node) are trying to shoehorn a browser environment for a desktop application.

Now immediate mode gui isn't so much the issue that a lot of people think that it is. Even using Raygui (a module of Raylib) with C++, could see roughly the same as Qt (depending on the complexity of the app). Shoot Blender is immediate mode with openGL.

[SeleDreams]

this comparison doesn't make sense, of course is we make a big 3d game it would take more resources

a big 3d game in godot tho would still be more efficient than a big 3d game in JS

Le mar. 16 nov. 2021 à 01:07, Marzin @.***> a écrit :

En tant que personne qui utilise Godot pour le développement d'applications régulières, cela constitue un SDK stable pour cela.

Gardez à l'esprit que Godot UI lui-même utilise également le moteur (manger sa propre nourriture pour ainsi dire).

Il existe un mode processeur faible, il permet également une gestion manuelle de la mémoire. Essayez simplement de rester à l'écart du type de codage à temps delta (ou assurez-vous de gérer manuellement la mémoire) et cela devrait être bon.

Peut utiliser d'autres langues (C++ et même Rust, j'aime bien Nim moi-même, mais je m'égare) aussi si je ne veux pas autant utiliser GDScript.

Godot sera toujours moins gourmand en ressources par rapport à Electron, alors gardez cela à l'esprit également. Pixelorama et Material Maker sont de bons projets réalisés à l'aide du moteur Godot (et Pixelorama, à ma connaissance, est toujours entièrement GDScript).

To say that godot takes less resources than electron is far too easy. WHAT if you code a big 3D game in Godot? you're just going to take a lot of CPU and GPU power. Likewise, if you are using Electron to display big CSS shaders, that will also take a lot of resources.

What I mean by that is that Electron's resource consumption depends on what you are actually doing. Electron takes fewer resources if you compare the power required to run VisualStudio (based on the Electron) and Godot, you will find that Visual takes several orders of magnitude in fewer resources than Godot.

In addition, the rendering of the user interface is set if there is nothing new to display and this is done internally (WebKit optimization). Not to mention CSS which is much more powerful than Godot's UE. These are the web-based technologies and therefore many developers are proficient in them. I can see many contributors creating LMMS addons in JS / WASM. The advantages are simply enormous and believe me if we could create a text editor such as Visual Studio is that Electron does not take a lot of resources.

The advantages of using Electron over Godot are simply huge.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/6194#issuecomment-969472872, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4UF4OQ62QJRJHEMVX6UZ3UMGOFTANCNFSM5F237PUA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[Marzin-bot]

1: JS code is faster than GDScript. (via Google v8 engine). 2: Just because a game is encoded in an interpreted language doesn't mean that the game in question will be absolutely slow because JS or GDScript code only calls APIs that are usually written in C ++. 3: If you are not convinced then tell me why use Godot with GDScript when it does not match the speed of C ++? Why Blender uses Python to create 3D APIs and ADDON? Not all of these languages ​​are very fast, yet they do the job they are asked to do. And I remind you that we can use WASM for the critical parts of a Web application.

Electron is a great fit for the LMMS and there is already music design software like LMMS that works great on the Electron. (and more generally directly in the web browser)

[rdrpenguin04]

First of all, GDScript is remarkably fast. Second of all, you don't have to use GDScript with Godot; there are other language options. JS does not mix well with high performance audio applications. I would know; I've tried to make an audio worklet, and it's incredibly slow. I would not recommend Electron even remotely for LMMS. Nevertheless, once we abstract the UI out, it would be possible.

[Marzin-bot]

exemple: https://www.audiotool.com/product

Tout d'abord, GDScript est remarquablement rapide. Deuxièmement, vous n'êtes pas obligé d'utiliser GDScript avec Godot ; il existe d'autres options de langue. JS ne se mélange pas bien avec les applications audio hautes performances. je le saurais ; J'ai essayé de créer un worklet audio, et c'est incroyablement lent. Je ne recommanderais pas Electron même à distance pour LMMS. Néanmoins, une fois que nous aurons extrait l'interface utilisateur, ce serait possible.

You have therefore not used the audio APIs of the web browser correctly. There is software online that can take full advantage of Browser Audio (www.audiotool.com). Plus, you can use WASM for speed. (I guess it is quite possible to create software written in JS and optimized as is the case for Audiotool)

[Marzin-bot]

GDScript 2.0 is fast, but not always faster than JS.

[SeleDreams]

1: JS code is faster than GDScript. (via Google v8 engine). 2: Just because a game is encoded in an interpreted language doesn't mean that the game in question will be absolutely slow because JS or GDScript code only calls APIs that are usually written in C ++. 3: If you are not convinced then tell me why use Godot with GDScript when it does not match the speed of C ++? Why Blender uses Python to create 3D APIs and ADDON? Not all of these languages ​​are very fast, yet they do the job they are asked to do. And I remind you that we can use WASM for the critical parts of a Web application.

Electron is a great fit for the LMMS and there is already music design software like LMMS that works great on the Electron. (and more generally directly in the web browser)

technically you can program in godot using nothing but C++, that's often what I do the main issue of web based frameworks is that they're heavy and i don't talk about the code of the app itself, the web browser in itself is heavy, they're often based on chrome, and chrome has a lot of ram usage godot at least can directly communicate with the GPU and CPU rather than going through a sandbox (web based stuff is always sandboxed for security) another issue is JS, JS is just not a good language at all and lots of js programmers program like shit, making lmms JS would only bring lots of bad code

[Marzin-bot]

Electron exposes features that are not directly available in web browsers, which allows direct communication with the user's operating system. So no sandbox problem

[SeleDreams]

What's sure at least is I wouldn't contribute code to a JS/browser based project as it's just too much of a mess

[Marzin-bot]

moreover, with the arrival of WEBGPU, it will be possible to communicate directly with the GPU with native performance while maintaining security.

[Marzin-bot]

On the other hand, it's much less complicated, that's the whole advantage.