ProffieOS 7.x pre-alpha discussion

[profezzorn]

@NoSloppy

TrWipe<BendTimePowInv<600,20000>>

I have TrFadeX<BendTimePowInv<1000, 65536>> in a test, and that compiled, so I’m not sure why it wouldn’t work for you.

@NoSloppy

then wouldn’t BendTimePowInv be this?

No, BendTimePowInv is flippex in both X and Y, which I guess makes it a 180 degree rotation, not a mirror thing.

The one you have is BendTimePow<ReverseTime<1000>, 65536>
BendTimePowInv<X, Y> is equivalent to ReverseTime<BendTImePow<ReverseTime<X>, Y>>, which is part of the reason I added ReverseTime<> in the first place.

Btw, I also added the ability to use time-bending functions recursively…
If needed, I can add other functions in the future that will bend time in other ways.

The other reason is that TrConcat<> needs the ability to time-reverse things in order to build loops, which is the next thing I’m going to add.

@NoSloppy

I know these are built to accommodate some new unseen stuff @fett263 has in store for OS7, so I assume that there’s no point is applying these to many transitions, although there’s nothing preventing one from doing so.

That is only partially true. fett263 had an idea for a style, but I’m exploring other ways to implement it, hopefully in ways that can be re-used in more ways.

[Fett263]

@profezzorn

fett263 had an idea for a style, but I’m exploring other ways to implement it, hopefully in ways that can be re-used in more ways.

Looking forward to it, already have additional ideas beyond original so this should be a helpful addition.

[NoSloppy]

@profezzorn

The only one that is supposed to make any difference is this one:

Bumping. Still a ton of constant Audio underflows.
If it helps, they’re all very close?

03:13:10.839 -> Audio underflows: 103
03:13:10.949 -> Audio underflows: 102
03:13:11.018 -> Battery voltage: 4.02
03:13:11.056 -> Audio underflows: 101
03:13:11.168 -> Audio underflows: 103
03:13:11.277 -> Audio underflows: 101
03:13:11.351 -> Audio underflows: 101
03:13:11.458 -> Audio underflows: 102
03:13:11.565 -> Audio underflows: 103
03:13:11.675 -> Audio underflows: 101
03:13:11.784 -> Audio underflows: 103
03:13:11.858 -> Audio underflows: 100
03:13:11.969 -> Audio underflows: 102
03:13:12.077 -> Audio underflows: 101
03:13:12.184 -> Audio underflows: 101
03:13:12.293 -> Audio underflows: 102
03:13:12.369 -> Audio underflows: 101
03:13:12.477 -> Audio underflows: 101
03:13:12.584 -> Audio underflows: 101
03:13:12.690 -> Audio underflows: 101

[profezzorn]

I’m not getting audio underflows on my test setup.
Guess I need to replicate yours. Post your config file? Any particular settings in Arduino → Tools?

[NoSloppy]

just default_profieboard_config.
Serial only.
SDI
80MHz
Smallest.

Fresh sync of master.
fresh formatted SD.
Weird these numbers are all almost the same

35 -> Audio underflows: 505
02:05:28.443 -> Audio underflows: 510
02:05:28.515 -> Audio underflows: 500
02:05:28.623 -> Audio underflows: 510
02:05:28.730 -> Audio underflows: 505
02:05:28.837 -> Audio underflows: 505
02:05:28.947 -> Audio underflows: 510
02:05:29.023 -> Audio underflows: 505
02:05:29.135 -> Audio underflows: 510
02:05:29.241 -> Audio underflows: 510
02:05:29.348 -> Audio underflows: 505

Re-creatable by serial monitor “on”, then “n”, maybe “n” a few times.

I’ll try another SD

[profezzorn]

n seems to be the missing ingredient, weird.
I’ll see if I can figure out what causes it.

[NoSloppy]

Yes, confirmed. All is normal until next or prev preset, then just a repeated output as posted above. Yet, the sound is fine, not choppy or laggy as typically with even just one or 2 Audio Underflow messages.

[baldusi]

I have a feature request. Since I’ve made the blade plug charging device work, I’ve found out I’m depending on the fact that in most of my installs I have Blade Detect wired. But many NPXL connectors don’t even have the necessary pins. And I depend on Blade ID for setting the correct LED spec and setting the charging preset. Thus, I was wondering if we could do one of the following additions to 7:

A) Add a #define to make the OS poll Blade ID every X time while the blade is retracted.
B) Add a & preset specifically for charging that polls Blade ID every second (or could be a parameter) when set.

The nice part of A) is that it would solve the problem of swapping blades without shutting off the hilt. I don’t have killswitches nor on/off on all my sabers.
The nice part of B is that you could disable motion sensors and many other power hungry parts.
Any thoughts?

[profezzorn]

@NoSloppy

Yes, confirmed. All is normal until next or prev preset, then just a repeated output as posted above. Yet, the sound is fine, not choppy or laggy as typically with even just one or 2 Audio Underflow messages.

II think maybe one of the players get stuck in a state where it’s not quite “stopped”, and not producing audio either.

[NoSloppy]

@baldusi

I have a feature request. Since I’ve made the blade plug charging device work, I’ve found out I’m depending on the fact that in most of my installs I have Blade Detect wired. But many NPXL connectors don’t even have the necessary pins. And I depend on Blade ID for setting the correct LED spec and setting the charging preset. Thus, I was wondering if we could do one of the following additions to 7:

A) Add a #define to make the OS poll Blade ID every X time while the blade is retracted.
B) Add a & preset specifically for charging that polls Blade ID every second (or could be a parameter) when set.

The nice part of A) is that it would solve the problem of swapping blades without shutting off the hilt. I don’t have killswitches nor on/off on all my sabers.
The nice part of B is that you could disable motion sensors and many other power hungry parts.
Any thoughts?

Check this thread out:

Crazy idea of the day - Constant Blade ID monitoring

This was a PM, but putting it here for public input. Disclaimer - totally off-the-cuff experimental and likely might take up resources, be a bad idea in general, etc… but is working in testing by adding/removing any blade, even a NPXL PCB first (detects the change), then add a blade on top of that (2nd change detected) (They’re wired in parallel) No BLADE_ID resistors are installed anywhere. If you have bladein.wav, it will play that when detected. Used these defines: #define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3> #define BLADE_ID_CLASS SnapshotBladeID #define BLADE_ID_MONITORED Edited the prop’s void Loop() to start like this: BLADE_ID_CLASS_INTERNAL blade_id; void Loop() override { PropBase::Loop(); DetectTwist(); DetectShake(); #ifdef BLADE_ID_MONITORED if (millis() - last_blade_id_ > 2000) { STDOUT << "BLADE ID: OLD = "<< looped_blade_id_ << "\n"; blade_id.id(); last_blade_id_ = millis(); STDOUT << "BLADE ID: checked = "<< blade_id.id() << "\n"; if (looped_blade_id_ > blade_id.id() + 100 || looped_blade_id_ < blade_id.id() - 100) { STDOUT << "BLADE ID: DIFFERENT ***** do something here\n"; // beeper.Beep(0.5, 1000); FindBladeAgain(); SaberBase::DoBladeDetect(true); } looped_blade_id_ = blade_id.id(); } #endif Vec3 mss = fusor.mss(); .................. and initialized these at the bottom uint32_t last_blade_id_ = millis(); uint32_t looped_blade_id_ = 0; Might need to be tweaked per setup: ENABLE_POWER_FOR_ID’s bladePowerPins are your blade’s LED pads. The id() +/- values. The 2000 delay adjust to taste. The detected values set in the BladeConfig. Use something reasonable based on what it shows in Serial Monitor for “BLADE ID: checked” for each state. You can kill the beep if you use bladein.wav instead. Terrible?

[profezzorn]

The audio underflow issue should hopefully be fixed now.

[NoSloppy]

yep! Thanks.

[profezzorn]

So Fett263 had a good idea: DISABLE_TALKIE; saves ~7.5Kb by disabling spoken error messages.
I improved upon the idea by replacing the spoken error messages with beep codes which takes very little space, but can still convey the same information.

Note that if DISABLE_TALKIE is used with a prop or style which uses talkie, you’ll get a compilation error. That error will explicitly mention DISABLE_TALKIE so it should be easy to figure out.

I’m working on a POD page which will have all he beep codes, including sounds you can listen to to figure out what they mean. In the meantime, try this cheat-(music)-sheet:

[NoSloppy]

@profezzorn

try this cheat-(music)-sheet:

I’m drawing a blank
and oddly there’s no “raw” icon to peek at what it’s supposed to be.
–edit-- oh, but I can drag it to the desktop and it’s a sheet music svg.
busting out the guitar…

[profezzorn]

What kind of browser do you have that can’t render SVGs?

[astromech]

We need a ProffieOS7 launch concert performance by the artist.

[NoSloppy]

Nevermind. It was the Experimental chrome flag for Dark mode setting.

[Sabersense]

I’ve no idea how the talkie system works, but would it not be possible to simply have 10 tiny wav files somehow loaded onto the board itself which just play a single number. Then when an error occurs, the board just plays the relevant number codes which you look up on a table?
So for instance if the board plays wavs 3, 7, 6, you look up what that number means.
This would mean no talking system is necessary as it’s just playing wavs, but it relies on the wavs being on the board in some kind of ram rather than on the SD card, and I don’t even know if that’s possible.

Just a thought.

[profezzorn]

Wavs take a fair amount of space. 88200 bytes per second in fact.
The 0-9 numbers would take up at least 5 seconds of audio, which
would take 441kb of memory.

Now, we can make that better by using phone quality audio (8-bit @ 8kHz), then it would only take up 40kb of memory.

This is where talkie comes in, it’s actually a simple audio compressor. WIth talkie, audio only takes up 200-500 bytes per second, which reduces the amount of memory needed from 40kb to 2.5k, plus ~5kb for the talkie code.

Oh wait, that means it would take 7.5k of memory, which is where we started, right?

[Sabersense]

Lol!
I hear ya Prof.
It was worth a shot.