Not so crazy - OLED durations from sound file length

So I’m working on blaster stuff, and additional images for OLED.
Particularly, Self-destruct. I thought it would make sense to have the duration listen to the file length instead of a fixed ProffieOSDestructImageDuration for example, because different fonts can have different sounds.
Having a hard time figuring this out.
I guess I just don’t know the right things to call.

GetCurrentEffectLength(); seems to return a different file’s time than the one triggered in the prop’s SB_EFFECT, and I can’t figure out how to print the current effect to see which it’s getting from.
I can print the length, but not which effect.
This is what I’ve tried in ssd1306.h:

  void SB_Effect(EffectType effect, float location) override {
    switch (effect) {
// other cases are all here
      case EFFECT_USER1: {
        float len = hybrid_font.GetCurrentEffectLength();
        ShowFile(&IMG_destruct, len * 1000);
       // ShowFile(&IMG_destruct, font_config.ProffieOSDestructImageDuration);

      default: break;

The triggered sound, destruct.wav, is 10 seconds long. But I’m getting a returned len of like 1.2 or .82… and whatison shows the last few played might be getting chosen (like boot or out, which are more like those lengths).
Best I can think is that GetCurrentEffectLength(); is too early and not picking up the destruct.wav from EFFECT_USER1. Would it need to wait a moment?
Other attempts like:
STDOUT.println(current_effect_);' STDOUT.println(GetEffect()); STDOUT.println(GetName());`
don’t work due to template parameters and other errors.
Other ways involve too specific things that would depend on the user having the file defined in a prop with EFFECT(destruct); and susequently play the wav directly, like I tried something like:

        if (SFX_destruct) {                                                          // cant depend on this being declared in prop
          ShowFile(&IMG_destruct, 1000 * hybrid_font.PlayPolyphonic(&SFX_destruct)->length());
        } else {
          ShowFile(&IMG_destruct, font_config.ProffieOSDestructImageDuration);

Just missing a piece or two to this puzzle, while trying to keep in mind that it needs to be kept generic enough that any blaster prop can still work with it,
and doesn’t take up memory for all users if not needed.
Any insight would be appreciated to get cool stuff working!

You have to change SB_Effect to SB_Effect2 to get access to the sound lengths.
After you do that, you can find the sound length in SaberBase::sound_length and the file number (if you need it) in SaberBase::sound_number.

Thanks, but I’m not that smart. No idea about SB_Effect2, but this works, thanks!

  void SB_Effect2(EffectType effect, float location) override {
    switch (effect) {
      case EFFECT_USER1: {
         ShowFile(&IMG_destruct, SaberBase::sound_length * 1000);

So now the question is, since this has a specific new IMG file, if this were to be officially submitted, do you think USER1 is right, or would a more descriptive, specific EFFECT be better, such as EFFECT_DESTRUCT ? (Trying to not unnecessarily use memory)

The backstory here is I made this work both ways - as is now as a one-shot thing, and also a version using the LOCKUP_ARMED version that detonator had already laid out. (with some modification since there’s no button being held, it’s a set-it-and-run-away sort of thing)
However, I think it’s great to be able to auto-time the blade effect for the overload to the sound using WavLen, which I couldn’t do with the Lockup version.
SO since no button held for lockup and no WavLen, I am leaning toward this one-shot route.

How about using OffType::OFF_BLAST ?
This is what the detonator prop uses to blow itself up.
Seems like if you make the self-destruct work similar to the detonator, then if someone puts a display on a detonator, that will work too.

Welll for the blaster prop, I removed Off(OFF_BLAST); and just stuck in

         case NEXT_ACTION_BLOW:

so the user doesn’t need to manually power on the blaster after boom…it’s just still on and ready to go. Not logical since it’s in smithereens at that point, but ¯_(ツ)_/¯

I can PR some stuff for review if that’s cool

Doesn’t that mean that if your blaster has a hum, it will continue after blowing up?

Sure, but I won’t merge it until I’m semi-confident that there aren’t more OLED fixes needed for 6.x.
(This would be come a 7.x feature, so there is no rush…)

Yeah… I guess since I bothered making power on/off always available, might as well use it.
Off(OFF_BLAST) it is!

@profezzorn here’s what I got.


Trying to figure out how to show the font image on preset change, but since it’s already on it doesn’t want to do it.

I also forked the blaster prop. added in volume menu, on demand battery level with spoken battery level, quote player, couple other things too. Calling it blaster_BC for now. Of course, no time frame. PR primarily for review and tips and tricks you might have for now. Thanks.

1 Like