ProffieOS 7.7 Beta (done)

Possibly, but adding new effect enums is free[1], adding new sound effects is not, so it’s not an automatic thing.

[1] Does not use any more flash memory.

test:
I’m seeing a 40 byte increase adding quote to effect.h 260840->206880
Adding basic use to props/saber.h as well 207056
Would bring the total additional to 216 bytes.
And it should just be an equal trade off if using a custom prop, as they wouldn’t need the declaration anymore.

40 bytes is pretty inconsequential, 216 is enough to matter, but it’s not a lot.
Do we think “quote” is something that most props need/want? If so, I’m ok with adding it.

1 Like

I can only speak for myself, who uses quote in my own prop for a while now. Fett263’s prop does and is bringing more to the table with EFFECT_QUOTE now in OS7.
It was always a trade off before using force for quotes. I think the public has become accustomed to it and feel it’s a standard available feature of ProffieOS already.
This would just make it actually official, and bring the quote feature to the default prop.

1 Like

Just as an FYI.
Once I reach 100% completion on the ProffieOS 7.x documentation, then I’ll be moving ProffieOS 7.x from Alpha to Beta. That means creating a new branch and zip files. From there on, any new features will default to go into ProffieOS 8.x. Obviously it’s still possible to add new features into 7.x after we go to Beta, but we’ll need a good reason for it.

!! Isn’t that going to take years? lol.
Oh, you mean just the OS7 additions I guess.

Yes, and my bar for “documented” is pretty low as well. :slight_smile:
As long as every feature in 7.x has a few lines of text written about it somewhere, that’s all I need… :slight_smile:

The documentation top post now has links for every new feature in 7.x.
Doesn’t mean that the documentation is fantastic, but at least there is something…

That means that I plan to move from alpha to beta very soon, maybe tonight if I have the time.

It also means that it’s time to get serious about testing. The more people help with testing, the sooner we can move from beta to full release.

1 Like

On board. Thus far, all has seemed to go very well. Will report anything awry.

Ok I found a thing, might be a known “issue”, but I haven’t heard of it, so I report:

I wanted short silence for bgnlock sounds, since omitting it would use a clash.wav (undesired).

If a bgnXXX file is 11ms or less, it causes silence until lock ends.
No crash, just no lock sound, and no hum. Smoothswings are still playing as are accent swings and stabs.

Increasing the silence wav file to 12ms and up work fine.
Yes, it’s an unusual condition, but I’m not likely the only one to have used silence in these wav files before. Maybe having effect sound files that short is something that could just have “rule” against as far as system requirements?
“16bit 44.1etc…and should not be less than 12ms long?”
Or… is it something that should be fixed.

1 Like

It makes sense actually.
ProffieOS tends to do things like:

player->Play(file);
player->Loop(nextfile);

However, the Play call will fill up the buffer (which is 11ms btw) before continuing. So the end of the file event happens before Play returns, and then the loop thing doesn’t happen.

I think file an github Issue for now, and I’ll fix it in 8.x :slight_smile:

1 Like

I find interesting It knocks out hum too even though it’s the effect file that has the issue. That the other effects play would indicate it’s not a run-out-of-wavplayers thing.
Maybe it just clogs up the buffer and affects hum_player?

  • edit - I added a debug printout to PickRandomSwing() since I had it open, and had it print when there were no hum_player, which it did indeed every change of swing pair.

Ok, we are now in BETA stage!

7 Likes

SubBladeZZ was tested a while back, but reporting it in the official testing thread.

Proof of life video:

1 Like

Is there some info on CONFIG_STYLES? The example is literally three lines:

#ifndef CONFIG_STYLES
using BatteryLevelStyle = InOutHelperX<Gradient<Red,Orange,Yellow,Green,Green,Green,Green>, BatteryLevel>;
#endif

Am I supposed to then do:

Preset presetneopxl[] = {
{ "Greyscal/Grey", "tracks/mars.wav",
    BatteryLevelStyle<>,
    "GS-Grey"},
};

I think if nobody is working on an OS7 example I could try one with all the options and highly anotated. But, that’s probably done by someone more knowledgeable.

It’s to allow using function styles to be moved to the bottom of the config (just to clean up reading the presets).

I haven’t had a chance to demo yet, but the new Config Tool will set it up for you if you choose OS7 and enable Using Functions, see this thread = ProffieOS6 & 7 Config Helper Tool v.2

1 Like

Is any way in which to keep a parameter, like color for example? That might simplify some setups.

Yes, working on that set up and demo currently. Hope to have it available soon.

1 Like

Minor bug spotted:
Something seems to have changed between an earlier version of 7.x and the latest one.
Prof, when you changed that OLED config thing so it reads the configs backwards, it worked fine, but I just tried it with the latest 7.x download and it doesn’t seem to be taking the ProffieOSFontImageDuration parameter in my shared oled folder. I’ve set it to seven seconds, but it seems to only display for the default five seconds.

Let me know if this doesn’t make sense and I’ll sort out a video to show what I mean.

If it’s any use, the version number of the earlier 7.x that works correctly is:
const char version[] = "$Id: ce12a06a1e236b5101ec60c950530a9a4719a74d $";