You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can open separate issues for these, but I think the "should we" needs to be discussed together.
It would be cool to have some powershell methods for switching the audio device from the CLI, for those of us into that kind of thing. Two that come to mind are of course Get-AudioDevice [-Active] [-Filter] and Set-AudioDevice [-Name]
To do that you need a DLL, not an exe. Rather than make a DLL and a wrapper EXE, it would be simpler to replace the static void Main() call with a call that rundll32.exe can make via UnmanagedExports The chocolatey package can then include a batch file to start this up manually, and add that batch file to the start menu.
Also, once this is a DLL, it makes sense to make this a regular nuget package and supporting an API as well.
The text was updated successfully, but these errors were encountered:
Continuing from #20. I'd rather not use rundll32.exe, I'd rather a real CLI interface to handle this.
Well powershell Cmdlets, not CLI arguments, but why not both if someone wants to control the audio device from cmd.exe.
For CLI arguments I don't need to do this. For powershell cmdlets, I need this to be a DLL, not an exe so I can load it as a powershell module.
Maybe the powershell cmdlets just need to be in a separate dll.
I see. Have a few questions:
How well do old-school console apps play with PowerShell? I assume by above that you'd expect Get-AudioDevice to actually return a AudioDevice representation itself, right?
It's clear what Set-AudioDevice will do (although, there's no good unique friendly "name" to represent a device, though maybe the non-unique description "Speakers" might be good enough). But what do you want to do with Get-AudioDevice? What would you do with the result? Perhaps filter and then pass result to Set-AudioDevice?
A console app will play fine enough with powershell. A possible workaround for better powershell support is to have the -listdevices option return XML. Powershell is really awesome at parsing xml output, and people do things with the xml output of svn all the time.
Is there a non-friendly (e.g. guid) unique identifier for audio devices?
I can open separate issues for these, but I think the "should we" needs to be discussed together.
It would be cool to have some powershell methods for switching the audio device from the CLI, for those of us into that kind of thing. Two that come to mind are of course
Get-AudioDevice [-Active] [-Filter]
andSet-AudioDevice [-Name]
To do that you need a DLL, not an exe. Rather than make a DLL and a wrapper EXE, it would be simpler to replace the
static void Main()
call with a call that rundll32.exe can make via UnmanagedExports The chocolatey package can then include a batch file to start this up manually, and add that batch file to the start menu.Also, once this is a DLL, it makes sense to make this a regular nuget package and supporting an API as well.
The text was updated successfully, but these errors were encountered: