Is LightBeat dead? about lightbeat HOT 8 CLOSED

The project is certainly not abandoned, but I have indeed not developed it any further since 2018.
If some issue would break LightBeat I would fix it, so no worries of it breaking anytime soon.
None of the open issues are critical in any way.

In general, I have a couple of issues with developing LightBeat currently:

1. Java's inability to read System Audio natively. Setting up virtual devices is annoying and should be integrated in the software. If this was built on .NET or a Javascript/Node stack via some Desktop wrapper this wouldn't be an issue and we could just directly read system audio without a hassle. So staying on JavaVM is a big bottleneck here.
2. Plans to monetize the visualisation engine with an Android (and later iOS) App failed a couple of years ago, since I found Android's audio API was far too limited and I wasn't happy with having to use the microphone to get better data. I did actually fully port the engine over to Android and had it running on my device, but the latency was too high for my tastes, so I lost interest in it.
3. I could probably make the visualisation alot more interesting by leveraging the Hue Entertainment API, however besides the official Philips framework there is still no third party (and preferably FOSS) tooling around this API. Switching to Hue Entertainment API would also lower the latency, but might cause issues with Hue bridge emulators and thus reduce compatibility. In any case, I would have to implement the Entertainment protocol myself, which I'm not interested in.
4. Despite LightBeat's public source code, it is actually not open source, but all rights reserved currently. We use the deprecated Philips framework, which means that I can't open source LightBeat due to licensing issues. There are however alternative API's with open source licences I could switch to.
5. I think Swing (our UI framework) is outdated and not fun to work with. There are enterprise tools using Swing (like Jetbrains IDE's), but there are better options out there now, like JavaFX and Compose for Desktop.
6. I'm not using it anymore. I originally built this for me, which drove alot of innovation in making the visualisation more interesting. For motivation, I would either need to be my own client like I was before, or make money off of it.

About being able to use non Hue lights, yes I'm aware that is the case. All we need is a Hue bridge, since that is the API we communicate with. Even if you don't have one, you could set up an emulator like OpenHAB and connect any light system you want with it, as long as OpenHAB offers an integration (and they support a LOT of different systems). I obviously haven't tested those combinations though, so there might be breaking latency issues. The homepage also mentions "Music Visualizer for Philips Hue compatible lights." and in the FAQ under system requirements "It does however require a Philips Hue Bridge to connect to. As long as your lights are compatible with said bridge you should be able to use LightBeat with them."

I am always happy to hear that people are enjoying the visualisation still, so thanks for the kind words!

from lightbeat.

Oooh to all of that and sweet to the project not being dead! :-) Thanks for the response.
As for making money off of LightBeat, until recently; I was going to say its totally possible because the closest thing was Huegasam, a Chrome Ext that costs $5 and doesn't give as cool of a light show. But, the dev is about to release V3 and is going to stop charging. I'd personally still pay you some $ for Lightbeat because it is system level&outside of Chrome AND looks better but; I'm not sure how many people would. :-(

As for an Android app, Apparently Android 10 has enabled screen&sound sharing between apps. Would that fix the latency issues? IDK why it would but, hey, I just saw that it was a thing now and it's how Huegasam for Chrome handles syncing to any sound not coming from a Chrome tab on Windows. So, I thought I'd mention it :-)

Outa curiosity, what network protocol are you using? UDP or TCP? Huegasam is using TCP and the Dev claims that's why the light show is the way it is. It only updates one light per beat and it's noticeably slower then Lightbeat, slower and boring heh! (Like seriously boring, I got used to Hue Sync and it was better with even only 2 bulbs then Huegasam is with 5!)

Also, what are glowing effects? I can't quite figure it out from the tooltips.

So, thanks again SO much for making Lightbeat! :-)

Note about using Lightbeat with Non Hue lights or ANY other app/program made to control Hue bulbs

You probably WILL have some random issues with apps and programs, including Lightbeat. I use the Hue app and Hue Hello and both have a feature or two that don't work right (or at all) with my CMARS bulbs.
----IE: I can't get my CMARS to go white using the color wheel in the Hue app for Android. I have to switch to white controller and do it that way.

As for Lightbeat, I'm having some issues where my CMARS bulbs are not giving me all of the colors I had selected and they were also turning fully off/flashing even though I had all strobe settings off and Min brightness at 1/2. I'm working on narrowing down the issue and it seems to be either related to Fade Time or Glow. My Hue bulbs are fine though. I'm thinking high FT mess up the bulbs. The issue seems to go away when I lower it, but they sometimes work fine with high FT so I'm not sure yet.

Also, one of my 3 CMARS bulbs will just not start responding to LightBeat when I start it. I have to use another app to power cycle the bulb while LightBeat is going to fix it.

Its totally crazy to ask any developer to deal with all of the varieties of Zigbee bulbs out there. So, I'm totally cool with some random glitches. :-)

So ya'll, be ready for some weirdness/minor annoyances if you venture into cheaper Zigbee bulbs. :-)

Besides, it's not like Hue bulbs are perfect in themselves. IE: I can NOT get the purple color that Hue bulbs do when using various music sync apps. I've even tried Hex codes and nope, no go. The same goes really for any fully saturated color with full brightness. sighs Those are the best colors.

from lightbeat.

Back then the most popular non-free music syncing app was Hue Disco, I don't know how the landscape changed since then. They charged 4$ for a visualisation that I personally didn't find very interesting, and apparently had over 100k installs. I don't know if they all paid 4$ of course, but if they did it seems like there is definietly some potential to profit of a Hue visualizer.

I haven't looked yet at Android 10 API features, thanks for letting me know that there are new Audio API's. Will be looking into it.

I know Huegasm which also seemed pretty boring to me. Maybe if all you want is some basic music ambiance it would work fine, but you can also configure LightBeat to give you a more relaxed visualisation if you wish to do so. Of course Huegasm is a web app, so you might prefer that over a Java install.

LightBeat uses the default TCP REST interface, this is what I was hinting at with using the Entertainment API (UDP) to get latency further down, while allowing more effects per second to go through. Pretty sure that Huegasm uses the same API as LightBeat does, so I have no idea why the dev would think that they cannot send more updates. The official docs mention some ridicoulously low numbers on how many commands you can send, but in my testing I realized that I could push far more commands per second than that. In any case there is a slider exposed if your bridge / Zigbee network gets overwhelmed.

Hue Sync on the other hand uses the Entertainment API, which is why they are able to update the lights as rapidly as they do. Personally I found that visualisation to be pretty basic when I tried it out and I still prefered LightBeat, but I might be biased ;)

Glowing just means the light going from high brightness to low and back to where it was. It's an effect that is exposed via the Hue REST interface. I don't know if it's a special thing that only works with Hue bulbs, or if it is something like a macro for the bridge to send multiple ZigBee commands to the light to control the brightness with only one command sent via the bridge REST Api.

When it comes to color accuracy, I personally never really cared about it. Different bulbs have different color gamuts, even when only thinking about Philips Hue lights, and I always thought that properly implementing color translation would be a big hassle for something thats not that important. And even if I did add additional code to translate colors better for different gamuts I couldn't possibly support third party lights this way. I hope you can approximate your colors good enough. What I probably should have added is a color preview in the color picker that sets one light to your selected color, so you know what you will get.

from lightbeat.

I changed the title of the ticket so other people who want to know what the current state of the project is can find the answer to their question here in the issue section :)

I will also leave the ticket open until I update it again.

from lightbeat.

I just read thru this discussion and I am wondering if you are interested in reimplementing this in C# / .NET Framework 5. Meanwhile its greatly supported on various OS, has a good UI framework for Windows, great libraries and also a great Hue API (https://github.com/Q42/Q42.HueApi). Additionally there isn't any really good Hue Music Sync Apps available on the Microsoft Store and as most of the Apps in the MS Store charge around 4$, I am sure this app could do the same.

Lots of the mentioned pains could be resolved by switching and I would love to see this project alive again

from lightbeat.

Thanks for weighing in and sorry for the late reply. I have played with the idea (not for the first time), and it still seems like Q42.HueApi is the only non official FOSS library supporting the Entertainment API across all languages. This would allow the visualisation to get even more fun, at the expense of losing compatibility with Hue emulators which do not support it.

However I'm personally not a big fan of working on multiple programming languages and their development stacks. I would like to finally be able to settle on a language/stack, and I believe Kotlin has won in my mind. When accessing system internals, like system audio, I'll probably be limited most of the time, but the language supports both JS ecosystems and JavaVM and in general is very fun to work with, and other languages bring other trade offs. I do like C#/.NET, but I'll (probably, most likely) be focusing on getting more accustomed to the Kotlin eco system.

from lightbeat.

That's sad to hear, because in my personal opinion the .NET / C# stack is by far superior and will get even more superior in the future. But I respect your opinion and choice, anyway great work on this project. Keep up the good work.

from lightbeat.

Update released, closing this since it doesn't look dead anymore.

from lightbeat.