Lv2 UI - Testing #7201

JohannesLorenz · 2024-04-08T21:11:18Z

This is solely for early testing yet. From the code review perspective, there are still a few things to be done.

When reporting an issue, please try to answer the following questions:

Does this issues occur in any other host, like Ardour/Jalv/...?
If the issue happens with UI, does it also happen if UI is turned off? (Edit -> Settings -> Performance -> Plugins -> External plugin embedding -> "No embedding")

Open issues:

src/core/lv2/Lv2Proc.cpp

JohannesLorenz · 2024-05-12T22:41:22Z

This now runs successfully in the CI, and it supports UI there for Linux and Macos, but not Windows yet. @DomClark , as discussed, I would appreciate if you would submit a vcpkg PR (and then add suil to our vcpkg.json in this PR or tell me to). In the end, the CI for Windows should not show

* SUIL for plugin UIs         : not found, install it or set PKG_CONFIG_PATH appropriately

but

* SUIL for plugin UIs         : OK

zonkmachine · 2024-05-19T20:34:16Z

Dexed.

When I press it's built-in keyboard there is only sound in the left channel.
Sending a note from lmms presents sound on both channels but if I change sound on Dexed, the left channel will follow the new setting but the right will stay with the default sound.
Octaves. Dexed C4 corresponds to LMMS C5. Both can't be right. Right?

zonkmachine · 2024-05-20T16:34:43Z

When I press it's built-in keyboard there is only sound in the left channel.

I assume it's related to this PR: #7247

messmerd · 2024-05-20T18:55:21Z

I assume it's related to this PR: #7247

The LV2 implementation in LMMS uses linked models, so mono plugins are actually 2 linked plugin instances (L and R) behind the scenes. Linked models need to be kept in sync for parameter updates which is already a complicated task, but adding a UI where updates can come not just from LMMS but also the plugin itself makes the linked model design untenable in my opinion. The issue with dexed sounds like exactly the type of synchronization problem I feared.

I would strongly recommend to @JohannesLorenz to replace the linked model design with the L/R routing design from #7247 once it's merged. I've been using it successfully for both CLAP and VST plugins and it works great. Making the switch will almost certainly be less work than trying to fix the bugs with linked models.

Not only is the L/R routing approach dramatically simpler and less buggy than trying to use linked models, it is also very flexible and intuitive from a user standpoint and uses roughly half the resources in the common situation where you only want a mono-to-stereo mix from your mono plugin.

michaelgregorius · 2024-06-02T20:35:48Z

I assume it's related to this PR: #7247

The LV2 implementation in LMMS uses linked models, so mono plugins are actually 2 linked plugin instances (L and R) behind the scenes. Linked models need to be kept in sync for parameter updates which is already a complicated task, but adding a UI where updates can come not just from LMMS but also the plugin itself makes the linked model design untenable in my opinion. The issue with dexed sounds like exactly the type of synchronization problem I feared.

Has this already been fixed? It sound like a waste of resources, a source for tons of bugs and a complete misunderstanding of how these things work. Sorry, if I am a bit blunt here but keeping it like this would take the implementation in a completely wrong direction. I am pretty sure that no other DAW implements it like this.

If a plugin reports as mono then simply copy the resulting mono output buffer of the single instance into the left and right channel buffers of the stereo track.

I would strongly recommend to @JohannesLorenz to replace the linked model design with the L/R routing design from #7247 once it's merged. I've been using it successfully for both CLAP and VST plugins and it works great. Making the switch will almost certainly be less work than trying to fix the bugs with linked models.

100% agree!

tresf · 2024-06-05T04:35:42Z

I pushed a few commits to help with AppImage findings over on Discord's #testing channel.

For now, I copy the suil-0 modules to <APPDIR>/lib/suil-0/, but I can't find a suil API to notify it of this location, so per @JohannesLorenz's advice, I set SUIL_MODULE_DIR in our launcher script.

(Until #7252 is merged, I can't test this on ARM64, so I'm just hoping this fixes the AppImages)

Initial testing on MacOS is OK but we don't use a launcher script for MacOS, Perhaps qputenv() combined with qApp->applicationDirPath() + "../Frameworks/suil-0/? Thoughts welcome

tresf · 2024-06-05T05:43:13Z

Initial testing on MacOS is OK but we don't use a launcher script for MacOS, Perhaps qputenv() combined with qApp->applicationDirPath() + "../Frameworks/suil-0/? Thoughts welcome

Done via 5bb73b0. Feel free to move the code elsewhere if needed.

Related LMMS#7201

src/gui/GuiApplication.cpp

zonkmachine · 2024-06-15T10:31:16Z

When I reload a project the lv2 gui doesn't update. The settings seem to stick, just the gui is showing it's init setting.

JohannesLorenz · 2024-06-15T14:22:57Z

When I reload a project the lv2 gui doesn't update. The settings seem to stick, just the gui is showing it's init setting.

@zonkmachine Can you please elaborate?

I did:

Creat a new Lv2 project, opened Vitalium, changed some params, saved the project
File -> Recently Opened Projects ->
Reopen the Vitalium UI

=> All params are as before.

Did I understand "reload" wrong?

zonkmachine · 2024-06-15T15:12:44Z

* Creat a new Lv2 project, opened Vitalium, changed some params, saved the project

* File -> Recently Opened Projects ->

* Reopen the Vitalium UI

=> All params are as before.

With nekobi I do:

I save and reload and I get:

The sound is the same as when I saved but the settings show a default nekobi.

JohannesLorenz · 2024-06-15T16:14:45Z

@zonkmachine Thanks. I fixed it.

zonkmachine · 2024-06-15T23:41:59Z

@zonkmachine Thanks. I fixed it.

This took care of the instruments but the effects see the same issue and this is not fixed by 3bcf80b.

JohannesLorenz · 2024-06-16T00:20:09Z

This took care of the instruments but the effects see the same issue and this is not fixed by 3bcf80b.

Actually, this commit should have fixed it for both... Which effect do you mean?

Sometimes, producing input for an effect (i.e. pressing a key) might force a lazy UI to update. Not sure if this helps here.

zonkmachine · 2024-06-16T00:38:19Z

Actually, this commit should have fixed it for both... Which effect do you mean?

Ping Pong Pan
3 Band Eq
GxRedeye Chump

There were more. Actually, the only Lv2 effect with gui that I've come across that works in this regard is Calf Analyzer (not an effect per se but the stored parameters are displayed correctly when reloading a project).

Sometimes, producing input for an effect (i.e. pressing a key) might force a lazy UI to update. Not sure if this helps here.

Nope.

JohannesLorenz · 2024-06-16T08:02:01Z

Oh, I get it. For instruments, first, the instrument is loaded, which includes loading the savefile. Only after that, the UI is initiated - at which time the mentioned fix sends all port values (knobs, sliders etc) to the UI.
For effects, the UI seems to be opened immediately, and the default values are sent to the UI. Only after that, the savefile values are being loaded, but they are not sent to the UI anymore.

Thinking about a fix...

Confirming: Ardour sends port updates of all ports to UI after loading a preset (LV2PluginUI::queue_port_update).

zonkmachine · 2024-06-16T10:12:08Z

New issue. The setBfree organ plugin doesn't save the settings at all.

JohannesLorenz · 2024-06-16T11:09:11Z

New issue. The setBfree organ plugin doesn't save the settings at all.

Does this work in Ardour or another DAW ~~(my favorite question to procrastinate all bugs)~~?

zonkmachine · 2024-06-16T11:26:02Z

Does this work in Ardour

Yes. Works fine in Ardour.

zonkmachine · 2024-06-16T12:03:46Z

setbfree gui explained here: https://setbfree.org/lv2/lv2_setbfree_up.html
I think it could be because it uses presets and it's not implemented yet. Like Dexed.

JohannesLorenz · 2024-06-16T12:16:06Z

I think it could be because it uses presets and it's not implemented yet. Like Dexed.

I think some use "Preset" and some use "State". Multiple of them contain "organ" in the description. Do you mean any specific one?

zonkmachine · 2024-06-16T12:18:36Z

Do you mean any specific one?

No. I'm very unspecific here.

JohannesLorenz · 2024-06-16T14:05:40Z

I cannot reproduce your Dexed issues: I turned all 8 "EG" level in "1" to 0, and when loading, they were still 0 and I think it sounded correct. How do I reproduce?

With X42 whirl (from the b_free plugins), I can reproduce the issue.

Gabrielxd195 · 2024-08-10T03:36:01Z

Don't you think it would be better if lv2 plugins had their own separate window like vst plugins? Don't you think it would be better to have a "vestige" type instrument but for lv2 plugins? I think we would have two advantages over the current way of displaying lv2 instruments and that is that it would be better visually and more consistent with the size of the other instruments, and that each plugin has a different size, they cannot be resized and this can be very annoying on small screens.

The other advantage would be better performance since on low-resource computers the graphical interfaces of the plugins being open can consume more resources; however, from a "vestige" type instrument window but with the option (a "Show/Hide GUI" button) to show the graphical interface to make some precise changes, you can control some parameters of the plugin without opening its graphical interface.

(Google Translate)

JohannesLorenz · 2024-08-10T08:00:11Z

Some of the LV2's don't fit well in their windows. I don't remember this from earlier. This is how Dexed shows up, with a lot of margin on top and to the left and cut off on the bottom/right.

This is a know issue (still open in my checkbox list at the OP): "Sometimes, plugins UIs do not have optimal size.". This waits for L/R routing because after that, the way we put the plugin into the window changes.

. I also can't change the size of the window manually.

Dexed does not allow resizing. However, as soon as we have fixed the size, resizing should not be required anymore.

JohannesLorenz · 2024-08-11T23:49:17Z

@Gabrielxd195 Thanks for your input.

Don't you think it would be better if lv2 plugins had their own separate window like vst plugins? Don't you think it would be better to have a "vestige" type instrument but for lv2 plugins?

I don't find it necessary to be exactly like VST.

it would be better visually and more consistent with the size of the other instruments

This could be a point, but most Lv2 instruments already have a larger than the default size (before lv2-ui). We did this to use the space better, especially on large monitors. E.g. try Helm, putting all these knobs into the small default-sized window with only 1 vertical scrollbar would be insane to navigate.

The other advantage would be better performance since on low-resource computers the graphical interfaces of the plugins being open can consume more resources; however, from a "vestige" type instrument window but with the option (a "Show/Hide GUI" button) to show the graphical interface to make some precise changes, you can control some parameters of the plugin without opening its graphical interface.

We had a discussion in Discord lately, and the result was that I wanted to try out a TabWidget, like we currently have it for the Instrument Track Window already (where you can switch between Plugin, Envelopes, MIDI etc.). If the UI is hidden at the start, it can be loaded at the moment where the user switches the TAB.

Ultimatively, it is up to the users what they prefer. But whatever we do, it is a UI thing, so we can still change it easily...

zynskeywolf · 2024-08-12T08:07:45Z

In any case there must not be another step to open the ui just because it's external. The way vestige works is horribly unintuitive and lv2 needs to move away from that approach. Plugin handling must be transparent and the user should get the same experience regardless of the plugin format.

michaelgregorius · 2024-08-12T15:59:20Z

In any case there must not be another step to open the ui just because it's external. The way vestige works is horribly unintuitive and lv2 needs to move away from that approach. Plugin handling must be transparent and the user should get the same experience regardless of the plugin format.

It might not be the scope of this pull request but in general I agree with what @zynskeywolf wrote. Ideally all external plugins should feel like entities of their own and the parameter handling should be transparent to the users (also with regards to plugin type, i.e. VST, LV2, CLAP, etc.). Many other DAWs just present you with a list of the available plugin parameters. If you select a parameter from that list you can then define the automation curve for it, etc.

I once did some investigation with regards to some problems with plugin parameters and if I remember correctly, what I found was that LMMS seems to automate the movement and changes of the GUI elements and not of the parameters themselves. If that is really the case then this would need to be changed first before better and more uniform parameter handling could be implemented. If I understand correctly then this is also the reason why some extra parameter widgets need to be shown for the parameters in the first place. If the automations worked directly on the plugin parameters then the would not be needed.

JohannesLorenz · 2024-08-12T19:50:56Z

In any case there must not be another step to open the ui just because it's external. The way vestige works is horribly unintuitive and lv2 needs to move away from that approach.

I agree here, though it is indeed a bit overhead to load the plugin UI. My idea is to have a tab widget to switch between both UIs. If the user previously selected the plugin UI, the next plugin will also let the TabWidget show the plugin UI. If they previously used the LMMS UI (the parameters), they get this when they open a plugin the next time.

@rpath

* CPack: Refactor AppImage and Apple DMG Generation * Switch from linuxdeployqt to linuxdelpoy * Add ARM64 AppImage support * Add support for `.run` installers using `makeself`, an alternative to AppImage * Refactor BashCompletion.cmake * Enable CPack debugging via `WANT_DEBUG_CPACK` * Add `download_binary`, `create_symlink` macros * Qt6: Fix @rpath bug on macOS * Detect and bundle LV2 UI Suil modules (Related #7201) * Allow remote plugins to honor `LMMS_PLUGIN_DIR` * Add .github/workflows/deps-ubuntu-24.04-gcc.txt * Fix waveforms FileDialog Co-authored-by: Dalton Messmer <[email protected]>

tresf · 2025-02-01T09:06:46Z

@JohannesLorenz, I've merged #7252 which moves the suil-0 stuff from shell scripts into cmake. This means when rebasing these conflicting files should just vanish:

cmake/apple/install_apple.sh.in
cmake/linux/package_linux.sh.in

http://lv2plug.in/ns/extensions/ui Size issues also fixed (but SlicerT is not happy as we removed `InstrumentTrackWindow::resizeEvent`... Co-authored-by: Tres Finocchiaro <[email protected]>

JohannesLorenz · 2025-02-01T21:52:21Z

This means when rebasing these conflicting files should just vanish

@tresf Thanks for the hint, that was really valuable when doing the rebase! Also, I saw your CPack review request for the bash completion - sorry, this week was too busy, I only took a quick glance and it looked good.

JohannesLorenz · 2025-02-02T10:27:31Z

This PR discovers a major bug in the Lv2 implementation. Short version: Many UIs will not save properly (yet).

Some plugins do not save their state via ports, but via "states". This is often the case for large, UI based plugins, like Zyn, which have so many ports that it gets easier to save them as one big blob of data (in case of Zyn, one XML file), which is being saved as one "state" rather than many ports.

Now, our Lv2 implementation does not yet support "state", which means even if you save a file, it will all be lost. I'm not yet sure if LMMS should reject plugins even that mark "state:interface" as an optional feature, or if we instead should implement "state" prior to Lv2.

messmerd · 2025-02-02T11:08:12Z

@JohannesLorenz
I had to do the same thing for CLAP. Originally I was manually saving and loading all the parameters, but sometimes plugins need to save/load information other than parameters, so now I always use the clap.state extension.

This is what saving/loading looks like with the CLAP's state extension implemented:

lmms/src/core/clap/ClapInstance.cpp

Lines 189 to 231 in 1b3b091

    
           void ClapInstance::saveSettings(QDomDocument& doc, QDomElement& elem) 
        
           { 
        
           	elem.setAttribute("version", "0"); 
        
           	audioPorts().saveSettings(doc, elem); 
        
           	params().saveParamConnections(doc, elem); 
        
           	// The CLAP standard strongly recommends using the state extension 
        
           	//     instead of manually saving parameter values 
        
           	if (!state().supported()) { return; } 
        
           	// TODO: Integrate save/load context into LMMS better 
        
           	const auto context = elem.ownerDocument().doctype().name() == "clonedtrack" 
        
           		? ClapState::Context::Duplicate 
        
           		: ClapState::Context::Project; 
        
           	const auto savedState = state().save(context).value_or(""); 
        
           	elem.setAttribute("state", QString::fromUtf8(savedState.data(), savedState.size())); 
        
           } 
        
           void ClapInstance::loadSettings(const QDomElement& elem) 
        
           { 
        
           	[[maybe_unused]] const auto version = elem.attribute("version", "0").toInt(); 
        
           	audioPorts().loadSettings(elem); 
        
           	params().loadParamConnections(elem); 
        
           	// The CLAP standard strongly recommends using the state extension 
        
           	//     instead of manually saving parameter values 
        
           	if (!state().supported()) { return; } 
        
           	// TODO: Integrate save/load context into LMMS better 
        
           	const auto context = elem.ownerDocument().doctype().name() == "clonedtrack" 
        
           		? ClapState::Context::Duplicate 
        
           		: ClapState::Context::Project; 
        
           	const auto savedState = elem.attribute("state", "").toStdString(); 
        
           	if (!state().load(savedState, context)) { return; } 
        
           	// Parameters may have changed in the plugin; 
        
           	// Those values need to be reflected in host 
        
           	params().rescan(CLAP_PARAM_RESCAN_VALUES); // TODO: Is this correct? 
        
           }

The plugin handles most of the work, and I just needed to make sure that automations were saved/loaded:

lmms/src/core/clap/ClapParams.cpp

Lines 280 to 310 in 1b3b091

    
           void ClapParams::saveParamConnections(QDomDocument& doc, QDomElement& elem) 
        
           { 
        
           	auto models = doc.createElement("automated_models"); 
        
           	elem.appendChild(models); 
        
           	for (auto& param : m_params) 
        
           	{ 
        
           		assert(param != nullptr); 
        
           		const auto model = param->model(); 
        
           		if (!model || !model->isAutomatedOrControlled()) { continue; } 
        
           		// TODO: Add method to AutomatableModel which only saves automation / controls? 
        
           		model->saveSettings(doc, models, QString::fromUtf8(param->id().data(), param->id().size())); 
        
           	} 
        
           } 
        
           void ClapParams::loadParamConnections(const QDomElement& elem) 
        
           { 
        
           	auto models = elem.firstChildElement("automated_models"); 
        
           	if (models.isNull()) { return; } 
        
           	for (auto& param : m_params) 
        
           	{ 
        
           		assert(param != nullptr); 
        
           		const auto model = param->model(); 
        
           		if (!model) { continue; } 
        
           		// TODO: Add method to AutomatableModel which only loads automation / controls? 
        
           		model->loadSettings(models, QString::fromUtf8(param->id().data(), param->id().size())); 
        
           	} 
        
           }

Since users have been using LV2 in its current form without state support, you could use an XML "version" attribute to detect whether you're loading an old project file where LMMS stored all the parameters manually or a new project file that uses the plugin's state, then pick the loading routine based on that. Saving could always use the plugin's state if that's possible and the recommended practice. That would effectively be an upgrade routine.

michaelgregorius · 2025-02-02T11:29:56Z

@JohannesLorenz, the issues #5738 and #4027 are good examples of why it would be a great feature to support the saving of state by the plugins themselves.

If the host saves the state of a plugin instance by persisting the individual ports using its own format then it might have to closely follow the development of the plugins, especially if a plugin undergoes huge internal redesigns where port change in a drastic way.

On the other hand, if a plugin supports saving its own state then the upgrade routine will only have to be implemented once by the plugin authors instead of by every host that wants to support it. Projects with an older saved state of a plugin will still work because the plugin knows how to upgrade this state to the current implementation. The host does not need to know anything.

So ideally LMMS should welcome plugins that implement the state feature instead of rejecting them and it should be wary of plugins which do not implement this feature as they might be prone to breaking in the future.

JohannesLorenz · 2025-02-02T13:13:31Z

elem.setAttribute("state", QString::fromUtf8(savedState.data(), savedState.size()));

There seem to be many different ways how to save such a state:

It looks like your CLAP implementation saves the whole state inside an XML attribute. In case of Zyn (which does not support CLAP yet) that would be a whole XML. What if that XML contains quotes?
I would probably rather have put it into a CDATA section, but even here, I am unsure, because if the plugin also has a closing CDATA, then it might result in a parse error, too.
Looking at Ardour, they save each state in a separate TTL file. A single """ line separates the state data. Still, what if your state contains """\n somewhere...

I wonder why LMMS-zyn patched zyn's XML routines to use Qt rather than relying on upstream-zyn's mini-xml approach and embedding the result. Maybe for such reasons?

JohannesLorenz · 2025-02-02T13:21:52Z

If the host saves the state of a plugin instance by persisting the individual ports using its own format then it might have to closely follow the development of the plugins, especially if a plugin undergoes huge internal redesigns where port change in a drastic way.

If the plugin can somehow save its own version into a port (or just infer the version, because the port has weird values), it could still assume an old format and convert the port value to the new format. However, if ports even start to rename or vanish, this gets impossible. So what you say makes sense. I'll probably first submit a PR for state saving, independent of UI.

messmerd · 2025-02-02T18:15:14Z

It looks like your CLAP implementation saves the whole state inside an XML attribute. In case of Zyn (which does not support CLAP yet) that would be a whole XML. What if that XML contains quotes?

It converts the plugin state to to base64 first before storing it to XML, then decodes the base64 when loading.

JohannesLorenz · 2025-02-09T20:00:15Z

This PR by definition solves #6707 (mentioning it to add the reference).

JohannesLorenz · 2025-02-09T20:17:32Z

I think I would like to do the Lv2 state implementation close to the CLAP implementation.

It converts the plugin state to to base64 first before storing it to XML, then decodes the base64 when loading.

Would it make sense to run a compression algorithm prior to the encoding?
What do you think about using CDATA rather than an attribute? I ask since states can get very large (take the Zyn XML, or imagine a daw records audio). ChatGPT says CDATA is the best option, followed by regular element content (<state>CONTENT</state>) and suggests to avoid attributes:
** XML attributes are meant for small, metadata-like values.
** Many parsers impose size limits on attributes.
** Makes the XML harder to read and maintain.

messmerd · 2025-02-09T21:21:57Z

Would it make sense to run a compression algorithm prior to the encoding?

It's up to you I guess. It's probably best to focus on getting it working first before trying to optimize for space. If you have a version attribute, you could add compression in the future without too much difficulty.

What do you think about using CDATA rather than an attribute?

It sounds like it's worth doing. It makes sense that attributes aren't meant for storing a lot of data. If that's the case, I'll probably switch to CDATA or something in the CLAP PR.

@rpath

* CPack: Refactor AppImage and Apple DMG Generation * Switch from linuxdeployqt to linuxdelpoy * Add ARM64 AppImage support * Add support for `.run` installers using `makeself`, an alternative to AppImage * Refactor BashCompletion.cmake * Enable CPack debugging via `WANT_DEBUG_CPACK` * Add `download_binary`, `create_symlink` macros * Qt6: Fix @rpath bug on macOS * Detect and bundle LV2 UI Suil modules (Related LMMS#7201) * Allow remote plugins to honor `LMMS_PLUGIN_DIR` * Add .github/workflows/deps-ubuntu-24.04-gcc.txt * Fix waveforms FileDialog Co-authored-by: Dalton Messmer <[email protected]>

JohannesLorenz force-pushed the lv2-ui branch from d5d0395 to 9129519 Compare May 10, 2024 20:03

zonkmachine reviewed May 10, 2024

View reviewed changes

src/core/lv2/Lv2Proc.cpp Outdated Show resolved Hide resolved

JohannesLorenz force-pushed the lv2-ui branch from cea5907 to 91f8c82 Compare June 2, 2024 20:14

tresf added a commit to tresf/lmms that referenced this pull request Jun 6, 2024

Detect and bundle LV2 UI Suil modules

fce984f

Related LMMS#7201

tresf reviewed Jun 6, 2024

View reviewed changes

src/gui/GuiApplication.cpp Show resolved Hide resolved

tresf mentioned this pull request Jun 7, 2024

Remove calf patches david0/homebrew-audio#31

Merged

zonkmachine marked this pull request as ready for review June 11, 2024 17:19

zonkmachine marked this pull request as draft June 11, 2024 20:24

JohannesLorenz mentioned this pull request Sep 4, 2024

Refactor Effect processing #7484

Merged

JohannesLorenz mentioned this pull request Sep 29, 2024

Maximize button for resizable instruments #7514

Merged

JohannesLorenz added the blocked by other issue label Nov 20, 2024

zonkmachine mentioned this pull request Jan 22, 2025

Wanting to use Guitarix presets, only with a DAW, is needlessly complicated. brummer10/guitarix#203

Closed

tresf mentioned this pull request Jan 24, 2025

Carla can't load as an effect #7660

Open

1 task

JohannesLorenz force-pushed the lv2-ui branch from 07682f1 to adc1422 Compare January 24, 2025 21:55

Implement Lv2 UI

19a8109

http://lv2plug.in/ns/extensions/ui Size issues also fixed (but SlicerT is not happy as we removed `InstrumentTrackWindow::resizeEvent`... Co-authored-by: Tres Finocchiaro <[email protected]>

JohannesLorenz force-pushed the lv2-ui branch from adc1422 to 19a8109 Compare February 1, 2025 21:29

tresf mentioned this pull request Feb 3, 2025

Incorporate Zyn-Fusion #4179

Open

JohannesLorenz mentioned this pull request Feb 9, 2025

Implement Lv2 UI #6707

Open

JohannesLorenz mentioned this pull request Feb 16, 2025

Implement SPA support (enabling zyn-fusion) JohannesLorenz/lmms#11

Draft

Lv2 UI - Testing #7201

Are you sure you want to change the base?

Lv2 UI - Testing #7201

Conversation

JohannesLorenz commented Apr 8, 2024 • edited Loading

JohannesLorenz commented May 12, 2024

zonkmachine commented May 19, 2024

zonkmachine commented May 20, 2024

messmerd commented May 20, 2024

michaelgregorius commented Jun 2, 2024

tresf commented Jun 5, 2024 • edited Loading

tresf commented Jun 5, 2024

zonkmachine commented Jun 15, 2024

JohannesLorenz commented Jun 15, 2024

zonkmachine commented Jun 15, 2024

JohannesLorenz commented Jun 15, 2024

zonkmachine commented Jun 15, 2024

JohannesLorenz commented Jun 16, 2024

zonkmachine commented Jun 16, 2024

JohannesLorenz commented Jun 16, 2024 • edited Loading

zonkmachine commented Jun 16, 2024

JohannesLorenz commented Jun 16, 2024

zonkmachine commented Jun 16, 2024

zonkmachine commented Jun 16, 2024

JohannesLorenz commented Jun 16, 2024

zonkmachine commented Jun 16, 2024

JohannesLorenz commented Jun 16, 2024

Gabrielxd195 commented Aug 10, 2024

JohannesLorenz commented Aug 10, 2024

JohannesLorenz commented Aug 11, 2024

zynskeywolf commented Aug 12, 2024

michaelgregorius commented Aug 12, 2024

JohannesLorenz commented Aug 12, 2024

tresf commented Feb 1, 2025

JohannesLorenz commented Feb 1, 2025

JohannesLorenz commented Feb 2, 2025

messmerd commented Feb 2, 2025 • edited Loading

michaelgregorius commented Feb 2, 2025

JohannesLorenz commented Feb 2, 2025

JohannesLorenz commented Feb 2, 2025

messmerd commented Feb 2, 2025

JohannesLorenz commented Feb 9, 2025 • edited Loading

JohannesLorenz commented Feb 9, 2025

messmerd commented Feb 9, 2025

JohannesLorenz commented Apr 8, 2024 •

edited

Loading

tresf commented Jun 5, 2024 •

edited

Loading

JohannesLorenz commented Jun 16, 2024 •

edited

Loading

messmerd commented Feb 2, 2025 •

edited

Loading

JohannesLorenz commented Feb 9, 2025 •

edited

Loading