ProffieOS 7.7 Beta (done)

Is it possible that something changed wrt file management? I upgraded a hilt from 6.7 to 7.4. I sudendly started getting font error (the OLED was great help displaying it). But didn’t saw anything wrong. So I got into the serial monitor, and stated that there was a problem with preon files, that one was missing. It’s just an upgraded font (JuanSith’s ObiTPM), and he had improved the preon01.wav, thus I renamed the old as preon1.old.wav and put the new one. This created a problem apparently that was not present on 6.7.

It’s likely seeing up to the first dot, and not caring anymore about file extension that may follow because we’ve already got a problem.
I would’ve probably named it preon01OLD.wav, which is an actual invalid file name that will be ignored, yet stay in an alphabetical list next to where it belongs (as opposed to OLDpreon01.wav, which would end up before on.wav.)

1 Like

Good to know why. But was also reporting the deviation wrt 6.7.Those little things should I report or deviations on things that are invalid anyways should not be reported?

I don’t know, but I had to look up “wrt” once I realized it’s not a typo. :crazy_face:

I’d say reporting anything you feel is reportable is good.

There has been some changes in this code to support alt sounds and subsubdirs.
I think this particular case is a bit weird and unusual, so I don’t think I’m going to try to fix it.
However, if you find an existing font that works with 6.x but doesn’t work with 7.x (without any file renames.) then please let me know and I will definitely do something about it.

1 Like

Style editor 7.x beta:

1 Like

Hmm…

There are 181 bullet points in the top post.
There are 22 “tested by” in the top post.
It’s been 52 days since the top post was posted.

If the current rate keeps up, Proffie OS 7.x will be released in (181 - 22)*52/22 = 375 days.

Now I’ve been writing documentation and working on the style editor, so things should speed up a bit once I start working on testing, but still, it would be nice to have more testing help.

I’ve tested ChargingStylePtr - works great. :+1:

When I use BOOT_VOLUME 100 I get ridiculously low volume. May be I’m using it wrong? I’m also struggling with a KR board that refuses to read SDs. But that’s probably not OS 7.

It should be the same as if you set VOLUME to 100. Except of course that if you use BOOT_VOLUME you can increase the volume afterwards (assuming VOLUME is higher than BOOT_VOLUME.)

Wait, if I use #define VOLUME 1500 I should set #define BOOT_VOLUME 1500 to get the same volume? I had read it was 0-100%.

Well, if you want 100% volume on boot, then just don’t set BOOT_VOLUME at all, but yes, BOOT_VOLUME has the same range as VOLUME, it’s not a percentage. Where did you read that?

I don’t know. I guess the example of using 100.
On a totally unrelated note, I’m struggling with a KR v2.2 that can’t read any SD card. BUT when I start it up with the USB, it can. Is this a 7.4 Beta issue or should I go the the “can’t read SD card” thread?

works as expected

Just did a little testing with BOOT_VOLUME, and it does indeed get over-ridden once you adjust the volume on the buttons and then reboot. (The documentation says this might happen).

However if it works on the same scale as volume, and adjusting the volume on the buttons goes up or down in 10 percent increments, does that mean when we turn up the volume, it might not reach the full volume in the config if it isn’t a 10 percent multiple of the boot volume?

No biggie I guess - just curious.

Also, although nit-picky, since VOLUME actually defines the highest volume you can reach via buttons or web usb without loading a new config, might it not be more accurate to describe VOLUME as MAXIMUM_VOLUME, and BOOT_VOLUME as DEFAULT_VOLUME.

Again, just bouncing thoughts. Hope you don’t mind :slight_smile:

Been doing a little more testing. Has something changed with clash sensitivity?

Normally I’ve always run it 3.9, but when I load OS-7.4 onto my test hilt, clashes are much harder to trigger, to the point where I can’t actually do it and only get perhaps one clash every half dozen attempts at bashing the hilt. I’ve tried dropping to 2.2 but it doesn’t seem to make much, if any, difference.

But if I go back to OS-6.8, clash is fine at 3.9.

Prop is the same subtly modded SA22C that I always use. Config is the same. (It includes BOOT_VOLUME, but I think 6.8 ignores that?).

Any thoughts?


Update; Tried 7.1 and it’s the same, i.e. difficult to clash.
The weird thing is I’ve used 7.x on some other installs and as far as I know it’s been fine. (All been sent out now so can’t test them further). The only difference is my test hilt uses a Proffie v1 board rather than 2.2. Could that be relevant?

Config is here:

All boot volume does is set a level at boot, that’s it. After that it’s done and normal volume level/control is in effect.

The documentation says it “probably” will happen, and it’s logical that it does.
Maybe it should just say “If #define SAVE_VOLUME is active (or SAVE_STATE since it encompasses SAVE_VOLUME), BOOT_VOLUME wil be overridden by your saved value.”

1 Like

I’m trying to test Blade Present and Blade ID, but I get loosing the serial monitor connection. It does opens, but after 8 to 12 lines, it just won’t show anything else. But I won’t get the serial disconnect message on the console. If I close it down and start it again, sends the previous commands minus the first character. Should I deinstall zadig and go with the new driver?
Between the SD issue and this I’m not able to help with the Beta as I hoped.

I got the “Dir not found” in the OLED.

Obviously used this section, plus parameters.

I want to test these but the serial monitor keeps dropping.

Now I’m getting no hum, and not clashes, even at G 1.0. But I can get the blast with AUX.