Wow... I hate forum timeouts... had to retype ALL of this. Twice. I think I really need to change that setting.
In the following I use the term "Font-Package" alot. This is the term I'm using in my head-space to denote the groupings of associated light patterns and sound effects (ignition, hum, clash, swing, spin, etc) possible with the Diamond Controller, to distinguish them from "soundfonts" which are
just sounds. If there's already a distinguishing term for this, someone please point it out and I'll make the adjustment.
I think all this might have to wait till the Diamond II controller, but...
To start with, an Input Button for the controller to expand on gesture control. Read AB as "Activation Button" and IB as "Input Button" for the rest of this post. I'm not sure of the aesthetics of adding a second button to many hilts, at least on the same side, but I figure they did it for the RGB sabers, if the utility and demand was there, US would figure out a way. Having one around back, or to one side, or something might be necessary, rather than stacking them. Anyway.
Basically the IB is there to help expand and control gesture recognition, both as a kind of "confirmation" that, yes, I do want this gesture executed (Swing without button press, just swing. Swing with button press, gesture), and as an additional input to the board that doesn't require monitoring the accelerometers.
This would (at least I think it would) allow the introduction of a kind of "doze" state or mode for the saber. "Sleep" is when the saber is powered down, but ready for ignition (normally triggered by pressing the activation button), which requires a trickle discharge from the batteries. "Active-idle" is when the saber is on (ignited) and actively processing accelerometer input for gesture phrases. "Ignite" would ultimately end in "Active-Idle" and "Extinguish" would ultimately end in "Sleep" "Doze" would be between "Sleep" and "Ignite" much the same way "Ignite" is currently between "Sleep" and "Active-Idle". The saber blade lights and sounds aren't active (selected accents might be, defined in launcher, to allow for visual confirmation that the saber is dozing), and swinging it around produces no swing effects, but the saber
is processing inputs for gesture phrases. Getting into this state requires initial condition "sleep mode" and "IB double-tap." Exiting this mode is automatic and occurs 4 seconds (defineable in launcher) after entering if no valid gesture is detected.
This would allow something I saw mentioned elsewhere. The question was asked "Can we ignite the saber with a gesture?" The response was along the lines of 'technically possible, however the drain on the batteries in "sleep mode" would increase to an unacceptable level, lowering the operational lifetime of the saber on a charge considerably.'
With "doze mode" this would alleviate that concern, as the active monitoring and processing of inputs (and associated drain) would only be done for very short periods, rather than constantly. Imagine a computer workstation. When the computer is on but inactive, the monitor is effectively off. When someone hits the mouse, the screen turns on, looking for a password. If no one enters a password, the screen turns off after a short period. Since the command to enter "doze" is singular and specific, accidental activation is limited (like limiting a workstation to a single specific keypress combination to wake), and even then is short in duration. When in doze mode, the activation button is treated as a gesture input only. During doze, ignition of the saber is
only possible via gesture, if you intended to simply ignite the saber, a single press from "sleep mode" is easier. Other gestures can be activated during doze, and play to completion. Unless they change the mode of the saber (see below) the saber returns to doze and thence to sleep, if no further gestures are input.
Another idea is On-The-Fly Font-Package transitions. Coupled with gesture recognition and "doze" this would allow transitioning to/from a mute font-package (or any other font). So the days of igniting a saber (with the associated ignition and hum (or lack thereof, in the case of going the opposite way)) just to get into (or out of) a mute font would be over. Also possible would be gesture controlled Font-Package changes during use (little more on that later).
A possible issue with the IB as input to gestures is the possibility of conflicting gestures. Say you have two gestures, "spin, IB tap" and "IB tap, spin." Separately, these pose no problem. But if you have an input sequence consisting of "spin, IB tap, spin" might cause issues. What I envision to solve this is a rolling buffer where processing inputs are matched against gesture phrases, and a separate buffer that is effectively a FIFO execution stack, where the recognized gesture activated commands are stored. So if the above happened, Gesture One's commands would be stored and begin executing, then Gesture Two (as the phrase is present) would be stored behind Gesture One's, and when Gesture One's commands had run their course, Gesture Two would begin executing... and so on. Effectively this allows stringing gestures together. without having to have more than a minimum of "words" in each phrase.
Expanding on the above is the idea of a "macro-like" gesture command editor for the launcher. Defining the gesture might still have to be done via actually performing it, and using an activation button hold as a "phrase start" and "phrase end" marker during recording. Short AB presses (double taps, and the like) would be taken as inputs. Directly editing at least three, and probably six, different accelerometer axes for intensity and duration would be way beyond most people's skill to translate from raw expected input to actual performance, but "ready, hold button, swing, other button, first button hold" is fairly repeatable for anyone. What would be easily editable is what that gesture executes, in what order, what pauses to make, etc. The following is an extreme situation, but I want cram-fu as much example in as I can. Consider this as a choreographed sequence.
Doze mode from sleep (hardwired):
IB double tap.
What's recorded as Gesture 1:
IB double-tap, AB double-tap.
What's recorded as Gesture 2:
IB, Spin, DifferentSpin.
What's programmed in the launcher:
Gesture 1 = Set ActiveFont-Package to F-P2. Wait 1.50 sec. Play F-P2 poweron . (note, this is not
Mode: Ignite, explained below). Play F-P2 Swing3. Play F-P2 Swing1. Play F-P2 Spin2. Play F-P2 Spin1. Play F-P2 Swing 2. Play F-P2 Clash2. Play F-P2 Idle, Break (explained below). Wait 2.30 sec. Play F-P2 trans2to3 (also explained below), Set ActiveFont-Package to FP-3. Mode:
Active-Idle.
Gesture 2 = Play F-P3 Swing1. Play F-P3 Spin2. Play F-P3 Swing 3. Play
F-P4 Force2. Mode:
Extinguish.
[Explanations from above]
"Mode:" is a command to the software to change the condition of the saber. Ignite and Extinguish play the associated ActiveFont-Package effects for power on/off, and put the saber into "sleep" or "active-idle" at completion. Mode: Sleep is possible, but would put an idling saber directly into sleep mode without the powerdown effect. Mode: Active-Idle (as seen above) sets the saber to normal idle operation without the poweron effect being played.
"Break" is a modifier for the buffer software, telling it to immediately begin the next command instead of waiting for the current one to complete. In the case of the next command being a light and/or sound effect, the software interrupts the light and/or sound effect currently playing and plays the new one. In the case of only one effect being interrupted, the previous effect (light or sound) continues playing until the new effect ends. In the case of a Break -> Wait, as above, the previous effect continues only as long as the Wait command specifies and then the next effect is played. In the case of multiple effects not interrupting the first effect (such as a Break, Set ActiveFont, Wait) combination, the first effect plays until interrupted.
I think "Set ActiveFont-Package" is pretty self explanatory, but it is exactly what it says on the tin. It changes the currently active Font-Package so that any swings, clashes, etc not directly played by gesture-macros are played from that Font-Package. Note the example (bolded) in the last gesture, where it calls a sound effect not in the active font.
The effect 'trans2to3' would be a custom transition between the idle effects of F-P2 and F-P3. This effect would have to be defined by the end user, or a Font-Package maker to create seamless transitions between Font-Packages possible. Without this, the idle effects would probably jar against each other, (such as a yellow saber blade suddenly blinking to purple, with a quiet-ish hum suddenly being a loud heavy rumble). Changing Font's during other effects (spins, swings, clashes, etc) would be possible with Break modifiers, with a blade starting a swing as yellow, suddenly becoming purple as the swing ends. The transition will still be sudden, but perhaps not quiet as jarring.
-----
Initial conditions of the saber: Sleep mode = on, ActiveFont-Package = F-P1.
What the observer sees:
Wielder unclips saber and assumes a ready stance, maybe notices him fiddlin' with buttons as he does (IB double tap, IB double tap, AB double tap).
Wielder begins swing, saber ignites mid-swing with a bright yellow blade.
Wielder swings again, associated sound playing.
Wielder swings a third time, different sound.
Wielder enters figure 8 spin from swing, spin sound plays one half, changes to another on second half.
Wielder hits something (floor, opponent's blade... whatever, choreography) and associated clash/flash plays.
Wielder, (apparently angry) takes a step back, raises his blade to a high ready, and the blade changes from yellow to a deep orange. As it does so, the hum takes on a sinister base rumble, instead of the more pleasant hum it had.*
Wielder and opponent spar for a bit, trading attacker and defender roles several times.
Wielder takes stance, then begins a two spin sequence, followed by a strike, recovery, follow-up strike and a palm-out push ('force sound' from saber). The saber extinguishes itself as the wielder performs a flourish, and the encounter ends.
What's actually going on:
Saber goes from sleep to doze.
Gesture 1 activated. Gesture-Macro plays, ending in a mode change for the saber (to Active-Idle) in a different Font-Package than it started in.*
Wielder and opponent continue choreography (normal saber operation at this point, all automatic light/sound effects).
Gesture 2 activated. Gesture-Macro plays, ending in an apparent force push from the Wielder, followed by an immediate saber deactivation.
Whew... I think I'm technicaled out for a while...
TL;DR: What they (US) have got is great already. Make it better.
