Jamulus
Replies: 7 comments 34 replies
-
Absolutely true. That's one of the reasons why we invested a lot in documentation.
If you develop it continuously, we can add it in some places - but please note that there are also other projects like KOORD; Melomax; WorldJam; which would need to have a place. We do already have the RELATED-PROJECTS file on the website, but I agree that it's a bit hidden. At very first, I'd suggest that you write a KB entry about your project jamulus.live (please remain neutral (it shouldn't e.g sound like an ad) but you can and should of course describe the features. As it's a KB entry, by policy the maintainers should not do a big review. If we do, please remind us of that). Just a note on the project: |
Beta Was this translation helpful? Give feedback.
-
|
Growth is good. The thought of empowering noobs is good. Some questions arise as to the state of the jamulus.live site, and what message its maintainer is trying to send, vs. what the Jamulus developers intentions are, and keep in mind I pose these as a new user. As a new user looking at explorer.jamulus.io, I see a list of servers in a genre, and the players connected to each server. Ping times are subject to the web server serving the page. The one pitfall is the lack of a single pane view of all genres. There are no other indications shown that require a judgement to be made as to the "quality" of the server/connection/occupants. Now I'm looking at jamulus.live. Are other servers labelled UNSTABLE as well? What message does that UNSTABLE label send to a new user? At the bottom of the page, there's an expandable section called Block bots.
As both sites (explorer.jamulus.io and jamulus.live) currently stand, there is confusion caused by the difference in information provided, and the arbitrary labelling by one site thats not officially sanctioned. I submit that if the Jamulus developers want to include a link to that third party site, it should also include a caveat emptor stating the site isn't a source of truth, arbitrarily labels servers UNSTABLE with no explanation, also has bots that connect to occupied servers, and is not officially a part of Jamulus. Information is empowerment. |
Beta Was this translation helpful? Give feedback.
-
|
As explained previously, CBVB blocks by IP, often without warning or apparent motive. I don't want that to lead to the perception that Jamulus is unreliable, which is exactly what it does. I've spoken to many people who have experienced this anti-social behavior. I've been quite open about this labelling. Why would a new user need to "address it" ? Is it, instead, a personal frustration of yours, rather than of a new user? I'm protecting new users. What are you doing? You're making up Hater-aid. Misinformation and flim-flam are corrosive to community growth so stop it. (I'm boggled by just how abusive and think-they're-clever these haters are: deeply wedded to a dark vision of operator power that degrades user experiences. Should I start a new discussion about this?) |
Beta Was this translation helpful? Give feedback.
-
|
I might be reaching two years of high uptime, and continue adding features. I see the case for introducing WorldJam in our core documentation. Those other projects won't enhance user experiences for the platform they've just installed, so I'd say they don't meet the same bar. (Could be mistaken.) Really I think we do cover installing the bits reasonably well. But near the end of that process, we should consider introducing every project that might enhance the user's experience, especially the noob's experience. I could prepare a KB, if you think it would bring me closer to this goal. I do write neutral information for a living. ;) You'll still end up with a whitepaper about lots of small techniques I use to improve localization and navigation. I generally don't find this work interesting. I want to deliver the features, rather than write about them. (I have a career in which I write about features, and a hobby in which I deliver them.) I can see how clarity about how the project works might gain me some support, and maybe even get some eyes on my project for improvements. |
Beta Was this translation helpful? Give feedback.
-
That's unfortunate, but an issue of the server owner.
Please don't. The server owner is the only one who can/should explain their policy. Please remain professional and don't get personal.
Yes, that's great! We can always link it from the main documentation.
If it's not interesting, there's no need to discuss it. You can and should focus on features and social aspects. |
Beta Was this translation helpful? Give feedback.
-
|
Related, when I navigate to http://jamulus.io, I don't see a link to http://explorer.jamulus.io. It seems like that should be on the home page with a big banner that says "see public servers with musicians on them right now!" or similar. https://jamulus.live/ could be another resource for a live view. WRT newcomers, I suspect that (post-Covid) almost all are brought to Jamulus by another user. Not a lot of musicians will be seeking out a tool like Jamulus these days. But it can still serve as a great tool for open jams, as well as band rehearsals when a group is separated by distance or doesn't have a dedicated rehearsal space. I wonder if the home page should say more about the primary use cases for Jamulus, such that those keywords are picked up by Google and other search engines? As an example, my Remote Band Rehearsals doc (linked from the Tips & Tricks section of http://jamulus.io) has a Quick Start section at the top, listing use cases and the appropriate sections of the doc to read. |
Beta Was this translation helpful? Give feedback.
-
|
I had thought I wanted one sentence with a link inline in the installation instructions. But chrisrimple's point about the front page makes a lot more sense, because the pre-install people will see it. This would give them a more concrete understanding that there's an active network of people, which I believe remains our still-hidden ace. So I'd like to join the marketing team. If a pre-install user saw it on the front page, I think that would improve their likelihood to even try installing the bits. Then, inline in the docs, I want to say something about a sentence long about "following your friends" and "hearing jams in a browser". Also, there's a good idea about replacing the front page large icon with an image of the app running, because it shows people more clearly what they can get. I have considered integration with the Jamulus app, and would welcome a place on the UI, which perhaps only entails sharing the URL's DNS control with the team somehow. The other integration I considered is that on Windows, you can let a browser call an executable, which possibly lets you choose the server from the webpage. That seems to be what noobs want it to do. |
Beta Was this translation helpful? Give feedback.
-
That's what I thought of. Provide a "social" button/box and let the user select multiple sites. We'd also include a link to Jamulus Explorer. |
Beta Was this translation helpful? Give feedback.
-
|
There's a Jamulus icon in the upper-left corner of the user interface. Just make it clickable to launch a URL.
Maybe the URL is settable. Seems like people could use that in many useful ways. Click the Jamulus icon, easy peasy. Presumably it defaults to a useful URL, such as a palette page where you choose a real-time service provider. |
Beta Was this translation helpful? Give feedback.
-
|
Hmm. But I'm not sure how "obvious" it is to know that clicking on it does something. |
Beta Was this translation helpful? Give feedback.
-
|
I'm figuring that sweet finger pointer mouse cursor would appear every time I mouse over. If I didn't notice at first, I would eventually. But we'd need that sweet pointer mouse cursor. |
Beta Was this translation helpful? Give feedback.
-
You mean they blocked you because you did something you weren't supposed to. And you weren't even a new user. You were expected to know better, and still you got yourself blocked.
You mean you don't want your sites users to feel that servers they connect to, that are visible on your site, are unreliable as that would reflect badly on your site. This isn't about Jamulus on the whole, if it were you'd have a LOT of other servers labelled as UNSTABLE because they too firewall. Just because a server operator utilizes tools available to them, doesn't make them anti-social. It makes them responsible admins, who are protecting their users from things like unwanted clients and bots, and protecting the resources they pay for. Your approach is anti-social as you believe you're entitled to a resource that you don't actually have entitlement to. No consideration for the users or the server is given. Are servers and their admins just "product" to you?
No, you haven't. You did something contrary to what the CBVB community wanted, and you got banned for it. That's on you. Lots of non-CBVB servers utilize firewalling. The only ones you mark UNSTABLE are the CBVB ones that banned you personally. So you've displayed both an anti-social behaviour AND attempted to misinform. It's fair that the Jamulus developers should be aware of this situation that you gloss over everytime you're directly asked about it.
"I installed Jamulus yesterday and started a new server and firewalled your bots off. You labelled my server UNSTABLE on your site. Your site doesn't explain why, or what remedy will give you cause to remove that label, or even a contact." Since I don't rely on your site for anything, your arbitrary judgements of my servers is moot. There is no frustration. New users to my servers get help when asked, information provided where queried, and are not blocked until/unless they do something that deserves an action to be removed. They are welcome to play. I ask or tell them about https://explorer.jamulus.io, explaining it is a source of truth for servers and those occupying them. I also ensure they're aware there are bots on the network and what they do, and my servers block them. They are thankful that I block your bots because they're not comfortable with sharing what they do on the server with anyone outside it.
From what?
The "hate" and "misinformation" you allege I'm creating began with your actions, not mine.
I'm not surprised you're boggled, you seem to have a notion that just because a server exists you have some right to exploit it for your sites needs, opposition be damned. You need servers to connect to else your site is useless. In the beginning your site had utility, its most useful feature, that single pane of glass view of who's on. I advocated use of your site based on that. When you implemented that Ear bot, you didn't ask me, as a server operator or my users, if they were ok with this new feature. You potentially have something really good, but you're blowing it by not working with those that provide the very thing you need, servers and those that run them. Unfortunately I fear nothing I'm saying here will give you reason to reconsider your approach. Your rationalization justifies the behaviour and attitude you display, and that will continue to divide and drive users off the publicly visible servers, as its already begun to. I'm all for growth and improving user experiences, but not at the expense of established users and servers/operators providing the resource we all need to make the Jamulus client so joyful to use. |
Beta Was this translation helpful? Give feedback.
-
|
@mcfnord I'd rather you answer here, for the record. That way everyone will know. You should detail how you're monitoring to gather the information that you make your labelling decisions on. Transparency is the best option that serves Jamulus users, new and old. |
Beta Was this translation helpful? Give feedback.
-
|
I've described the pattern. Are you unfamiliar with it? Have I left anything out? I interviewed a victim of apparent IP banning last month. She was hurt and upset. If you can't speak with me verbally, I don't wish to speak with you here. But I will continue logging the record of abuse in this thread for everyone if you prefer. |
Beta Was this translation helpful? Give feedback.
-
|
Requests for information are not abuse. However since you clearly do not wish to be transparent about your processes/policies/etc, I will leave this alone. |
Beta Was this translation helpful? Give feedback.
-
|
I've answered all of your questions with specific information and evidence. Ending connections to humans will result in this label. Each time evidence reaches me that it still occurs, we might think of it as a 6 month clock resetting. You've disclosed that it's a policy that appears to be cherished, but let me know if the policy changes. |
Beta Was this translation helpful? Give feedback.
-
|
Transparency and this record are key themes in these comments, and apparently key concerns. This comment continues my legacy of providing policy transparency with excoriating force.
I find it hard to believe the claim that many servers routinely block users by IP. Instead, I think you might be among a small group that practices this. This issue arose when I labeled CBVB servers as UNSTABLE to help users better understand the experience of being blocked by IP. I spoke with individuals who expressed discomfort and confusion due to this practice. A few things have happened since then:
In light of these developments, I've removed the "UNSTABLE" label from CBVB servers. Instead, I've adjusted CBVB rendering to be regional, with a range of 2,000 kilometers. Evidence suggests that users farther from those servers are more likely to experience IP blocking. Maybe those closer to the server do have more reliable experiences. This change protects my users from adverse IP block experiences and may also reflect the strong preference on those servers against high latency connections. I still firmly believe that blocking by IP is a rare, unkind, and unwise practice that hinders the adoption of our platform by degrading the mesh utility of our geographically distributed servers. |
Beta Was this translation helpful? Give feedback.
-
|
Putting aside all the history, etc. and thinking about it purely from a new user perspective, I wonder if:
In effect, it's the WorldJam without video or streaming to YouTube. The control of "if and when" to broadcast is left in the hands of individual server operators. Servers that are broadcasting can state so in their Welcome Message, so musicians on that server are not surprised. I can imagine that there are many groups (open jams, barbershop choruses, etc.) that are regularly using Jamulus and would welcome an audience, as well as a way to attract future participants. And those that do not don't have to worry about blocking bots, etc. |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/dtinth/headless-jamulus-to-icecast-linux-streamer/blob/main/README.md @dtinth has provided a pretty trivial method of achieving broadcasting with no changes needed (I've questioned why the patch to the client is necessary - I think I don't see any need for a centralised site - IceCast servers can register with https://dir.xiph.org/ already. |
Beta Was this translation helpful? Give feedback.
-
|
@pljones Looking at the README, it appears that we'd just need a dedicated Icecast server for Jamulus, but I'm unclear if multiple Jamulus streams could be sent to a single Icecast server, so they'd all show up in the https://dir.xiph.org/ directory? I think that requiring every Jamulus server host to have their own Icecast server would drastically limit participation. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, dtinth/headless-jamulus-to-icecast-linux-streamer is no longer being used, nor is it being maintained anymore. Now my servers are using https://github.com/dtinth/jamulus-lounge for the web interface, which is what I now recommend. |
Beta Was this translation helpful? Give feedback.
-
|
I'd say the opposite were true. It's better if the Jamulus Server operator has full control of how they appear in the Xiph directory, in the same way as it's better for a Jamulus Server operator to have control over the details shown when the register in a Jamulus Directory. But the main point is that the stream out from the server would be mixed audio, exactly like goes to a Jamulus Client. Unless there were a way to control that mix (exactly like a Jamulus Client can), then the audio would - potentially - sound worse when fed direct from the server. It would introduce complexity (i.e. if it weren't a Jamulus Client connection with input and output feeds, new ways of dealing with the new client interface would be needed -- and it would, indeed, be a new client interface). So it simply makes more sense just to use the existing Jamulus Client interface. (Either the actual Client or a replacement.) |
Beta Was this translation helpful? Give feedback.
-
|
I have anecdotal evidence that browser streaming is used by die-hard community members (like me, while I ride my bike), family and friends of jam participants (who get a link as the jam starts), and a few people who don't have Jamulus installed, just want to listen ("Jamulus Radio"). I limit ten-second snippets to max 2 active, and limit to just one "floating lobby" because from the new user's perspective, it's highly important to have a reasonable sample, but less important that all the possible servers are ready to stream audio. I would like to revisit the idea of a server streaming metadata by default. In particular, I'd like every server to share https links that are shared in a chat message, and also share a summary of connection audio levels (silent vs. not silent). I translate https links into an artist and song title, or indicate that a Jitsi or Meet video component is active. The https is low-weight metadata that indicates a lot about an active group's current state. Knowing a group is silent is another useful tip. |
Beta Was this translation helpful? Give feedback.
-
|
Here in Thailand we have a Discord server, Thailand Jamulus User Group. Currently, there are about 300 members in the group. Just want to share what kind of worked for us.
Some more observations:
|
Beta Was this translation helpful? Give feedback.
-
|
@dtinth Thanks for the additional detail and screenshots. In the Discord view, is there an indicator for servers that are running jamulus-lounge? Is there a way to click to open a browser to the jamulus-lounge view for that server? @pljones makes a good point that broadcast/no broadcast should remain in the control of the server owner, perhaps without the need for a server to go "private" or block bots. For example, there could be a server own wanting to hold "open jams" that anyone can join, but without wanting those broadcast to non-Jamulus users. I wonder if it would be possible to incorporate jamulus-lounge to core Jamulus such that it could be enabled/disabled with a switch in the jamulus.ini file? Does jamulus-lounge have additional Linux/etc. configuration needs beyond the standards to run Jamulus? The next step, having given that capability to server owners, would be to provide a "single pane" view of servers with Broadcast = True. Perhaps that's a modified version of @mcfnord's solution, running on a Jamulus Team-maintained server (similar to explore.jamulus.io)? |
Beta Was this translation helpful? Give feedback.
-
|
Let's sew all the projects into one deliverable called Jamulox Mega. Maybe streaming onto big Discord servers is our growth plan. I originally rolled out two docking instances of jamulus-lounge. We can give any new server on the public network a lounge. I guess we can even give a lounge to an unlisted server. It was not designed for this but I do it. Therefore: One person could provide lounges that anyone can get for as long as they want. Eventually I decided two docking lounges is overkill. When I switched to one, I noticed a market: some people adopted it and used it, and that made it increasingly scarce to everyone else. I want us to evaluate the role of sound to a musician, perhaps as a unique case. We are creating to be heard. Even if we play alone, we are creating to be heard. The docking lounge is listen-only. What is the worst case if it's heard by non-Jamulus users? We've adopted the awareness that someone's listening in the lobby. If there's an objection to a hearing bot, it's probably among specific people, and the operator probably isn't even present. I don't think user-centric policy is so outlandish, and don't think operator-centric policy is so enlightened. But I also don't think a listener with no microphone is anything new, period. A distinction with no difference. Listener is listener is listener. I know a few people sincerely object to bot as a category, and feel uniquely uncomfortable around them. I also feel that's a little odd. Listeners can't speak but a lot of connections can't speak into a microphone. Listeners on any stack seem the same as any other to me, especially if they can type in chat and indicate they're present and engaged. |
Beta Was this translation helpful? Give feedback.
-
Yes, that is a “Listen” link in
In Thailand, there are about four servers that run 24/7, only two of them have lounge set up. Some people prefer to join the ones with a lounge, some people prefer otherwise.
It runs an entirely separate client (written in Go) and the lounge part requires Node.js. The default distribution uses Docker. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @rdica on this. The dot-live product editorializes and pushes an "opinion" about servers, their connections, and operators, no? (its author certainly does). There is no place in core Jamulus for a reference to this and it should certainly not be lumped together with explorer or worldjam. Further, and maybe more important, dot-live does not necessarily help newbies in their quest -- listening in on other people's rooms through a third party like dot-live is both disturbing and deceitfully surreptitious; not to mention it doesn't provide any help or guidance to becoming a Jamulus user beyond describing the most obscure way to join a server via the server connect dialog's manual address field. However, if the community thinks that a "third-party" list of applications that are based on Jamulus or that operate within the ecosystem makes sense (like Koord et al), then obviously dot-live could live on that list with a reasonable description. @mcfnord - I will say 'thanks', however, for including the block IP's on the dot-live website. However, suggesting that operators add 'priv' to their server names to avoid being bot-ted is a bit self-serving and not in the spirit of the Jamulus community in my opinion. I'm not sure you fully appreciate why server operators dislike this. |
Beta Was this translation helpful? Give feedback.
-
|
People commonly include 'private' in their server name, and I piggyback on this convention. It is just one of 3 opt-out techniques, with 2 more being planned. You claim the dot-live website does not work for new users. I see about 100 daily users, including noobs. Why do people regularly return to a website that doesn't help them? |
Beta Was this translation helpful? Give feedback.
-
|
When people use 'private' in the server name it's because they don't want anyone barging in, not just a bot. If I'm looking for people to jam with and I see a server with 'priv' or 'private' in its name I'll automatically rule it out as I'll assume they don't want random people joining. And I'm willing to bet most people would take it that way. If I have to spin up a server with 'priv' in its name to avoid bots it's going to be a pretty lonely jam. It should be opt-in and not opt-out. For what it's worth, the thought of there being a bot popping in and recording what we're doing or saying bothers me. Yes, I know, it's public and blah blah, but a single person joining is that, a single person. Or three, or ten - but I can see each one individually and interact with them. A bot broadcasting a recording is like suddenly having a potential crowd of strangers eavesdropping. As a server operator, I shouldn't have to do anything to opt out. Edit: I would find something like 'no-bots' in the server name acceptable to opt out if it has to be that way. It both bars bots and tells potential clients that there won't be bots listening in. It would have to be clearly documented though. |
Beta Was this translation helpful? Give feedback.
-
|
The only servers actually putting the word priv or private in their server names are temporary and transient in nature. None of the permanent servers use the word, for obvious reasons. With the limited number of characters permitted in server name, I submit that it'd be better if there was something in the welcome message that could be parsed as there are more characters permitted in that. |
Beta Was this translation helpful? Give feedback.
-
|
Lobby only streams, and does not record. (The 3 fixed lobbies can record on their 3 servers in Thailand and Brazil.) I have a plan for bringing recording back with a proper REC icon and other indications/controls. The problem with recording was that some loved it, others hated it. Now that it's stream-only, groups use lobby to reach their usual group when they're on the road, or they give the link to family and friends to listen in. The lobby indicates how many are listening, and chat works so you can interact with them. Since some people want to use the floating lobby, it means others won't see it, because there's just one. I've seen this work well as more have adopted it. For example, in 12 hours, Marsha will click Listen on Studio C and send the link to her daughter and friends who will listen to her jazz set there. There is a bot policy welcome message standard being designed, though I prefer a per-user policy, and have designed one. A while ago, drummer Timmerman added PRIV to his server name. I approached him and offered to blocklist his server from all bots. He accepted this plan and no longer needs to add PRIV. Proactive work like this might not be opaque and surreptitious, but I'm trying! (Ghoulish laughter.) The project is open source, so all the source code is available, and I occasionally receive and merge pull requests. The goals of Jamulus core vs dot-live differ. Core prioritizes stability and consistency, while dot-live prioritizes real-time information value. Both are very valuable philosophies that highly compliment each other! It's still kernel vs. user space and that's a useful line to maintain. |
Beta Was this translation helpful? Give feedback.
-
This is my understanding also. |
Beta Was this translation helpful? Give feedback.
-
I believe we should introduce Jamulus.Live in our core documentation as a strategic step to increase the percentage of new users who continue using the platform after their initial experiences.
Newcomers often encounter technical difficulties when they first connect, but they also struggle to discover and operate within the local musician landscape. Many new users are unaware there even is a public network. I believe we are technical leaders for unparalleled stability, but we are also the largest active public community of live musicians in the world. Communicating more about opportunities on this public network is a strategic growth opportunity, because there's a narrow window of time where new users either become regular participants, or drop off. By providing tools and information to navigate this community, we can guide users towards more positive first experiences. Many appear with the more narrow goal of jamming with a particular friend, but Steve Jobs said users don't know what they want until we show them. It should be our aim to increase the likelihood of successful collaboration with strangers during this evaluation period.
Of all the people we could reach out to, newcomers have the most potential to ultimately become routine users. They already have the necessary hardware and software running. They don't yet know what to think of the platform. Imagine the long-term impact if new users become 50% more likely to continue using the platform.
Beta Was this translation helpful? Give feedback.
All reactions