I’ve added this to my defines:
#ifndef VERBOSITY
#define VERBOSITY 0 /* range 0 - 5 */
#endif
Then I put this in my code:
(...)
case EVENTID(BUTTON_POWER, EVENT_PRESSED, MODE_ON):
#if VERBOSITY - 0 >= 3
STDOUT.println("Action: Power OFF");
#endif
Off();
return true;
(...)
Do you want me to propose it in a new thread? I think you should do it, though.
If you use sound library, the sounds queue up and wait to play until the previous one finishes.
I assumed it’s if you try to reload when already full 
I think we would actually want the default to be 2 or something.
Also, I think I should refine this concept a bit.
It would be nice if could be written just like this:
VLOG(3) << "Action: Power OFF\n";
And if the logging level is less than 3, this would get compiled into something that doesn’t do anything.
Also, VERBOSITY is probably not a good define actually. It’s possible that some other library or something would collide with it. It should probably be something like PROFFIEOS_VERBOSITY instead.
blaster.h waiting for accepting or commenting my solution to your comments.PROFFIEOS_VERBOSITY.master so we can define how to improve it further.Normally when there are comments on a PR and you make some fixes, you should answer those comments, even if it just to say “OK”, “Done” or “Do it yourself, wingnut”.
I’m sorry, I’m still trying to understand that part of git. Also trying to install it in my computer and clone my github fork locally. Please have patience because I’m a total newby.
hoping to build my rig today, I know how to grab latest stuff off github to help test. This tgread exciting. sorry I missed it!
No worries, my patience is nearly endless. 
(And I submitted your PR.)
Give me a couple of days and on my master fork will have blaster_baldusi.h with the full set of functionality that I’m feeding piece wise to blaster.h. Regrettably, I decided to “simplify” things, and broke a functionality. Let me settle the github in my PC, so I can make it work.
I highly recommend keeping the master branch clean (no changes) and develop your changes on a git branch with it’s upstream set to the master. Makes it much easier to merge upstream changes.
@profezzorn
I have a strange behavior that’s puzzling me. I want to add a define to set the initial power state.
/*-------------------- USE -------------------------------
#define BLASTER_DEFAULT_POWER_STATE - Sets the state at startup as ON|OFF|SOUNDFONT (dependent on poweron.wav presence). Defaults to SOUNDFONT.
----------------------------------------------------------*/
I will copy just the relevant parts of the code:
// First I make sure it is defined with the historic default
#ifndef BLASTER_DEFAULT_POWER_STATE
#define BLASTER_DEFAULT_POWER_STATE SOUNDFONT
#endif
// Then define an enum so I can do a "switch" statement later on
// Set default power state.
enum BlasterInitialPowerState {
ON = 0,
OFF = 1,
SOUNDFONT=2
};
// I then initialize at preset setup.
void SetPreset(int preset_num, bool announce) override {
PropBase::SetPreset(preset_num, announce);
switch (initial_power_state) {
case ON:
if (!SaberBase::IsOn()) {
On();
}
case OFF:
if (SaberBase::IsOn()) {
Off();
}
case SOUNDFONT:
if (!SFX_poweron) {
if (!SaberBase::IsOn()) {
On();
}
}
}
}
bool Event2(enum BUTTON button, EVENT event, uint32_t modifiers) override {
switch (EVENTID(button, event, modifiers)) {
/*
REST OF THE BUTTON PRESSES CODE
*/
//-----------------------------------------------------------------------
//POWER Button
//-----------------------------------------------------------------------
// In the event of the presence of a power button, let it control the power on events.
case EVENTID(BUTTON_POWER, EVENT_PRESSED, MODE_OFF):
On();
return true;
case EVENTID(BUTTON_POWER, EVENT_PRESSED, MODE_ON):
Off();
return true;
}
The SOUNDFONT (default behavior) and the ON case work just as expected. But the OFF case, starts as what looks like off, but I have to press the Power button twice to turn it on. What could it be?
I did found out that there’s no IsOff() method on SaberBase. Could it be something about identifying that it is, indeed, off?
I can’t tell what the problem is from this code.
Does the serial monitor show you what happens when you press the power button?
I will try. The positive of a NPXL strip got lose, and now this board will not boot when I power it. But if I connect it to the USB with the Arduino and press reset, it does start. Quite frustrating piece of hardware to develop a prop. 
I recommend one of these:
https://fredrik.hubbe.net/lightsaber/v6/test_rig.html
I do all the software development, debugging and testing with these things.
I wish I had had the foresight to do that. I’m actually waiting for the “long” version of the pFet module for low voltage switches to make a single order on OshPark. I live abroads and procuring the elements is a slow and painful process.
One “long” module coming right up.
Beautiful. I’m ordering 30 of the modules. Plus the 3x V3 breakout, 3x V3 pogo adapter board, 3x V2 pogo adapter board, 9x Graflex Helper v2 and 6 x Thermal Detonator Helper board. Now the questions: