Panning

[rakslice]

Per-app pan sliders, re: #97

I hacked this together quickly to get it working for my own needs; feel free to ignore or rip it apart. Notable things that are missing from this:

• precalculating the coefficients for the pan settings to make the plugin faster, or any optimization at all really
• L and R tick marks on the pan sliders, or some other visual indication that shows what the pan sliders are for -- maybe people would prefer rotating knobs for this?
• tests for this stuff

[rakslice]

whoops, this [NSSlider setCellClass] call is spurious test code changing the global default slider cell class that shouldn't have been left in

[rakslice]

I guess this function could be used with any map, so it doesn't even know which mutex to expect to be locked

[rakslice]

I probably thought I was editing my own comment wording here, no nitpicking intended :)

[rakslice]

minValue is zero for the volume slider anyway, but I'll pay it forward for the next person who copy-pastes the code ;)

[rakslice]

If someone knows a better way to set a custom subclassed NSSlider coming in from Interface Builder to use a custom NSSliderCell subclass, I'm all for it; it took me hours of hitting my head against the wall of ambiguous documentation and forum posts to come up with this.

[kyleneideck]

@rakslice I didn't find any bugs or anything, so I went ahead and merged this. Thanks!

As far as I can remember, the only significant change I made was to move the sliders into a dropdown section:

I'm not really sure how people usually use pan/balance, so let me know if you find that gets in the way too much. Or if you disagree with anything else I changed, for that matter.

I've added L and R labels, and a centre tick mark since I thought it looked better with the L and R labels and differentiated the pan and volume sliders a bit. With the centre tick mark, snapping is handled automatically so I ended up removing the snap function you added.

I've also been adding people to the copyright notices of files they change, so let me know if you'd prefer not to be listed in those.

precalculating the coefficients for the pan settings to make the plugin faster, or any optimization at all really

For me, your code for applying the pan position in BGM_Device::ApplyClientRelativeVolume ran about as fast at the code for applying the app volume -- a bit under 0.5 us each. I didn't look into combining the two, either (or using the Accelerate framework to go beyond SSE2) but 1 us seems pretty reasonable to me.

[rakslice]

On Tue, Feb 14, 2017 at 4:53 AM, Kyle Neideck ***@***.***> wrote: @rakslice <https://github.com/rakslice> I didn't find any bugs or anything, so I went ahead and merged this. Thanks!

Cool.

As far as I can remember, the only significant change I made was to move the sliders into a dropdown section: [image: Screenshot] <https://camo.githubusercontent.com/0f03432e7beb76a4b0d7cc460b756397766b2977/68747470733a2f2f692e696d6775722e636f6d2f525132494f5a772e706e67> I'm not really sure how people usually use pan/balance, so let me know if you find that gets in the way too much. Or if you disagree with anything else I changed, for that matter. I've added L and R labels, and a centre tick mark since I thought it looked better with the L and R labels and differentiated the pan and volume sliders a bit. With the centre tick mark, snapping is handled automatically so I ended up removing the snap function you added.

That seems fine; I'll test it out when I'm back on my Mac. My use case is monitoring 2 video streams w/ audio at once while I'm doing other stuff that sometimes includes its own audio, so I open them in different apps and give them different pan positions. I've also been adding people to the copyright notices of files they change,

so let me know if you'd prefer not to be listed in those.

I don't mind if you list me. Cheers, -at