-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
2DGEQ: Getting same sized bar width on 32x32 display #3752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
It is easy to test, just resize segment. |
PR looks reasonable, however I'm currently "away from WLED" (holidays) and cannot test. @adrianschroeter please test with segments of different width, and inform us about results. At least the following should be tested:
Also please try a few different numbers of bars (slider), in addition to the standard of 16 bars. |
|
@adrianschroeter are you willing to pursue this PR further? If so, please rebase it for 0_15 branch. |
updated changelog (missing credit)
Update cdata.js to rebuild if package.json changes
usermod support for Adafruit MAX17048 module
return of GPIO16
millis()/1000 rollover after 18h was not handled, truncating to 16bits after division fixes it.
- add "clock" - CPU clock in MHz - add "flash" - flash size in MB Fix for wled#3879
…erator Added fix for wled#3870
Indentation fix
Indentation fix
Compile fix
Esp32 s3 touch fix
- audioreactive always included for S3 & S2
Effect: modified KITT (Scanner)
- fix for wled#3896 - fix WS2815 current - conditional AA setPixelColor()
…d_improvement_new Usermod Updated: Internal Temperature V2
Avoid reconfiguring the device during web server context, which can trigger a yield(). Instead defer the device initialization to loop().
Mpu6050 usermod crash fix
Fix typo in "Battery" usermod (Build Failed)
* fixed a few typo's in comments * fixed 8266 specific warning about 'comparison of integer expressions of different signedness' based on recommendations made by @willmmiles: * make sure that audioSyncPacket is the same size (44bytes) on all platforms * use static buffer for receiving (avoids heap fragmentation) * copy receive buffer to local audioSyncPacket struct - avoids alignment problems * esp32 only: to stay in sync with UDP, Udp.flush() is needed when Udp.parsePacket() is _not_ followed by Udp.read()
softhack007
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the code change is aligned to "common practice" for avoiding inaccuracies of map, we still need confidence by testing with several segment width and "number of bars" settings.
|
|
||
| for (int x=0; x < cols; x++) { | ||
| uint8_t band = map(x, 0, cols-1, 0, NUM_BANDS - 1); | ||
| uint8_t band = map(x, 0, cols, 0, NUM_BANDS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is in line with the common workaround for know inaccuracies of map, by adding 1 to in_max and out_max.
However - as already stated - it would be good to test with common segment sizes before merging.
@adrianschroeter you can simply change the segment size to test your proposed modification.
Add additional clarification as to the original source URL and the specific local patches.
... protected against array overflow due to previous "if (packetSize <= UDPSOUND_MAX_PACKET)"
ESP8266 audioreactive UDP sound sync ported from MoonModules/WLED - receive only
use -D WLED_BOOTUPDELAY=500 in platformio env definition to add 500ms of delay before hardware init.
boot-up delay to fix wifi not starting in some setups use `-D WLED_BOOTUPDELAY=500` (or some other delay you want, in milliseconds) in platformio env definition to add 500ms of delay before hardware init.
before a x=32 (n times of 16) had not equal sized bars, but first was a single pixel and later a bar had 3 pixel width. This solves it to have always 2 pixel sized bars. I have to admit that I did not test with other pixel dimensions.
|
Hi, I finally rebased and tested your suggested segment sizes. Apart from width = 2 it made all sense to me. The 17, 23, 24 had different sized bars, but I think that is expect. width=2 showed only 2 led's to me (not 2x2). However, not sure if this resolution is so useful. |
|
@adrianschroeter thanks for the testing 👍 I still see the PR is targeted at our 'main' branch. Please rebase it for |
|
0_15 merge in new request |
before a x=32 (n times of 16) had not equal sized bars, but first was a single pixel and later a bar had 3 pixel width. This solves it to have always 2 pixel sized bars.
I have to admit that I did not test with other pixel dimensions.