Who is using PulseMesh this year in Australia ?

I've used it a bit in my own display testing, but haven't advertised it at all. It works reasonably well. Not perfect, like initial startup/sync takes a while, and there's been a few instances where it just didn't play and I had to close it and restart it (using the web player). But when it works, it seems to work very well with minimal difference to my outdoor speaker.
 
Like @B4IGO ive set it up and been quite useful in testing my display without carrying a small FM radio around.

As for publicly advertising it, I’m not sure it would be better that what I have now. Most people for my display come on foot and listen to the speakers I have, or via car and either roll down the windows or tune in via my FM transmitter. Plus it needs it adds an extra step or needing to scan a code.

I can see it being super useful where neighbours don’t like outdoor speakers etc and each visitor brings they own audio.

very impressive tech and glad someone figured it out. I can see it being very useful in public displays
 
Would this still introduce various delays per person? I noticed last night whilst talking to visitors that I could hear 3x different time delays of my audio from different cars near me
 
Would this still introduce various delays per person? I noticed last night whilst talking to visitors that I could hear 3x different time delays of my audio from different cars near me
Every streamer would have their own delay, the concept here being similar to multisync on FPP - each app has a copy of the music for and is being told where in the file it'd up to.
That sync packet will take a finite time to reach the user, depending on network latency, in the order of a few tens to hundreds of milliseconds.
It's possible with accurate time synchronisation to have that accounted for, to a certain degree, but whether that's implemented or not it's a different story.
 
I've been using it since about halfway through December and it's proven really rock solid for me. Plus you get some viewer stats, which is always nice.
 
I've used it a bit in my own display testing, but haven't advertised it at all. It works reasonably well. Not perfect, like initial startup/sync takes a while, and there's been a few instances where it just didn't play and I had to close it and restart it (using the web player). But when it works, it seems to work very well with minimal difference to my outdoor speaker.
I'm the same. This is my first year, so wanted to embrace the technology. It is really good & clear once it connects. Definitely will use it next year & will advertise that my display exists. This year was by word of mouth & had quite a few people stop by, some came every night, some stayed for the 2 hour no repeat show!
 
I to had a play with it during set
it up and testing however I did not use it. I even had the QR code display on my P4 matrix however and found that it worked quite well but I decided not to use it as I I was a little bit concerned about how copyright would work with it.
 
I'm going to use it for 2025 Christmas after I upgrade to the latest FPP 8.4 and make sure all my controllers have the latest updates :)
 
Hey all. I'm Bob Kazan, the creator of PulseMesh. Just wanted to jump in here and mention that I'm happy to answer any questions or take any feedback.

One of the common challenges for use of PulseMesh in Australia in particular has been longer than idea time for the app to start up and sync. This is due to the fact that currently all of the infrastructure for PulseMesh is located in the US and the latency measurements between the two countries are quite high due to the geographic distance. I have plans to add a regional deployment in Melbourne or Sydney prior to next season which should make startup much faster. That said, everything should still work correctly in the meantime, this is really just a matter of improving the app startup time

That sync packet will take a finite time to reach the user, depending on network latency, in the order of a few tens to hundreds of milliseconds.
It's possible with accurate time synchronisation to have that accounted for, to a certain degree, but whether that's implemented or not it's a different story.
PulseMesh does indeed account for the (variable) latency introduced by the time taken for messages to reach the client device. The delay of each message is calculated and used to correctly set an offset on the audio playback. Without this compensation the synchronization results would be quite poor.

Again, feel free to send me any questions or feedback, either here or via the PulseMesh site.
 
Hi Bob,

We have been discussing this in the chat a bit, and a primary point of concern is pricing going forwards.

There was a post quoted that mentioned maintaining the current feature set as a free tier, with a "reasonable" simultaneous stream limit. and then a paid tier for more features/connections.

Whats your view of "reasonable" ?
 
Hi Bob,

We have been discussing this in the chat a bit, and a primary point of concern is pricing going forwards.

There was a post quoted that mentioned maintaining the current feature set as a free tier, with a "reasonable" simultaneous stream limit. and then a paid tier for more features/connections.

Whats your view of "reasonable" ?
Yes, I was very happy to announce that I plan to keep all the feature of PulseMesh that exist today free indefinitely to support the hobby. Of course this is not free for me to do, with the costs of cloud compute, licensing, etc, hence the introduction of a paid option with a bunch of new features. I don't have final pricing for the paid option, but I expect it to be similar to the cost of a 100 count strand of bullet pixels, per year.

As to what is reasonable - I'm looking at somewhere between 4 - 6 simultaneous connections with the free option but I still need to dig further into the data from this season to ensure that the majority of residential use cases didn't exceed this at any point.
 
Back
Top