Repository navigation
Replies: 1 comment
|
I see PRs aren't desired. So I've made an issue about this, and thus closing. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I recently made a change in my own local copy (not yet even forked/pushed to my own account yet) to provide PPM support for SDRPlay devices. I noticed there is a discussion from 2021 that said sdrplay didn't support PPM, maybe it was true then, but it does now and all the required backend was already present. I just needed to add the UI component and send the correct API calls from structures already present.
Now, currently it allows you to set it, it saves the config. Applies it to the device on startup and when adjusted live. Which is good enough for my needs, so if this is not desired I can stop right here and just use it myself.
But, it doesn't currently support server mode (it uses Double, which is not implemented in SmGui so goes direct to InputDouble from ImGui). Also it would need a bit of cleanup to make it tidy/look nice, since it's my first toe in the sdr++ code base, I've probably committed a thousand faux pas'.
My question is, would the correct way to go about this be to make one PR with the change to SmGui and Sdrplay source, or (and I feel like this would be better), one PR to make SmGui support InputDouble in server mode and local mode, then once that is accepted make the SdrPlay source PR to complete things?
For reference it looks like this:
All reactions