andreykaipov/goobs

InputVolumeMul doesn't accept `0` volume

Closed this issue ยท 3 comments

normen commented

Hey,

first of all thanks for the library, it makes it so easy to interact with OBS!

While controlling some audio channels in OBS I encountered the following issue:
When I am trying to set the volume of a channel to zero (-inf) via InputVolumeMul, the following command:

		_, err := client.Inputs.SetInputVolume(&inputs.SetInputVolumeParams{
			InputName:      name,
			InputVolumeMul: 0,
		})

yields this result:

2023/11/20 00:15:36 request SetInputVolume: MissingRequestField (300): You must specify one volume field.
2

I suppose this is because the json omitempty directive in SetInputVolumeParams? At any instance, for now I am working around this by setting the volume via dBs when its zero..

normen commented

Same for the inputAudioSyncOffset

Edit: (workaround: set it to 0.0001)

Hey @normen! Sorry I missed your issue from so long ago. I need to figure out a better way to filter through notifications from GitHub!

I suppose this is because the json omitempty directive in SetInputVolumeParams?

You are indeed right about that. It's come up before for bool types in #27, and the fix was to use *bool to be able to distinguish between zero-values versus unset values. I've noticed a lot of other client libraries for various other APIs also prefer the approach of using pointers everywhere to avoid things like this, but as mentioned in that issue, the UX for setting pointers to primitives is really ugly (but maybe not so ugly nowadays with generics).

So yes this is a limitation of the library, but your work around is what I've used in the past too. And my past self apparently knew this day would come:

I imagine there's a few integer fields whose empty value (0) happens to be a valid value in a request, so in the future more fields may omit omitempty, but that's something to worry about later ... ๐Ÿ˜„

However omitting omitempty wasn't the right fix but using pointers is what would have to done. One day I'd like to revisit the functional option approach mentioned in #27 (comment) that would improve the UX of creating the request objects and at that point I wouldn't mind having pointers everywhere.

I'm a bit on the fence myself adding pointers to primitives everywhere now but I think if I sleep on it I'll realize it'd make the library more reliable so it should probably be done some day... It'd require changing the Number and String cases to look like the Boolean case at https://github.com/andreykaipov/goobs/blob/v0.12.1/internal/generate/protocol/generate.go#L382-L388. That might break some tests though.

This was released in v1.0.0 ๐Ÿ˜„