Open ann0see opened 2 years ago
As far as I can see all is well on Win10.
How long does it take for the symptom to appear? I am also running macOS Monterey (12.0.1) and Jamulus 3.8.1 I didn't experience any issues during my 90-minute session on 12/7.
@bhr-private Your issue has been moved here: https://github.com/jamulussoftware/jamulus/issues/2164
Please reply on the new issue.
See attached screen record, which shows just a part of the behaviour e.g. volume level also change when people entering a room. Also a print screen of the Security& Privacy settings.
Thanks bernhard
Just trying to think of what mechanism in the SW could be causing the sliders to move. Could it be that you have some form of MIDI software that is running in the background, Jamulus sees that and connects and the MIDI is randomly changing things? I am having problems imagining what else could be causing this.
Are you Jamulus with a modified command line at all? If so, could you provide the full details, please.
(As it's a Mac, I don't know how to find out - I may be asking the question wrongly, too...)
I use a VST plugin (Superior drummer 3) that my drum connects to using Midi. Don't think it is Midi, as all sliders move to the same level when symptoms occur.
I also tested with command line and no difference to the behaviour.
Anyone know how to completely ! uninstall/remove Jamulus?
Still... Knowing the SW I can't think of any other way of making the sliders move. Do you have the same symptoms if you don't use MIDI ?
I also experience this problem on Mac OS Monterey. Another symptom is the Jitter buffer sliders in Audio/Network Setup. You should be able to move the Local and Server sliders individually, but for me they seem to be connected and it is nearly impossible to set them the way you might want to. There is also something weird going on with the scale lines along the sliders...
I use a VST plugin (Superior drummer 3) that my drum connects to using Midi. Don't think it is Midi, as all sliders move to the same level when symptoms occur.
I also tested with command line and no difference to the behaviour.
Anyone know how to completely ! uninstall/remove Jamulus?
In Mac OS, there is normally nothing to uninstall, you just delete the app from the Applications folder or wherever you put it. The Jamulus settings is in ~/.config/Jamulus/Jamulus.ini if you want to move or delete them.
@bjobr just tested the Jitter buffers - jumping up and down. Which software/instrument are you using, is Midi part of your configuration?
No midi. I am using Jamulus for choir, so my setup is an audio interface with mic/headphones, Jamulus, Zoom and Safari.
@bjobr can u do me a favour and check whether you have Facetime on or off - I just switched off Facetime, which should disable SharePlay (which came with Monterey) and things look different / better ...
@bhr-private Interesting idea. I disabled Facetime and rebooted, but Jamulus behaviour seems to be the same. Only verified by observing the Jitter buffer sliders, but I believe the root cause is the same for all slider settings. Reverb slider appearance is also affected.
Did the problem go away for you when you disabled Facetime?
Also tried disabling Messages, as well as removing all accessibility and automation privileges in Security & Privacy settings. Created a new user account, no change in Jamulus behaviour.
We should note that this appears to be a visual/presentation problem, the values of the slider controlled variables are not really affected. I think there is some kind of Monterey incompatibility in whatever GUI toolkit is used.
I agree, and disabling Facetime was of no success in the end. I do also agree on your GUI comments on Monterey. I think we can also safely exclude Midi components, as you are not using Midi.
Question is how to address this - I was doing a Google search hoping to find other applications with those symptoms with no success.
So, just to be sure, is it established that this problem exists only on macOS 12 (Monterey) and not on earlier versions (up to Big Sur)? Do we know if all users of Jamulus on Monterey experience it, or only some?
EDIT: OK, I see above that @gene96817 doesn't experience the issue on Monterey.
@gene96817 have you had another Jamulus session since 12/7? May I ask you to join any Jamulus session playing around with the sliders (volume, jitter faders) and reporting back.
Still wondering which piece of software is responsible for this behaviour.
I also have this problem. I believe it started after upgrading to MacOS Monterey. I upgraded tot Jamulus 3.8.1 around the same time, so I thought that might be the problem. I tried going back to Jamulus 3.8.0 because but I thought that might be the cause but it exhibited the bug behavior under MacOS Monterey.
I don't believe the value of the faders change just their visual settings. For me it comes and goes. One moment the faders for all users will be normal, then suddenly they are all the same level, then a while later they are normal again.
Testing a new setting > System Settings >> Accessibility >>> Display >>>> Reduce Motion
Things look promising, I am cautiously optimistic.
Maybe another Qt on Mac issue?
This sounds surprisingly similar https://bugreports.qt.io/browse/QTBUG-98093 + related article / workaround here https://stackoverflow.com/questions/69890284/qslider-in-qt-misbehaves-in-new-macos-monterey-v12-0-1-any-workaround
I don't know if the components are QSliders though.
I don't know if the components are QSliders though.
Yes, they are QSliders. Thank you for the heads-up!
@bjobr @bhr-private @alanz1357 Please could you test whether the issue occurs in all three skins: Fancy, Normal and Compact?
@softins short answer ... Fancy = OK, Normal & Compact OK with "Reduce Motion".
Question out of interest: Is porting the Jamulus client to a Java based version a feasible thing?
@softins short answer ... Fancy = OK, Normal & Compact OK with "Reduce Motion".
Thank you, I suspected that might be the case. The stackoverflow article referenced above suggested the issue could be solved with custom stylesheets, and I remembered that Fancy skin is already implemented using stylesheets.
Question out of interest: Is porting the Jamulus client to a Java based version a feasible thing?
That would depend on the underlying architecture. It might work if the Java is compiled to machine code, but I doubt a JVM would be fast enough. It probably wouldn't happen unless someone with the appropriate skills felt passionately enough to do it! There is a command-line client implemented in Rust at https://github.com/dtinth/jamurust that looks very interesting, but it doesn't have any GUI interface. It could make a useful starting point.
@softins Fancy = just another workaround - I stick with the "Reduce Motion" option - got used to the "Normal" skin. In either case glad that this could be solved.
I am not a developer, more in system engineering - was just thinking that an OS independent version will require less effort in the end. Agree with the performance issue, would probably require a lot of tweaking here.
Also on the wishlist, being able to listen to Jamulus sessions without being connected (e.g. IceCast streaming server).
But all that is "nice to have" - just happy that Jamulus is available.
Also on the wishlist, being able to listen to Jamulus sessions without being connected (e.g. IceCast streaming server).
Jamulus works on the KISS principle - keep it simple and stupid. It aims to do one thing and do it well.
You can already have a client connected that has its audio output connected to an IceCast streamer. For a more media-rich example, try watching Jamulus WorldJam every other week to see what's possible. Lots of live events are being broadcast over the net already using Jamulus for audio.
@softins short answer ... Fancy = OK, Normal & Compact OK with "Reduce Motion".
I see exactly the same behaviour, Main window is ok with Fancy skin, other skins and Settings window require "Reduce motion" to be ok. Thank you @bhr-private for this workaround!
Discussed in https://github.com/jamulussoftware/jamulus/discussions/2160