search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
37 stars 8 forks source link

[Feature]: Add music loop toggle to music navigation panel in web interface #383

Open nomakewan opened 1 week ago

nomakewan commented 1 week ago

What would you like to add in terms of software changes?

Would it be possible to add a toggle for music loop one/play all to the web interface? It would be nice to have since at present that can only be controlled via the wand menu.

Would this request involve any specific hardware?

ESP32 Wifi Module/Attenuator

Homework Completed

DustinGrau commented 1 week ago

Yeah, I think we can squeeze in an API call that would set the flag. And make it part of the audio playback screen.

DustinGrau commented 1 week ago

This ranks up there with the goal to consolidate some of the API calls as we have a W_MUSIC_TRACK_LOOP_TOGGLE but no such A_MUSIC_TRACK_LOOP_TOGGLE for the attenuator. Just another example of why we should have a clear and consistent list of actions which the pack understands, regardless of who sent it. If there's an effort to scan the code for sound files (based on their enum names) we should do the same for the API calls and see which ones have been rendered obsolete so we can remove them, and then possibly combine the 2 lists.

nomakewan commented 1 week ago

I've got a script that does that for sound files yeah. I'll adapt it for the API calls too, good idea.

DustinGrau commented 1 week ago

BTW, I feel that reorg should probably wait until after the 6.0 release just because it could seriously muck things up. Therefore, this could wait a bit longer since it seems like more of a convenience feature than a bug fix.

DustinGrau commented 1 week ago

Screw it, I'm working to add some more API calls now, and we'll sort through them later once they are in there and working. This has some experimental support for forcing the lockout (button smash) state, just like we allow for the manual venting. Not sure if it will have the intended effect, but trivial to add with the other API.

nomakewan commented 1 week ago

Only issue with the current implementation is that it's not good from an end-user perspective. While Mute/Unmute was okay because you could literally hear whether it was active for yourself, loop/unloop is not good because there is no visual way for a user to know whether it is set to loop or not, and you won't be able to find out until the currently-playing song actually ends, which can lead to frustration.

There should be some sort of visual indicator. Whether that's some sort of icon next to or above the button, or changing the button to a toggle switch like we use for bools in the Settings pages, not sure.

The button mash stuff does work but I've already found several issues, only one of which was actually caused by this latest push, the rest of which were issues well before but since I didn't have a full setup I couldn't test. The only new issue is that you shouldn't be able to cancel unless the button mash state is actually active (and likewise, you shouldn't be able to trigger mash if it's already triggered), because right now you can spam the Cancel and Mash buttons.

I'll work through the bugs. If you can spitball an idea for the loop/unloop I'm all ears. :)

DustinGrau commented 1 week ago

It's not done yet. I just did some of the work at my desk, then moved to the shop to test. Already finding lots of bugs. I may hide the UI controls but keep the API until I can deal with the UX.

DustinGrau commented 1 week ago

Yup, we have 2 problems with the audio system. There's no way to get the status of the mute toggle, and likewise no way to know when the loop is toggled on or off for the track. We need either a new API that can tell us each state or we combine several audio states into a new object and pass that on demand. I'd opt for the latter which could refresh the volume levels, track, etc. just so we can make 1 call and be done with it.

Edit: I like the idea of it being a toggle input, but again we'd just need to have a way to know what the state is so we can show it appropriately.

The lockout stuff also is broke as hell. While the API's work perfectly fine to trigger the pack events, they're not doing the same as what the wand does despite calling the same logic. Either I'm missing something (perhaps due to not having the wand powered up) or it's just dependent on other factors I've missed. I'd like to get the functionality in there eventually but for now will just comment out the UI elements so they're not usable.