Change settings without restarting LMMS

[badosu]

I am posting this issue as a place to discuss whether it's possible or not to change settings without having to restart LMMS.

I believe some cases will be very difficult or impossible to implement, but maybe we can track these cases and only require restarting for those?

[taupter]

Being able to change configurations without restarting LMMS is a nice feature to have. Tracking the cases where it is currently implementable will take some time.
I see some:
Audio backend/device;
Plugin paths;

Audio backend/device may imply stopping/starting the audeio engine, what may be problematic to do without restarting.
Plugin paths involve plugin discovery. If you load a song with missing plugins, after you alter the plugin paths the engine should rescan the available plugins and bind them to the tracks accordingly. Scanning plugins may involve scanning only new plugins, scanning prevoiusly failed plugins, rescanning already scanned plugins. Writing a new directory list dialog involves remodelling the current ui responsible for it, and maybe including the plugin list into this new dialog. May I do a mockup?

[badosu]

@taupter

Before attempting something as ambicious as creating a new dialog only for plugin paths, I'd recommend making the current configuration manager reload configurations without having to restart LMMS.

This will solve a problem that is shared for both old and new ways and cement the path for your feature request.

If you want to submit your feature request with mockups/discussion I recommend to file another issue.

The relevant fields you'll have to reload for plugin Paths will be these: https://github.com/LMMS/lmms/blob/master/include/SetupDialog.h#L156-L162

[taupter]

Ok. I'll take a look at it. It involves rescanning directories and maybe sending signals to reload things. Some options to reload plugins may be necessary, that's why I talked about hte ui. Of course it can be done hardcoded for debugging purposes, but exposing such features sooner or later would be fine.

[badosu]

@taupter Regarding the plugin path reloading process, I am not sure if we really need to rebind all plugins that are already loaded.

In my understanding this should affect only the discovery of plugins on the dialogs. What happens on other DAWs?

[Wallacoloo]

We can absolutely track which cases need restarting explicitly. The code that updates the settings & shows the warning dialog is here.

We could add a simple line:

bool needsRestart = (ConfigManager::inst()->value( "mixer", "framesperaudiobuffer" ).toInt() != m_bufferSize) ||
 (ConfigManager::inst()->value( "mixer", "audiodev" ) != m_audioIfaceNames[m_audioInterfaces->currentText()]) || [other settings that require reset]
...
if( needsRestart && m_warnAfterSetup )
{
    // show warning dialog
}

While we're at it though, the settings dialog could really use some refactoring in the form of abstraction. There are a number of places there where it's basically the same code duplicated for a bunch of a different settings. And adding a new setting requires inserting such code into like 4 or 5 different places. This could probably be fixed by adding a SetupOption class that stores the option name, data type, description, whether or not it requires a reset when changed, etc, and then just creating an array of these upon instantiation of the settings dialog and building the dialog's UI and doing the updates dynamically with a for loop. This could easily shave a good 300-400 lines of code off the file as well as making it easier to edit and read.

[tresf]

I believe some cases will be very difficult or impossible to implement, but maybe we can track these cases and only require restarting for those?

I like this idea and the topic. We can start by binding the fields to a boolean of whether or not a restart is actually required, as the dialog itself is ambiguous as to whether or not a restart is needed.

Another item that may be useful is to offer a "restart now" button which could (on most platforms at least) save and restart the application.

Then, we can start knocking off the biggest pain-points one by one.

In my understanding this should affect only the discovery of plugins on the dialogs. What happens on other DAWs?

They generally allow this, but for remote plugins (ones that otherwise could be added manually, such as VST effects, etc) there's really no need not to IMO. It's more of a directory listing refresh than anything else.

Also, what @Wallacoloo said. 👍

[taupter]

FL Studio and Sonar offer such funtionality. FL particularly offers to scan only new, scan previously failed and rescan those already ok.
If you change paths, some previously available plugins may not be anymore. If some plugins were overwritten (new versions) if may make sense to verify if previously failed plugins are able to load now. Being able so select what and how we scan is a nice feature, because we could avoid long waits if we have a huge number of plugins and just added a new one, or fixed a dependency that allowed a previously broken plugin to load correctly. If the plugin database was corrupted we could rescan everything. Making those options available to the end user is a nice thing to do. Obviously during development it could not be necessary to show such options, but at least a simpler UI to configure multiple directories wouldn't be so complicated to do.
@Wallacoloo I believe the goal would to make LMMS not need to restart itself by any reason. It should be resilient enough to not need it. As a step the reset flag is interesting, but as a goal it may not be the case. Commited changes should throw a signal to inform the main engine to do the proper parameter reloading.
@tresf Dunno about you, but LMMS should be a DAW able to compete head to head to other DAWs out there (IMHO). To do so it must have a lot of things implemented. Handling a huge number of plugins should be a breeze. Nowadays it's difficult to adjust the path list! Sanitizing the configuration, ui and internal handling, will improve LMMS, make it more maintainable, simplify code and present a better experience to the user.

[badosu]

@taupter Well, one thing that's clear for everyone is that this area needs some love.

I think any work you could put here would be very welcome. If you want to take a look at this we can discuss the details on the Pull Request itself.

[tresf]

@tresf Dunno about you, but LMMS should be a DAW able to compete head to head to other DAWs out there (IMHO).

It already does in many areas. It's the cheapest and it runs on the most platforms, so it is a competitor in many markets.

To do so it must have a lot of things implemented. Handling a huge number of plugins should be a breeze.

I'm not even sure what this statement means, especially the part "should be a breeze". Handling blind execution of someone else's code (albeit often proprietary) is one of the toughest tasks you can ask of a programmer. In regards to "huge numbers", we do. We support LADSPA out of the box, VST(i) and VST-FX out of the box and have many, many built-in instrument plugins too.

Nowadays it's difficult to adjust the path list! Sanitizing the configuration, ui and internal handling, will improve LMMS

Difficult? No. Annoying? Perhaps.

... make it more maintainable, simplify code and present a better experience to the user.

I think that's everyone's goal here. 👍

[softrabbit]

This could probably be fixed by adding a SetupOption class that stores the option name, data type, description, whether or not it requires a reset when changed, etc, and then just creating an array of these upon instantiation of the settings dialog and building the dialog's UI and doing the updates dynamically with a for loop.

I tried to put together a proposal of this kind, but ended up scrapping it as too incoherent or something... but here are a few points I think I had in it:

• More than one value could be stored in the SetupOption: loaded, modified, command line override. Command line overrides would be temporary and not saved to the config file unless explicitly asked for, and modified values could be reverted before saving.
• Maybe have a tree of those options, rather than an array
• IIRC, there's some logic in the GUI end that really should be moved to the core. But that will hopefully stick out like a sore thumb when the refactoring gets started, I've forgotten the details on what exactly it was 😵

[taupter]

Em terça-feira, 16 de junho de 2015, Tres Finocchiaro <
notifications@github.com> escreveu:

@tresf https://github.com/tresf Dunno about you, but LMMS should be a
DAW able to compete head to head to other DAWs out there (IMHO).

It already does in many areas. It's the cheapest and it runs on the most
platforms, so it is a competitor in many markets.

@tresf https://github.com/tresf Yes, it does compete. Even Voyetra still
competes. Yes, LMMS is pretty competent and featureful, with a lot of extra
goodies and and excellent bang for the buck. It has the potential to
compete in even more markets. But there are a lot of possibilities of
improvement. There are some things that we take for granted in other DAWs
that are not implemented on LMMS (undo/redo) or implemented in a way not
quite expected (some aspects configuration handling), and these
idiosyncrasies may make some people choose another DAW, even if they have
to pay for. It makes me remember 1999, when I was designated by my employer
to make a viability study on StarOffice, to see if it could substitute MS
Office 97 on more than 250 bank branches across the country. Despite being
a quite competent program and people being able to write beautiful,
insightful texts with StarOffice, for the purposes of the bank it wouldn't
suffice. Had I received such task today about LibreOffice, it would be
approved with flying colors. Improving LMMS to a point that it may be taken
as a viable choice by as many people as possible seems to be a sensible
goal.

To do so it must have a lot of things implemented. Handling a huge
number of plugins should be a breeze.

I'm not even sure what this statement means, especially the part "should
be a breeze". Handling blind execution of someone else's code (albeit often
proprietary) is one of the toughest tasks you can ask of a programmer. In
regards to "huge numbers", we do. We support LADSPA out of the box, VST(i)
and VST-FX out of the box and have many, many built-in instrument plugins
too.

Yes, of course LMMS handles plugins just fine internally. Yes, it is robust
in this aspect. When I mentioned handling I expressed myself in a not clear
enough way, what I had in mind was "enabling the user to manage his/her
plugin collection just as easy as the most talked about commercial
counterparts (Logic Pro, FL Studio, CuBase, Nuendo, Pro Tools, Studio One,
Sonar, Bitwig, Ableton Live, Sequoia, Digital Performer). As LMMS seems to
loosely resemble FL Studio, taking a good
https://www.image-line.com/support/FLHelp/html/envsettings_files.htm look
https://www.image-line.com/support/FLHelp/html/img_shot/vst_deepscan.png
at it may be worth it.FL Studio seems to mix in the same bag FL, VST and
VST3 plugins. Directory entries may be enabled/disabled, just as individual
plugins. This may not be the best way to do in LMMS, but let's keep our
eyes open.

Back to the problems in management, any efforts at it may be hampered by
the fact that LMMS has trouble handling its configuration file. I tested it
with 1.1.3 (Windows version from Download page) and git master (on Linux,
all extras enabled on Cmake), and if I select an unavailable audio
backend/device it doesn't alert me about it (as I'm unable to test the new
configuration before restarting LMMS). If I change anything else in the
configuration (let's say, the plugin path), after I reboot the changes I
made to the plugin path are ignored and the defaults are loaded. This is
not an expected or documented behavior.

Nowadays it's difficult to adjust the path list! Sanitizing the
configuration, ui and internal handling, will improve LMMS

Difficult? No. Annoying? Perhaps.

I would consider it annoying if it did what it was supposed to without
corner cases and the only clumsy point was the UI, but is difficult because
it doesn't behave the way one should expect it to (losing its changed
parameters if an unrelated option was changed too and failed). I'm not
saying it is complex, just difficult.

... make it more maintainable, simplify code and present a better
experience to the user.

I think that's everyone's goal here. [image: 👍]

Of course.

—
Reply to this email directly or view it on GitHub
#2109 (comment).

[taupter]

@softrabbit May I take a look at it?

AFAICS we need a flag for each subsystem that could need a reboot. I'd name it "reload" or something like that, as I believe reloading a module/subsystem instead of restarting the full program would be the saner thing to do. When saving/applying configurations such flags should be checked and acted upon: the modules/subsystems that reloading is not implemented should alert the need of rebooting, the ones that reloading was implemented should happily do so without a fuss.

If it was possible for every subsystem have his own configuration loading/saving code we could use a Qt SIGNAL to make each subsystem take care of itself (similar to the way Kopete does with its modules), with a clear adherence to the MVC approach.

[tresf]

We could talk endlessly about how LMMS needs to improve, but the proof is in the pudding, so to speak.

enabling the user to manage his/her plugin collection just as easy as the most talked about commercial counterparts

Our software can drag SF2s and VSTs (and others) directly from the file browser into a new track. That's pretty easy. Management of them in a single dialog may be clumsy, sure, but that is mostly a UI improvement.

is difficult because it doesn't behave the way one should expect it to [...] I'm not
saying it is complex, just difficult

I still feel this description represents clumsiness, not difficulty.

losing its changed parameters if an unrelated option was changed too and failed

That is neither difficult nor clumsy, that is a bug and should be filed.

And these idiosyncrasies may make some people choose another DAW, even if they have
to pay for

Who cares? We aren't trying to put Image-Line out of business. We have to stop using "people might buy something they want" as an incentive to make our software better. We aren't trying to save people money nor are we trying to replace the need for a commercial DAW. Our home page once said "Free alternative to FruityLoops", but that has since been taken down. It's misleading and it's not even correct. Enabling people to make music that otherwise couldn't should be our mission statement, not saving people money.

Also apologies to @badosu as this thread has gone way off-topic.

[tresf]

[...] May I take a look at it?

Yes, please do although this can grow into a fairly large project. I'd recommend opening a Pull Request as soon as you have a basic proof of concept started so that the team can have plenty of time to review and approve your approach.

[badosu]

@tresf

Also apologies to @badosu as this thread has gone way off-topic.

This thread appearead as a spin-off of a discussion with @taupter on what he wanted to collaborate to LMMS.