sl23 wrote: ↑May 2nd, 2022, 8:42 am@Yincognito: WHAAAT?!
You lost me... on pretty much all of that! This is why I could never be a programmer!
I so wish I did IT at school!
Nah, man, I lost you on that and you're having trouble becoming an amateur programmer because you didn't read the manual entry, not because it's complicated, LMAO. But don't worry, it's ok, I won't tell anyone ... who I didn't tell already.
sl23 wrote: ↑May 2nd, 2022, 8:42 amSo... Roundline used a number that was in fact an error code? Htf does that happen?
But when I looked at About/Skins, the value was a number, not a string, when I remove the substitute. But it appears in the column of String not Number? That window is confusing, as even the Mute/Unmute states don't change the Number value?!
A measure has 2 values: a numerical one and a string one. In some cases (like a RunCommand measure), these 2 are different from each other: the numerical value is the error code after launching whatever command you launch (so you can know if it ran successfully and all that), while the string one is the STDOUT output of the said command after it has been run (i.e. what you're looking after). That is the reason why you see different values in the Log for the said RunCommand measure. In this case, the raw output string value "looks like" a number, because it's "70.0\n", aka a string made of the percentual value using a precision of 1 after the decimal, followed by a newline character, and you can easily see that if you right click and choose "String: Copy to clipboard" in the Log and then paste it into a new Notepad++ tab. The mute/unmute measure follows the same principle, and that is why it looks that the number value doesn't change - well, it does, but it does very fast, according to the stage in the execution of the command, eventually becoming 1 if the execution was successful.
A Roundline meter by default will use the number value of whatever source measure it uses, but since we're talking about RunCommand measures, that is not what you'd want, for the above reasons. You'd want to use the string value of the measure, but since you can't control that in the meter, you'd have to create a new measure that takes the string value of the relevant RunCommand measure and "converts" it to an explicit number. After that, everything works fine.
sl23 wrote: ↑May 2nd, 2022, 8:42 amI have never used those in a Roundline meter and never had any issues with them. What sort of problems arise from not using them?
The problems that can arise from not specifying W and H for a Roundline meter range from it being invisible to being truncated, at least that is what my (limited) experience with Roundline meters was. I might be wrong and fail to see the right approach on this, but I always found it safer to explictly set the W and H and not have any kind of issues where I wonder where the heck it went or what X and Y would I need to bring it back into view. Anyway, if you didn't have such problems, then you might be more familiar than me with how it's positioned and dimensioned, because for the occasional instances where I help someone on the forum, I don't use Roundline meters much. I love them cause they're pretty, but I'm space limited in my suite.
sl23 wrote: ↑May 2nd, 2022, 8:42 amIs it not possible to close these with a Bang after a delay Bang?
A command executed in a RunCommand will automatically close when the CMD or whatever program you run exists, or when the Timeout value expires, there's no need to do that in a bang. You could reduce the Timeout value (in your case, the value of the Timeout variable), but then, if you set it too low, the CMD+SVCL system won't have time to run and yield the desired outcome. Frankly, I expected that the command line version of that NirSoft utility to be much faster, like CMD commands and programs usually are, but it appears it's a bit slower, so it is what it is.
sl23 wrote: ↑May 2nd, 2022, 8:42 amGoing back, is there a way to get the 'Command-Line Friendly ID' from SoundVolumeView and place it into a Variable? The plan is if Rainmeter is moved to another PC, a simple button click would get and set the Variables new ID. I guess this would need to be the Default Input Device.
You already have that variable, as CmdFriendlyID, so it's more or less the same. If you're talking about detecting which friendly ID is the microphone on an arbitrary PC so it can be used as the said variable in the skin, you should check the avilable parameters for these utilities on their pages and see if you can achieve it. As far as I tried, there is no way of getting (just the) the friendly ID for a string like "*Microphone*" the way you can do it with PowerShell, and even if you did, the friendly IDs won't match between these two. Also, the friendly ID of a mic will most likely differ from PC to PC, so saving yours and using on another PC would be pointless. Of course, you can easily export all the info about audio devices to a file by using
svcl /stext "<Filename>" (or
svcl /stext "" if you want it displayed on STDOUT) and you could probably filter lines containing "Microphone" using some CMD or RunCommand system or substitute, but that would not be so reliable as you wouldn't know exactly which of the mic entries the said user would like to manage or display info from.
That being said, I'll try some other PowerShell approach to all this, maybe it will work. If it does, I'll let you know.