-
Notifications
You must be signed in to change notification settings - Fork 420
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preset enhancements - configuration save/restore framework #1050
Comments
Yes, the request isn't for displaying two different types of preset in the same table, but having a single preset/configuration that sets device settings, channels and features all in one. So, for example, we could have: This could be implemented by having a configuration that references an existing channel preset and feature preset, or similar, so you still have all existing functionality. |
OK I see so in fact it all boils down to what I called the "second part". In fact the presets are not the point what you would like to do is to be able to save and retrieve a complete configuration with all its devicesets and featuresets. You do not necessarily have to use a specific interface to combine presets you just build the instance with or without presets and once you are satisfied with it you "save" it in order to be able to retrieve it later. You would also like to be able to save many configurations and have them listed somewhere more or less in the same format as the presets display. For what concerns "loading" complete configurations with many devicesets and features this already exists using the REST API via a Python script: https://github.com/f4exb/sdrangel/tree/master/scriptsapi#configpy But you have to build the JSON configuration by hand. I already had in my mind to extend the Note that it is possible to invoke the config,py script from the GUI using the "Commands". For example: JSON file content[
{
"endpoint": "/deviceset",
"method": "POST",
"msg": "add Rx 1 device set"
},
{
"endpoint": "/deviceset/1/device",
"method": "PUT",
"payload": {
"hwType": "LocalInput"
},
"msg": "setup Local Input on Rx 1"
},
{
"endpoint": "/preset",
"method": "PATCH",
"payload": {
"deviceSetIndex": 1,
"preset": {
"groupName": "QO100",
"centerFrequency": 489605000,
"type": "R",
"name": "Narrowband slave low"
}
},
"msg": "load preset on Rx 1"
},
{
"endpoint": "/deviceset",
"method": "POST",
"msg": "add Rx 2 device set"
},
{
"endpoint": "/deviceset/2/device",
"method": "PUT",
"payload": {
"hwType": "LocalInput"
},
"msg": "setup Local Input on Rx 2"
},
{
"endpoint": "/preset",
"method": "PATCH",
"payload": {
"deviceSetIndex": 2,
"preset": {
"groupName": "QO100",
"centerFrequency": 489885000,
"type": "R",
"name": "Narrowband slave high"
}
},
"msg": "load preset on Rx 2"
},
{
"endpoint": "/deviceset/0/device",
"method": "PUT",
"payload": {
"hwType": "RTLSDR"
},
"msg": "setup RTLSDR on Rx 0"
},
{
"endpoint": "/preset",
"method": "PATCH",
"payload": {
"deviceSetIndex": 0,
"preset": {
"groupName": "QO100",
"centerFrequency": 489745000,
"type": "R",
"name": "Narrowband master 25M"
}
},
"msg": "load preset on Rx 0"
},
{
"endpoint": "/deviceset/1/device/run",
"method": "POST",
"msg": "Start device on deviceset R1"
},
{
"endpoint": "/deviceset/2/device/run",
"method": "POST",
"msg": "Start device on deviceset R2"
},
{
"endpoint": "/deviceset/0/device/run",
"method": "POST",
"msg": "Start device on deviceset R0"
},
{
"endpoint": "/deviceset/0/channel/0/settings",
"method": "PATCH",
"payload": {
"channelType": "LocalSink",
"direction": 0,
"LocalSinkSettings": {
"play": 1
}
},
"msg": "Start local sink 0 on deviceset R0"
},
{
"endpoint": "/deviceset/0/channel/1/settings",
"method": "PATCH",
"payload": {
"channelType": "LocalSink",
"direction": 0,
"LocalSinkSettings": {
"play": 1
}
},
"msg": "Start local sink 1 on deviceset R0"
}
] This is a bit convoluted but this is feasible. So I think I will not reinvent the wheel here more re-implementing the Lastly having a config fired up at startup time should only be an option and be done after the initial setup. It would be very costly to change the default as it is today and also 90% if not more of the users run the program with a single receiver. Note that this was originally done just so that the GUI displays something and more conveniently the last receiver that was used. The server flavor starts empty. |
Yep, sounds good. Being able to create a config in the GUI and then load it in the server would make it much easier to set up the server. |
…SON format for the API. Prerequisite tp #1050
With the projected revamping of the UI the very nature of presets is going to change so I'd better postpone this to the new UI implementation or make it part of the project. |
While the older presets (device sets and features) will be kept for compatibility a new class of "preset" called "configuration" will be able to save/restore the complete instance and its UI configuration i.e. workspaces, device sets, features ttheir UI widgets with their respective arrangements (workspace and geometry). Similarly to what was in place for presets a "working configuration" is kept to save the current arrangements across program start/stop cycles. |
done in v7.0.0-alpha.1 |
Currently Device/Channel presets are separate from Feature presets. While this is nice in some use cases, in others, it would be nice if the two could be grouped as one. Perhaps there could be an option in the Device/Channel preset that determined whether it should save/restore Features as well?
Also, it would be useful if there were "application" presets, that included settings for multiple DeviceSets and also determined which Devices were used in each. E.g. for those with multiple SDRs, it would be nice if SDRangel started up with all DeviceSets setup to how there were on exit (As is currently the case for DeviceSet 0).
The text was updated successfully, but these errors were encountered: