User-defined default settings / settings templates for features and channels using preset concept

[srcejon]

As previously discussed: https://github.com/f4exb/sdrangel/issues/1139#issuecomment-1049661748, I think it would be useful if users could set the initial settings for any particular plugin, so that whenever that feature or channel is added, the user's settings are automatically applied.

This would be particularly useful for features such as the Map, that have settings such as API keys, that you don't want to have to re-enter each time you open the map. But it can be useful in channels too - E.g. you might always want the Broadcast FM demod to start in stereo with RDS enabled.

While this is somewhat supported via presets, loading a preset changes all of the channels / features, which isn't always what is wanted. E.g. if you add the Map into an existing setup, you can't load a preset with the Map, as that might close other features.

Could perhaps be implemented by adding save & reset buttons in the Common Settings dialog.

[f4exb]

I think it would be useful if users could set the initial settings for any particular plugin, so that whenever that feature or channel is added, the user's settings are automatically applied.

Well... maybe it is not the easiest nor the safest way to implement this. I'd rather have it as presets but unlike the current presets they would be of a kind that applies only to the channel or feature type. At the expense of having to do things in two steps (1: add the channel/feature with default settings, 2: select and load the preset) it has the following advantages:

• we do not change the way a channel or feature is added. This is a sensitive part of the code and it is safer not to fiddle with it too much
• you can have more than one preset for the channel or feature type. For example with SSB demod you can have several filter settings for wider or narrower SSB, choice between LSB/USB or CW
• You are not tied to the same settings to create every channel or feature
• similarly to what exists today for presets you would also be able to add, change, export and import such presets
• presets are a known and old story it would be not much different in functionality than the present presets only the scope changes. Maybe some parts of the code can be reused or at least be a source of inspiration.

Note that if you want to add many channels of the same type you can create the first and then duplicate it. I don't think this exists for features. It is probably less useful but could be implemented the same way.

Note also that it means changing a bit the way current feature presets are implemented as they load a collection of features. There would be a bit of reorganization to support both single and multiple feature presets.

[srcejon]

Having multiple per individual channel / feature presets sounds good.

But I would really like it, if one could load automatically :)

How about after creating a channel/feature, it automatically tries to load a preset named "Default" for the type of channel/feature created - with no error if it doesn't exist. So if you want default settings, you just save your preset with the name "Default". And if you want to get rid of the default settings, you just delete that preset?

[f4exb]

I am still a bit concerned about how we create the channel/feature but may be this is over-concern. The load of the "Default" preset may just follow the creation with the (true) defaults. So if "Default" does not exist it just does nothing and you will have the (true) default.

[srcejon]

The load of the "Default" preset may just follow the creation with the (true) defaults. So if "Default" does not exist it just does nothing and you will have the (true) default.

Yep - that's what I was thinking.

[srcejon]

It would also be good if this worked for the spectrum settings too - so that every time I open a device, I get preferred grid / colour / FFT settings, etc.

[f4exb]

There is a difference in nature between the spectrum component and channels or features. The spectrum component is part of channel and features and device set also so its settings are already part of the channel, feature or device set settings and therefore are already part of device set presets or configurations (also channel and feature presets when this issue is implemented).

The spectrum settings are particular to the use case the spectrum takes part of thus it makes less sense to have it as an independent preset compared to channels and features. However we could have spectrum presets but there could not be something like a "Default" preset.

Edit: there could be a "Default" spectrum preset but it would be superseded most of the time by other presets as mentioned above. The only possible use case is for the main spectrum when starting from scratch (with the --scratch option) so I am not sure it is even worth having special code for it.

[srcejon]

To clarify, I was mainly thinking of the Main Spectrum. E.g., the use case is:

• Press Add Rx/Tx device
• Have appearance and annotation marker settings automatically applied to the Main Spectrum for the added device

I guess this could be achieved if a default device set preset were attempted to be loaded in the same way as discussed for channels and features, after a device is added.

This means you need to setup the spectrum settings for each device, but as that only needs to be done once, that's no big deal. The important bit from my perspective, is that the settings are be applied automatically.

[f4exb]

The important bit from my perspective, is that the settings are be applied automatically.

Not sure this is tremendously useful. In a lot of cases you will want once to start say your RTL-SDR device as a Broadcast FM receiver and the next time as a NBFM receiver for say PMR 446. So this is more an annoyance than a facility. However since it would be conditioned to the preset having "Default" as its name you would not be obliged to bear with the annoyance.

Also the way device set presets are designed are with the complete receiver or transmitter in mind. That is it will store settings of channels and main spectrum and also a collection of settings for each device. Thus it will not be possible to have say Broadcast FM default setting for RTL-SDR and PMR446 for HackRF but only one default receiver or transmitter. I do not intend to change the Device Set presets for the purpose of having entirely different setups for each device. This would break the idea of having these presets define a type of receiver or transmitter regardless of the device being used (which I think is useful).

You already have a lot of options just a few clicks away (just load the device set preset of your choice) and also you have the default configuration that will load the same complete configuration of receivers, transmitters, windows setup again and again across program restarts.

[srcejon]

In a lot of cases you will want once to start say your RTL-SDR device as a Broadcast FM receiver and the next time as a NBFM receiver for say PMR 446. So this is more an annoyance than a facility. However since it would be conditioned to the preset having "Default" as its name you would not be obliged to bear with the annoyance.

Yes, but I don't think this is a problem, as you can save a preset without any channels open. So all the preset would do is set the initial device and spectrum settings.

Thus it will not be possible to have say Broadcast FM default setting for RTL-SDR and PMR446 for HackRF but only one default receiver or transmitter.

This wasn't something I was trying to do. However, if you wanted to support that as well, instead of always loading a preset named Default, it could load a preset with the device name in it. E.g. 'LimeSDR Default', or 'RTLSDR Default'.

You already have a lot of options just a few clicks away (just load the device set preset of your choice)

Yes, but if it's something that you do every single time, and you it quite frequently, to me it makes sense to automate it. It's of course not the most important thing - just makes it that little bit nicer :)

Superficially, adding the following at the end of MainWindow::sampleSourceAdd seems to work:

DeviceUISet *deviceUISet = m_deviceUIs[deviceSetIndex];
QString presetDescription = QString("%1 Default").arg(deviceUISet->m_deviceAPI->getHardwareId());
QList<Preset *> *presets = m_mainCore->m_settings.getPresets();
for (auto preset : *presets)
{
    if (preset->getDescription() == presetDescription) // Maybe && preset->getGroup() == "Default" 
    {
        deviceUISet->loadDeviceSetSettings(preset, m_pluginManager->getPluginAPI(), &m_workspaces, nullptr);
        break;
    }
}

[f4exb]

Yes, but if it's something that you do every single time, and you it quite frequently, to me it makes sense to automate it. It's of course not the most important thing - just makes it that little bit nicer :)

Sure... in the order of importance the Features would come first I think and more importantly for complex features like the Map but that's a global features thing, then the Channels, and lastly this Device thing. I would also include the spectrum settings before. I think it can be interesting to be able to load a preset for say having markers at RTTY frequencies for the spectrum of the SSB demod so you can fine tune it. And probably other use cases I am not thinking of at the moment.

Yes, but I don't think this is a problem, as you can save a preset without any channels open...

Sure you can it just seems a bit counter intuitive to me to always start at the same frequency with the same settings. There is a default frequency and default settings anyway so it will also always start with something by default but in my view the first thing you would like to do next is either set everything manually and then save it to a preset to be able to recreate the same conditions later or load such a preset that you saved before. Anyway both use cases are compatible with a "Default" preset.

This wasn't something I was trying to do. However, if you wanted to support that as well...

Well not really. It is enough for me to just have one default else it turns out into something more bulky like a "Default" group then an optional "Default" name that is always taken if it exists (so the primary functionality is respected) or if not check if the device type matches one with the same name and then take it else just take the device defaults.

Superficially, adding the following at the end of MainWindow::sampleSourceAdd seems to work:

It is not the complexity of the code I am challenging just the functionality. But again if you so desire it does not seem to hurt.

[srcejon]

Sure... in the order of importance the Features would come first I think and more importantly for complex features like the Map but that's a global features thing, then the Channels, and lastly this Device thing. I would also include the spectrum settings before.

Ok - I was only really suggesting having Device default presets as a way to be able to set the default Main Spectrum settings. If you add a specific way to do that, then there's less of a desire for the former.

[f4exb]

There might still be an interest for a Default device set preset this is when you want your own defaults instead of the default defaults like starting at 435 MHz (for devices covering this range).

[f4exb]

Deployed in v7.15.4