Closed VincyZed closed 1 year ago
There's a global left/right invert setting which may be related.
Just found that button. It was off, and turning it on or off makes no difference.
I confirm that toggling the "Swap stereo" switch does nothing with zynfusion / zynaddsubfx git head as of last week.
The same issue exists with the fltk interface: channels are swapped and the global invert setting has no effect. So it's not an issue with the new UI.
Exactly which pan controls are we talking about here: the ones in the Mixer pane, in the Part settings, or somewhere else? Which environment (standalone, as a plugin (in which host?), etc)?
When I tested a few random patches just now both running in standalone mode on a PC or in Zynthian, the Mixer and Part pan controls appear to visually pan the audio in the correct direction as viewed on the VU meters in the Mixer pane as well as the global VU meter in the upper right hand corner of the UI, and the sound also audibly pans in the correct direction. (In these cases, I was operating in multi mode (starting zynaddsubfx with -O jack-multi, which is perhaps not the most common way).
(A while ago (January 2022) I fixed an issue in multi mode where the output from the individual parts was swapped due to a number of swaps internally, even though the sum output was correct. (https://github.com/zynaddsubfx/zyn-fusion-issues/issues/330)).
Thanks for keeping me honest. I went through all the pan controls I could find in the Zest standalone interface, on Linux.
The general stereo swap switch indeed works (also on Mac/FLTK) as long as Zynadd is restarted. This is mentioned in the FLTK UI, not in Zest.
I checked that my physical cabling was set up correctly using Ardour, which I assumed does the right thing, as in: channel 1 is left, 2 is right. In all cases mentioned below, Zest's viewmeter in the top-right corner agreed with the sound output in the speakers.
Command line used: zynaddsubfx -I jack -O jack -U -P 1337
+ Zest launched using make run
from the mruby-zest-build git directory.
With the 'swap stereo' setting unchecked, I found inverted panning in quite a few places
I also looked at effects. For all effects that have a 'pan' button, the panning is handled correctly, with the exception of "distortion" for which the pan button appeared to have no effect.
Thanks @pgervais for the detailed list. I haven't checked the effects, but I can verify that all the other pan locations behave as you mention.
Where you planning to look into this as you are noted as the assignee of the issue?
My initial intention was to check whether this issue was fully resolved and I assigned the ticket to myself as a way to bookmark it. So if you want to take care of the fix, feel free to reassign the ticket to yourself. And if alternatively you would like some help, just let me know.
I'll see if I can have a look at it. Since I fixed a couple of pan issues already I'm a bit annoyed with myself for missing the ones that remain.
Seems I'm not registered as a collaborator, so I can't reassign the issue. @fundamental, would that be possible?
Looked in the code and found the location of all the Add/Sub/Pad pan bugs (should be an easy fix), but the pan in the distortion effect looked fine. After some more experimentation, it turns out that the L-R-Crossover (L.RC) control affects pan, so that if LRC is in its center position, pan essentially has no effect, since both L and R affect both channels equally. With LRC in its leftmost position, pan works as expected (and is inverted when LRC is in its rightmost position, as then L feeds R and R feeds L). I haven't dwelled to much on it, but instinctively it seems as if it's working as intended, even if it may not be completely intuitive depending on what you are expecting.
I've created a pull request if anyone wants to test: https://github.com/zynaddsubfx/zynaddsubfx/pull/242 .
Closing the ticket since the PR mentioned above has been merged. Thanks @polluxsynth !
The pan controls in Zyn-Fusion are inverted. Dragging the knob to the left actually pans the audio to the right, and vice-versa. The value of 0 still applies a random value correctly, though.