On the other hand, every functional section of SDRUno is created in its own separate Windows dialog. That means you have to open them separately then arrange them on the screen to your liking. So, that's both a blessing and curse. However, once you get the screen arranged the way you like, you can save the configuration and invoke it with a single click. Since the various function dialogs have various sizes, you can never get all the windows to line up exactly - but that's a small price to pay for the flexibility that is provided.
Alas, SDR Console runs great until it drop dead with a simple, “Waiting" then it shuts down - as if it failed to do something important and was being nice enough to exit without crashing the system with a BSOD. It’s probably due to my system's plethora of USB ports all vying for Interrupt priority regardless of the fact that my SDRPlay RSP1 is connected to a dedicated port.
I've now tested both SDRUno and SDR-Console using the highest quality USB 3.0 and USB 3.1 controllers and SDR Controller also produced a BSOD. That strongly suggests the issue is with the MIRICS API that the SDRPlay RSP1 uses to control it. SDRPlay is aware of the issue and is working on a solution since newer machines may come only with USB 3.x ports. It is likely that MIRICS will be the one to iron out that wrinkly since it is their API and driver. We shall see.
But don't let my USB issues deter you from giving it a whirl. A lightly loaded or dedicated system with a direct USB port connection (not through a hub) and few background processes to steal CPU cycles, your results will surely be better. The good news is that the bundled SDRUno software hasn't crashed on me once while using either a dedicated or hubbed USB 2.0 port.