For clarity, It’s short-short-short-long. (I think that’s what you meant already, I just wanted to make sure.) Check the serial monitor to see what it thinks you pressed.
New zip: 8.9
Has some bugfixes for the select style menu option, a new define for the sabersense prop and some whitespace and comment cleanup.
By my count, everything that needs to be tested is now tested.
I’m investigating one more thing, and once I have fixed that (or decided not to fix it) it will be time for ProffieOS 8.x to go live.
If you have a moment to try it out before that, please do, and report any problems you encounter.
If you don’t test it, and it doesn’t work, then it’s your fault. 
I have a PR submitted to correct this error. As noted check that you’re doing the controls in Serial Monitor if it’s still not working.
You can test in my fork if you like, just click Green Code button and Download ZIP: GitHub - fdarosa2663/ProffieOS at os8-updates
1 Like
re:
I understand what you said above and the points but I’m still seeing a need to run unnecessary volume control defines where the prop should work clean. IMHO we shouldn’t have to do this with the new rotary control setup. I get it’s more responsive and has more and smaller spacing between the clicks (fast scroll?) but there needs to be a stop at the minimum and maximum volume settings in the main OS.
The props can have their specific defines as a backup or alternative, as @Fett263 and @NoSloppy have for theirs, but those are a redundancy that up thru OS 7.15 was not a necessity. Simply being able to quick scroll to min or max volume with a stopping of the excessively overplaying repetitive audio is effective enough to make things perfect.
I suggest looking at and implementing NoSloppy’s solution used in his prop since it’s set to where the “maximum…” and “minimum volume” wav files will not keep playing redundantly stacking up because someone rotated their hilt or prop just a tad too far.
Hahaha, don’t you love it when you get a late-night thought?
With #define KILL_OLD_PLAYERS being a standard inclusion for OS8.x why didn’t it kick in and stop the overplay?
Kill old players would make this worse, if anything.
It clears the sound queue for new sounds to make sure they play, it doesn’t stop new sounds from playing duplicated. If you’ve lots of those events, the sounds will stack up and fill the queue regardless. The only difference that define would make is in when new sounds are played, not how many may be playing.
Thx, seemed worth asking at the time.
- FETT263_MANUAL_BLADE_ID - Retested and now works.
2 Likes
Zip updated to 8.10 differences from 8.9:
- fix for fett263 volume menu (broken by changes in sound queue)
- make sure “voice pack not found” wav file can play (and not crash)
- fix for manual array selection in Fett263 prop
All major features have now been tested, and known bugs have been fixed.
Unless I hear otherwise, this is likely to become the first public 8.x release.
2 Likes
What is the “barrel roll” ?
It simulates rotating the saber around it’s axis, which is useful for testing menus. Rotating around the axis is easy with a saber, but not so easy with a test bench setup.
The command is only available when compiling with ENABLE_DEVELOPER_COMMANDS
1 Like
Much appreciated. I definitely see and hear the difference in how the rotating menu for volume performs in 8.10 that mirrors how it was in 7.15. It plays the min/max volume callouts slower versus in a hyper fashion. The slower playback can still be induced like in 7.15 but it plays the callouts in a slower methodical fashion back to back but is nowhere near as annoying as it was lately.
All else works great on my end but that’s up to others to chime in on also.
For Non-Circular Volume Menu: I still like the idea I had about “hard stops” for the volume where a stoppage to the stacked callouts is ideal. If you hit maximum or minimum volume it only does the callout once in a certain timeframe. As in if you rotate all the way full-right it only reads the callout once for minimum. If you rotate full-left it only plays the callout once for maximum. Overrotated inducement is halted and any stacked playback is not allowed to happen. Then if you go back after for any reason x-amount of time has to have happened so you do have a reminder but not a parade of the same callouts back to back. This may be something to reserve for OS9.
Is Arduino plugin v4 required for 8?
(I figure yes, since it explicitly has fixes for SPI stuff?)
It is not, but it is recommended.
The earlier versions of gcc compiler seems to get confused with some of the code in OS8, and will at times just generate code that doesn’t work. The later gcc versions does better…
1 Like
@ryryog25 yeah, use 4.6.0 like @profezzorn wrote, less issues and it does things better.
What about the Arduino version itself? Some of us still prefer 1.8.19 simply because of the progress bar and ability to put it into DarkMode w some code changes. Functionally I and another haven’t seen any issues doing so.
Is it v2 that doesn’t support carriage returns (makes the bar go onto multiple lines) or vice versa you’re saying?
Dark mode is default I think on v2, unless I misunderstand what you mean.
V1 not being Electron is a pretty solid plus 
As far as needing it for ProffieConfig, I appreciate Arduino splitting things into arduino-cli and providing a frontend in the IDE, but I wish the frontend wasn’t Electron… not that it really matters to me I guess…
1 Like
Yup.
Version 2.2.whatever has the progress bar go
vertically
one
tick
at
a
time.
Annoying as hell. Plus I love DarkMode. People have openly complained in the Arduino group and it’s still not resolved. Never should’ve been brought back IMHO, but that’s a different topic.
I’ll keep v7.15 on v3 in ProffieConfig, since I’ve seen multiple people both here and talking to me directly who find the higher flash usage of v4 to be a fair annoyance without any gain.
But for v8.x, I’ll start making v4 the default then.
All I’ve consistently seen is a mild 3-5% jump in file size and that’s all. The performance is chef’s kiss but I may be biased because Macintosh.
Shutting down for the night. IMHO we should carry this over to DM-Chat or a new topic tomorrow if we wanna keep the thoughts rolling. 
@profezzorn Lemme know your thoughts as far as Arduino 1.8.19 versus 2.2 since it never hurts to listen.
1 Like
I recommend upgrading.
Arduino 1.8.19 should still work, but there is a caveat: on some platforms (I actually don’t remember which) 1.8.19 is not able to install the 4.6.0 plugin. It should be possible to install 2.x, install the 4.6.0 plugin and then keep using 1.8.19 after that though.
Also, at some point will add debugging support, and that will not work with 1.x…