Hi,
Not sure where to post this, but I just want to encourage the developers to consider an update to the user interface. This morning I was trying to help the director of a youth music program try out Jamulus and Sonobus this morning. His impressions (I'm paraphrasing): Jamulus is good but difficult to setup and use; Sonobus was much easier to get going. In general the differences are just in the UI! I've had similar responses from several people.
The biggest problem is that the client's sound in the "Personal Mix" is not muted by default, and it creates a lot of anxiety when a feedback loop is blaring and we're trying to get it turned off. Despite my attempts to give clear instructions that the "Mute Myself" button doesn't actually mute the app and that they need to click "Mute" in the personal mix, "Mute Myself" is always the thing that users click first! Then we're stuck in a catch-22, where they can't hear me without starting the feedback loop again. It makes setup very frustrating and leaves a bad impression overall, even if we get it working in the end.
So 1st - I strongly recommend making your own sound in your Personal Mix both in a "Mute" state and the slider all the way down as a default. Make it difficult to start a feedback loop, not the default if someone's headphones aren't hooked up properly!
2nd - I'd recommend the first time the Jamulus client is run it should launch the My Profile dialog so that users can name themselves. Trying to get 10 people to connect and sorted is difficult when they all have the same name.
3rd - the checkmark UI feature isn't consistent. Some checkmarks open a dialogue box (Settings, Chat), others just enable a feature (Mute Myself, Grp, Mute, Solo). I'd suggest making Settings and Chat proper buttons (like Connect, which opens a dialogue). Then leave check marks for toggles.
4th - if I understand correctly, the Buffer Delay has 4 settings: 10.67, 5.33, 2.67, and 2.67+"Enable Small Network Buffers". Why not just make it a 4-step sliding scale from "Faster" to "More Stable"? Then put text underneath that gives more detail.
SonoBus has some other neat features - client side recording, metronome (client or shared - but unfortuantely not synced, something that maybe Jamulus could do?), more refined reverb controls. Might be worth looking into?
Anyway, should I post these suggestions on Github or something? I'm not a software developer at all, just a fan of Jamulus and how it has enabled us musicians to stay connected during the pandemic. Thank you to everyone working on it!
👍
3
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Crossrhythm - thanks for the suggestions. On your numbered points:
This is an interesting point, and has I think been discussed (one such discussion gave rise to the --mutestream option). There is always a bit of confusion about how Jamulus works in terms of the sound you hear and the sound coming from the server, so it's possible such a default might cause other problems but it's worth raising as an issue on Github I think.
Yes. In fact a "first run wizard" containing that and some other things (like sound setup help for Windows users in particular) has been floated. Again, worth a feature request.
Indeed. Perhaps a minor point, but it adds incrementally to the general impression of difficulty.
This is a good idea I think, and while it has in fact been discussed in another context before, might be worth raising again as a way of helping people understand why the different settings are there.
On your initial point about "mute myself" , I'm a bit confused. If they get feedback, then "mute myself" is the correct thing to do (otherwise your suggestion in 1 would not work). And if you tell them to hit "mute" on a channel as well then that would give rise to the problem of them not hearing you.
As to client-side recording that would be nice, although I think the current feeling is that if you can do it using other tools (which you can) then Jamulus would rather concentrate on other things. Metronome has been discussed quite extensively and I'm afraid that's not going to be possible with Jamulus in its current form. More refined reverb might be possible depending on how it's being implemented in the code today.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you Gilgongo, it's awesome technology and so appreciate the work you all are doing! I think making it as easy and pain-free as possible to get started for new users will only increase its reach and adoption.
Just a point for consistancy - for Audio Quality, there is no indication of bit rates, VBR vs CBR, compression, etc, just Low - Normal - High. Same standard could apply to the Buffer settings.
For the feedback loop, the problem is that, remotely, it can be difficult to be sure a new user isn't about to fall into a feedback loop, especially when trying to help several people at once. Then once they connect it's too late! Then they hit "Mute Myself" (usually with me prompting over Zoom - "you need to click the Mute button above your name!"). Then I say "Not that one, the other one", and they inevitably uncheck "Mute Myself" and theiy're back in the feedback loop again. It has happened at least four or five times when getting people setup and is starting to get old! :)
Then the problems with ASIO4ALL... well, probably too much to go into here...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to say, untangling the confusion around muting is quite a challenge. Interestingly, it occurs to me that I don't know under what circumstance you would want to hit the mute button above your name but not the "mute myself" button. In the circumstance you have feedback, hitting either would work, since "mute myself" cuts your sound going to the server, and "mute" cuts the sound coming from it. Would there be a circumstance in which you would want other people to hear you, but not yourself, I wonder?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would there be a circumstance in which you would want other people to hear you, but not yourself, I wonder?
I am not quite sure what you are asking here but I like to press the mute button on my own slider so that I don't hear my own echo. Note we are using Jamulus with microphones for singing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right, hk1020, that's what I do. As an accoustic musician (violin), I find it difficult to play with a monitor on, whether it is immediate or with the slight delay of Jamulus. The classical musicians I've worked with also seem to find it better when the "echo" is removed. Maybe it's different/easier for singers or those used to working in a studio setting?
Does it help with alignment with the other musicians to listen to the monitor? I just advise everyone to play with a driving tempo, don't hold back, anticipate every entrance a bit and we usually can find a groove.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nononooo. You MUST listen to the SERVER sound or you will never synch with the other musicians! This REQUIRE headphones! It wont take long time before you got used to play lsike that.
if you listen to your local and the delayed sound from the others you will be such a drag to play with because you will be so late..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hehe. There is a lot of confusion on this point :-)
Fundamentally, the way Jamulus works is that everyone sends their sound to the server, the server mixes that all together, and then sends that mix back to each player (who can then adjust the levels in their "local" mix),
The only way you can keep in time with other musicians is to listen to them (just like in the real world), unless you have the ability to play in front of the beat to prevent yourself from slowing down relative to them.
This is obviously hard for singers and some acoustic musicians though. But if you hit "mute" above your name, that basically guarantees you will have problems keeping in time. How bad this problem is depends on how much latency you have of course.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe there is a difference for acoustic musicians, I think @Crossrhythm feels the same. We had no problems to stay together, our conductor plays the piano and we just sing along with it. Works for rhythmically more complex places as well. Actually, what I hear in the headphones doesn't change much without my own voice. Without the piano it gets hard, though.
Last edit: hk1020 2020-11-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If your overall latency is small (<25ms perhaps) then it probably won't be an issue. And some forms of music are pretty tolerant of latency. The percussion section in a big orchestra might be as much as 43ms (15m) away from some of the first violins, for example.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
then you have your own voice too low in the mix. you should have it so strong that its is stronger than the sound directly from your mouth. Thst you sont hear any difference in your mix just shows that you dont hear yourself in the mix.
Thibg is this: if you hear yourself delayed, your brain will automatically compensate and you wil start the correct amoubt of time earlier to make your voice appear in time on the server.
This a test that is funny and rather disturbing: send a metronome sound in 120 bpm to a server in such a way that you only hear the sound from the server. Now whith headphones, listening to the server sound only, try to clap so the sound of your clap on the server is in synch with netronome. continue clapping to metronome until it feeks totally natural (some minutes)
Then remove headphones and continue clapping: you will now experience that the sound of the clapping comes before you actually clap! Your brain has adjusted the internal synch of the experiences! this effect dissapears quickly thou
😄
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
wow, this reminds me of the Top Gear episode where one of the guys tries to drive an F1 car, and keeps having trouble because he cant get it fast enough to heat up the tires properly to get enough grip! Sounds like you have to go all-in to make it work with monitoring your own sound.
Maybe I'll try it with in ear monitors. My cushy cans don’t keep the sound out. I also worry about hearing damage if I turn it up too loud....
Is it possible we're both right?
1) distance model: we're all playing as if we are on opposite sides of a stage (~3ms/m), where you have to anticipate and push the tempo to have any hope of staying together.
2) delay model: Block out outside/acoustic sound and learn to compensate to play together directly with the latency
Mats, I get the sense that you are skeptical, but I had a relatively successful performance last weekend. Jamulus starts at 27:00 - https://fb.watch/1TUR4gXy5_/
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree it's not straightforward. I have a theory that the overall Jamulus UI makes it harder to understand because it presents itself like a real-world mixing desk, with faders, level indicators, mute buttons, etc., when in fact the sound path is not like a mixing desk at all in some ways. So the more familiar you are with mixing desks, the harder it is to understand what is going on sometimes. I have experimented with alternative UIs for this reason but it's very tricky!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what is not fully compatible with the paradigm of a mixing table?
With a mixing desk you don't get issues like playing your instrument and seeing your levels, but not hearing your sound (because you are not connected to the "speakers", which are effectively the server). Or muting your input, hearing yourself and seeing your levels, but nobody else in the room being able to hear you (ie "mute myself"). Or adjusting the faders, pan, etc. for other people and them not hearing the effect of that. Or muting them and them not knowing you can't hear them (and you can see their levels even when they are muted).
And perhaps most "interestingly" (and as discussed in this thread), if Jamulus does act for you like a normal mixing desk in the sense that you can hear yourself when you aren't connected to a server, then that means you're using it wrongly :-)
The Jamulus UI has to have several "hacks" to try to message these non-mixing desk phenomena but they often fail for new users who simply look at it and (subconsciously or not) think "Oh, it just like a mixing desk".
Last edit: Gilgongo 2020-11-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gilgongo could you share your ideas for an alternative UI ? Maybe some collective brainstorming could help.
As an engineer I have no problems with the concepts and hidden portions of what is happening using Jamulus, but I can appreciate that most people don't think like an engineer and that there may be better ways to present things to make the results of different actions clearer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm hesitant to share them, mainly because I'm pretty sure that implementing would will require a fork and all the issues that implies. They are VERY different from the current UI. But maybe if I think about them some more I'll post them here for discussion.
And yes, I think the "engineering" conception of Jamulus came out most strongly for me when we discussed a new icon for the server. It was suggested that the server icon (not the client!) should have a representation of a mixing desk on it. That is probably closer to what the sever actually is, technically, but .... :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, to be precise, the reason I'm not clear about the signal chain is because of the mixer metaphor. I don't have anything against mixers, if that's what you mean. And Jamulus does have a few hints as I've mentioned (we recently introduced a very visible message when you use "mute myself" and the icon to show you who can't hear you).
But yes, some graphical hints of the signal chain is what my UI is sort of based around (or one of my ideas for the UI at least).
But this is a very well-know problem in UI design. Metaphors are useful to communicate the way something works at first, because the user's understanding of the real thing (in this case, a mixer) lets them understand for example that a slider will adjust volume on a channel. But once you have chosen a metaphor, you lose control over the user's interpretation of it unless you stay true to the thing it's supposed to represent. And after a certain point that becomes impossible, because the UI isn't the thing it represents. Jamulus client is not a mixing desk. It's a tool for jamming on line. :-)
So the other approach is to not use a metaphor and have the user understand the UI without reference to anything else. This makes it hard for the user at first, but keeps you (the designer) in control of their understanding. For example: in my "alternative" UI for Jamulus, only those who can hear you appear in the "room". Those that have muted you are demoted out of it. But design can never go entirely without mimicry, because if you’re not speaking some kind of common visual language, you cannot make yourself understood. It's a balance. And I think Jamulus currently has that balance wrong. But without exploring the other side, it's hard to say.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OBS handled a few things:
- FB live stream
- choosing and combining video and audio sources and try to fix the audio delay/sync
- put up an intro graphic before I started
- with Touch Portal, let me change scenes (intro, solo, Zoom+Jamulus) remotely
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, it not only helps , but is a requirement to get synchronization of all players to listen to the sound from the server, it is impossible otherwise as you don't know how far off you are and as such can't correct.
And yes, it does take some getting used to. But playing now with others using Jamulus for several months the latency and correcting for it is no longer an issue. I play viola and play together mostly with other strings. There is no question for me any more that it works also for acoustic instruments and I expect just as well for singers.
We are back to the normal discussion of rehearsals, interpretation, etc. One thing we have noticed, however, it that this is great training for the ear. As all cues pass only auditively we become much more attuned and sensitive to listening. We are not really missing the visual cues.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Not sure where to post this, but I just want to encourage the developers to consider an update to the user interface. This morning I was trying to help the director of a youth music program try out Jamulus and Sonobus this morning. His impressions (I'm paraphrasing): Jamulus is good but difficult to setup and use; Sonobus was much easier to get going. In general the differences are just in the UI! I've had similar responses from several people.
The biggest problem is that the client's sound in the "Personal Mix" is not muted by default, and it creates a lot of anxiety when a feedback loop is blaring and we're trying to get it turned off. Despite my attempts to give clear instructions that the "Mute Myself" button doesn't actually mute the app and that they need to click "Mute" in the personal mix, "Mute Myself" is always the thing that users click first! Then we're stuck in a catch-22, where they can't hear me without starting the feedback loop again. It makes setup very frustrating and leaves a bad impression overall, even if we get it working in the end.
So 1st - I strongly recommend making your own sound in your Personal Mix both in a "Mute" state and the slider all the way down as a default. Make it difficult to start a feedback loop, not the default if someone's headphones aren't hooked up properly!
2nd - I'd recommend the first time the Jamulus client is run it should launch the My Profile dialog so that users can name themselves. Trying to get 10 people to connect and sorted is difficult when they all have the same name.
3rd - the checkmark UI feature isn't consistent. Some checkmarks open a dialogue box (Settings, Chat), others just enable a feature (Mute Myself, Grp, Mute, Solo). I'd suggest making Settings and Chat proper buttons (like Connect, which opens a dialogue). Then leave check marks for toggles.
4th - if I understand correctly, the Buffer Delay has 4 settings: 10.67, 5.33, 2.67, and 2.67+"Enable Small Network Buffers". Why not just make it a 4-step sliding scale from "Faster" to "More Stable"? Then put text underneath that gives more detail.
SonoBus has some other neat features - client side recording, metronome (client or shared - but unfortuantely not synced, something that maybe Jamulus could do?), more refined reverb controls. Might be worth looking into?
Anyway, should I post these suggestions on Github or something? I'm not a software developer at all, just a fan of Jamulus and how it has enabled us musicians to stay connected during the pandemic. Thank you to everyone working on it!
Hi Crossrhythm - thanks for the suggestions. On your numbered points:
This is an interesting point, and has I think been discussed (one such discussion gave rise to the
--mutestreamoption). There is always a bit of confusion about how Jamulus works in terms of the sound you hear and the sound coming from the server, so it's possible such a default might cause other problems but it's worth raising as an issue on Github I think.Yes. In fact a "first run wizard" containing that and some other things (like sound setup help for Windows users in particular) has been floated. Again, worth a feature request.
Indeed. Perhaps a minor point, but it adds incrementally to the general impression of difficulty.
This is a good idea I think, and while it has in fact been discussed in another context before, might be worth raising again as a way of helping people understand why the different settings are there.
On your initial point about "mute myself" , I'm a bit confused. If they get feedback, then "mute myself" is the correct thing to do (otherwise your suggestion in 1 would not work). And if you tell them to hit "mute" on a channel as well then that would give rise to the problem of them not hearing you.
As to client-side recording that would be nice, although I think the current feeling is that if you can do it using other tools (which you can) then Jamulus would rather concentrate on other things. Metronome has been discussed quite extensively and I'm afraid that's not going to be possible with Jamulus in its current form. More refined reverb might be possible depending on how it's being implemented in the code today.
Thank you Gilgongo, it's awesome technology and so appreciate the work you all are doing! I think making it as easy and pain-free as possible to get started for new users will only increase its reach and adoption.
Just a point for consistancy - for Audio Quality, there is no indication of bit rates, VBR vs CBR, compression, etc, just Low - Normal - High. Same standard could apply to the Buffer settings.
For the feedback loop, the problem is that, remotely, it can be difficult to be sure a new user isn't about to fall into a feedback loop, especially when trying to help several people at once. Then once they connect it's too late! Then they hit "Mute Myself" (usually with me prompting over Zoom - "you need to click the Mute button above your name!"). Then I say "Not that one, the other one", and they inevitably uncheck "Mute Myself" and theiy're back in the feedback loop again. It has happened at least four or five times when getting people setup and is starting to get old! :)
Then the problems with ASIO4ALL... well, probably too much to go into here...
Good point about the audio quality labels.
I have to say, untangling the confusion around muting is quite a challenge. Interestingly, it occurs to me that I don't know under what circumstance you would want to hit the mute button above your name but not the "mute myself" button. In the circumstance you have feedback, hitting either would work, since "mute myself" cuts your sound going to the server, and "mute" cuts the sound coming from it. Would there be a circumstance in which you would want other people to hear you, but not yourself, I wonder?
I am not quite sure what you are asking here but I like to press the mute button on my own slider so that I don't hear my own echo. Note we are using Jamulus with microphones for singing.
Right, hk1020, that's what I do. As an accoustic musician (violin), I find it difficult to play with a monitor on, whether it is immediate or with the slight delay of Jamulus. The classical musicians I've worked with also seem to find it better when the "echo" is removed. Maybe it's different/easier for singers or those used to working in a studio setting?
Does it help with alignment with the other musicians to listen to the monitor? I just advise everyone to play with a driving tempo, don't hold back, anticipate every entrance a bit and we usually can find a groove.
Nononooo. You MUST listen to the SERVER sound or you will never synch with the other musicians! This REQUIRE headphones! It wont take long time before you got used to play lsike that.
if you listen to your local and the delayed sound from the others you will be such a drag to play with because you will be so late..
Hehe. There is a lot of confusion on this point :-)
Fundamentally, the way Jamulus works is that everyone sends their sound to the server, the server mixes that all together, and then sends that mix back to each player (who can then adjust the levels in their "local" mix),
The only way you can keep in time with other musicians is to listen to them (just like in the real world), unless you have the ability to play in front of the beat to prevent yourself from slowing down relative to them.
This is obviously hard for singers and some acoustic musicians though. But if you hit "mute" above your name, that basically guarantees you will have problems keeping in time. How bad this problem is depends on how much latency you have of course.
Maybe there is a difference for acoustic musicians, I think @Crossrhythm feels the same. We had no problems to stay together, our conductor plays the piano and we just sing along with it. Works for rhythmically more complex places as well. Actually, what I hear in the headphones doesn't change much without my own voice. Without the piano it gets hard, though.
Last edit: hk1020 2020-11-21
If your overall latency is small (<25ms perhaps) then it probably won't be an issue. And some forms of music are pretty tolerant of latency. The percussion section in a big orchestra might be as much as 43ms (15m) away from some of the first violins, for example.
then you have your own voice too low in the mix. you should have it so strong that its is stronger than the sound directly from your mouth. Thst you sont hear any difference in your mix just shows that you dont hear yourself in the mix.
Thibg is this: if you hear yourself delayed, your brain will automatically compensate and you wil start the correct amoubt of time earlier to make your voice appear in time on the server.
This a test that is funny and rather disturbing: send a metronome sound in 120 bpm to a server in such a way that you only hear the sound from the server. Now whith headphones, listening to the server sound only, try to clap so the sound of your clap on the server is in synch with netronome. continue clapping to metronome until it feeks totally natural (some minutes)
Then remove headphones and continue clapping: you will now experience that the sound of the clapping comes before you actually clap! Your brain has adjusted the internal synch of the experiences! this effect dissapears quickly thou
wow, this reminds me of the Top Gear episode where one of the guys tries to drive an F1 car, and keeps having trouble because he cant get it fast enough to heat up the tires properly to get enough grip! Sounds like you have to go all-in to make it work with monitoring your own sound.
Maybe I'll try it with in ear monitors. My cushy cans don’t keep the sound out. I also worry about hearing damage if I turn it up too loud....
Is it possible we're both right?
1) distance model: we're all playing as if we are on opposite sides of a stage (~3ms/m), where you have to anticipate and push the tempo to have any hope of staying together.
2) delay model: Block out outside/acoustic sound and learn to compensate to play together directly with the latency
Mats, I get the sense that you are skeptical, but I had a relatively successful performance last weekend. Jamulus starts at 27:00 - https://fb.watch/1TUR4gXy5_/
I agree it's not straightforward. I have a theory that the overall Jamulus UI makes it harder to understand because it presents itself like a real-world mixing desk, with faders, level indicators, mute buttons, etc., when in fact the sound path is not like a mixing desk at all in some ways. So the more familiar you are with mixing desks, the harder it is to understand what is going on sometimes. I have experimented with alternative UIs for this reason but it's very tricky!
How is it not like a mixing board? you have your input channel to server to the left and then all the channels coming into the mix on the server.
what is not fully compatible with the paradigm of a mixing table?
A mixing table doesn't have the same kinds of delay, right?
With a mixing desk you don't get issues like playing your instrument and seeing your levels, but not hearing your sound (because you are not connected to the "speakers", which are effectively the server). Or muting your input, hearing yourself and seeing your levels, but nobody else in the room being able to hear you (ie "mute myself"). Or adjusting the faders, pan, etc. for other people and them not hearing the effect of that. Or muting them and them not knowing you can't hear them (and you can see their levels even when they are muted).
And perhaps most "interestingly" (and as discussed in this thread), if Jamulus does act for you like a normal mixing desk in the sense that you can hear yourself when you aren't connected to a server, then that means you're using it wrongly :-)
The Jamulus UI has to have several "hacks" to try to message these non-mixing desk phenomena but they often fail for new users who simply look at it and (subconsciously or not) think "Oh, it just like a mixing desk".
Last edit: Gilgongo 2020-11-24
Gilgongo could you share your ideas for an alternative UI ? Maybe some collective brainstorming could help.
As an engineer I have no problems with the concepts and hidden portions of what is happening using Jamulus, but I can appreciate that most people don't think like an engineer and that there may be better ways to present things to make the results of different actions clearer.
I'm hesitant to share them, mainly because I'm pretty sure that implementing would will require a fork and all the issues that implies. They are VERY different from the current UI. But maybe if I think about them some more I'll post them here for discussion.
And yes, I think the "engineering" conception of Jamulus came out most strongly for me when we discussed a new icon for the server. It was suggested that the server icon (not the client!) should have a representation of a mixing desk on it. That is probably closer to what the sever actually is, technically, but .... :-)
It seems that your problem is NOT the mixer metaphore but that you are not clear of the signal chain.
So maybe that is whats needed: some graphical hints of the signal chain.
Well, to be precise, the reason I'm not clear about the signal chain is because of the mixer metaphor. I don't have anything against mixers, if that's what you mean. And Jamulus does have a few hints as I've mentioned (we recently introduced a very visible message when you use "mute myself" and the icon to show you who can't hear you).
But yes, some graphical hints of the signal chain is what my UI is sort of based around (or one of my ideas for the UI at least).
But this is a very well-know problem in UI design. Metaphors are useful to communicate the way something works at first, because the user's understanding of the real thing (in this case, a mixer) lets them understand for example that a slider will adjust volume on a channel. But once you have chosen a metaphor, you lose control over the user's interpretation of it unless you stay true to the thing it's supposed to represent. And after a certain point that becomes impossible, because the UI isn't the thing it represents. Jamulus client is not a mixing desk. It's a tool for jamming on line. :-)
So the other approach is to not use a metaphor and have the user understand the UI without reference to anything else. This makes it hard for the user at first, but keeps you (the designer) in control of their understanding. For example: in my "alternative" UI for Jamulus, only those who can hear you appear in the "room". Those that have muted you are demoted out of it. But design can never go entirely without mimicry, because if you’re not speaking some kind of common visual language, you cannot make yourself understood. It's a balance. And I think Jamulus currently has that balance wrong. But without exploring the other side, it's hard to say.
That video was great, thanks for showing. How did you do video? Is it just a muted zoom meeting?
Exactly - just muted Zoom shared through OBS. Switching scenes with Touch Portal.
What part does OBS play here? Just to get it to facebook? I am still researching rudimentary video options.
OBS handled a few things:
- FB live stream
- choosing and combining video and audio sources and try to fix the audio delay/sync
- put up an intro graphic before I started
- with Touch Portal, let me change scenes (intro, solo, Zoom+Jamulus) remotely
Yes, it not only helps , but is a requirement to get synchronization of all players to listen to the sound from the server, it is impossible otherwise as you don't know how far off you are and as such can't correct.
And yes, it does take some getting used to. But playing now with others using Jamulus for several months the latency and correcting for it is no longer an issue. I play viola and play together mostly with other strings. There is no question for me any more that it works also for acoustic instruments and I expect just as well for singers.
We are back to the normal discussion of rehearsals, interpretation, etc. One thing we have noticed, however, it that this is great training for the ear. As all cues pass only auditively we become much more attuned and sensitive to listening. We are not really missing the visual cues.