Linking UI elements in the GUI to retrieve values from other UI elements
Hi there,
sometimes I have a use case where a "Input field", like e.g. the "Center frequency" of the "AM/FM Demodulator" should not be statically filled by the user, but use a value existing somewhere in the deep space of the RTSA config.
In my case, I wanted the "AM/FM Decoder" to decode what i hover in a specific waterfall view.
Therefore i added a marker and hoped, i can select that marker's value as value-source for the "Center frequency"
You for sure know this from blender where you can rightclick an input field and select "Add driver" to set the source for the value to use.
It would be great to right click fields of type "Frequency", "Percentage", "Number", ... and select their value-source.
Value sources could be input boxes of the same type, or attributes of stuff like Markers or even JS-snippets.
For special-cases it would be great to evaluate JS-code, which gets executed when the linked UI field changes.
So when linking the "Center Frequency" to the "Decode Frequency" Marker, I can choose between the variants
"Link to attribute: Frequency" and "Link by evaluating JS code".
Then I have to supply a JS snippet that evaluates to the type of the target element (in this case "Center frequency") by
evaluating the linked source whenever it was updated (in this case the Marker).
Implementation-wise the linked value-source would have to know all links and when it updates it's value,
it would remotely update the config items that use it value. If JS would be supported and the link type is JS,
it would first evaluate the snippet and use the result to update the config item.
Do you think this is doable without too much effort?
Regards,
g3gg0
Another use case is:
monitoring a frequency range, subtracting a reference profile, having an automatic marker that shows the highest peak.
So with just a single link, it might be possible to auto-demodulate the signal with the highest signal strength 🙂
Keep in mind that the RTSA is usually processing millions of datapoints every second, and having such a generic link system could easily lead to unintended side effects. Also there are already quite a few implicitly linked values between specific blocks that could easily lead to further issues.
You can already use the Script block for such specific things (listen for configuration change messages and react to them however you want). Though markers aren't part of the configuration system and won't trigger change notifications on purpose as they can change on every sample. So for that you'll have to obtain the actual marker values at regular intervals and change the desired config value accordingly like in attached mission.
Uploaded files:
thanks for your reply and example.
yeah, using scripts to automate things is also possible. however, having it in the GUI would definitely feel more solid than extra scripts.
Of course. But the script option is already available right now, and by definition much more flexible.
