If you want a new feature or a change to the software then add your request here.I've put a small SDR console remote control project on hold due to some bugs in the TS-2000's RS232 remote control protocol (as well as some other limitations that prevent interaction with certain features).
I had considered trying to combine the TS-2000's remote control protocol with the MIDI interface, but I still see several shortcomings and think it would only complicate things further.
I understand that Simón has his own priorities (in addition to the recent development of SDR Television), and as a programmer, I'm aware that a simple idea or suggestion from outside can often lead to significant internal changes. However, I think it would be interesting to have a small API that publishes a series of methods allowing users to obtain and set values for certain console operating characteristics (mode, frequency, filters... in short, a subset of everything done via the TS-2000 and MIDI protocols).
My API suggestion isn't a complex service for remote connections that would require developing extra protocols. I believe a simple Windows DLL that interacts with the SDR console instance and makes a series of methods publicly available could allow for the development of small third-party tools/plugins that would extend the program's functionality.
For anyone with basic programming knowledge, it would be as simple as linking to the DLL and creating the entire new implementation, calling these methods as needed.
Suggestion: Simple local public API that allows interaction/development of utilities/plugins
Re: Suggestion: Simple local public API that allows interaction/development of utilities/plugins
It's worth another try. {^_-} I want it, too.
As far as a remote control program for SDRC, it would be an pathetic anemic experience to use. You have to account for N receivers up and running. You have individual control sets for each one plus for the front end settings. The TS2000 set probably won't work unless it is extended. Are you planning on dealing with the recording interface? The favorites and the memories? How about several different tools for dealing with noise? (Speaking of which I really wish he'd adopt noise squelch. Sigh!) One thing you will have to deal with are the various tools options that can give remote control inconsistent results.
It might pay to structure up a meaningful command set for SDRConsole, ideally after you have spent many loving hours learning its capabilities and quirks. (Like, Visual Gain is not strictly visual. It affects levels throughout the system because it multiplies the samples by the Visual Gain.) I am in favor of some form of remote control access to the console. Alas, that does not seem to be within the realm of what Simon is trying to achieve.
{^_^}
As far as a remote control program for SDRC, it would be an pathetic anemic experience to use. You have to account for N receivers up and running. You have individual control sets for each one plus for the front end settings. The TS2000 set probably won't work unless it is extended. Are you planning on dealing with the recording interface? The favorites and the memories? How about several different tools for dealing with noise? (Speaking of which I really wish he'd adopt noise squelch. Sigh!) One thing you will have to deal with are the various tools options that can give remote control inconsistent results.
It might pay to structure up a meaningful command set for SDRConsole, ideally after you have spent many loving hours learning its capabilities and quirks. (Like, Visual Gain is not strictly visual. It affects levels throughout the system because it multiplies the samples by the Visual Gain.) I am in favor of some form of remote control access to the console. Alas, that does not seem to be within the realm of what Simon is trying to achieve.
{^_^}
Re: Suggestion: Simple local public API that allows interaction/development of utilities/plugins
My initial idea for remote control is based on the simple concept of managing the active receiver (although currently, receiver selection can be done via MIDI) with basic controls, just like with CAT/MIDI control, but perhaps adding a few features missing from current controls.
What I mean is that there's currently a subset of options for performing certain "remote" operations (CAT/MIDI/SRCP/TMATE/External Radio), and if a DLL were available that published the methods used by all these current remote control features, it would open up the possibility of creating all sorts of third-party utilities (console tools, new communication protocols, or small control services).
The ideal setup for my small hardware project would be to have the SDR console in the background, or on a secondary monitor with the waterfall display visible, and be able to interact with the most common controls (frequency change, mode, filters, etc.). For more advanced tasks, the SDR console would typically be used via keyboard and mouse.
Furthermore, I believe that directly using calls to this supposed Windows DLL would be more efficient than using an intermediate polling method on the serial/MIDI port.
As I said, what we have now is "functional" but "divided." There are things that can be done via MIDI but not via CAT, and vice versa.
On the other hand, I think the DLL suggestion would be the simplest implementation for Simon. It doesn't make sense for him to develop/maintain a new plugin system or a new console tool to make all this possible. I don't know how the software works internally, but I assume that all these SDR console features that the current remote control methods interact with are encapsulated in calls (setFrequency, setMode, setAudioGain...), so it would be a matter of exposing them publicly.
What I mean is that there's currently a subset of options for performing certain "remote" operations (CAT/MIDI/SRCP/TMATE/External Radio), and if a DLL were available that published the methods used by all these current remote control features, it would open up the possibility of creating all sorts of third-party utilities (console tools, new communication protocols, or small control services).
The ideal setup for my small hardware project would be to have the SDR console in the background, or on a secondary monitor with the waterfall display visible, and be able to interact with the most common controls (frequency change, mode, filters, etc.). For more advanced tasks, the SDR console would typically be used via keyboard and mouse.
Furthermore, I believe that directly using calls to this supposed Windows DLL would be more efficient than using an intermediate polling method on the serial/MIDI port.
As I said, what we have now is "functional" but "divided." There are things that can be done via MIDI but not via CAT, and vice versa.
On the other hand, I think the DLL suggestion would be the simplest implementation for Simon. It doesn't make sense for him to develop/maintain a new plugin system or a new console tool to make all this possible. I don't know how the software works internally, but I assume that all these SDR console features that the current remote control methods interact with are encapsulated in calls (setFrequency, setMode, setAudioGain...), so it would be a matter of exposing them publicly.