FX-Sabers.com
Ahch-To: Instructional Section related to constructing your own Lightsaber => Open Source Sound Cards => Topic started by: Thexter on February 18, 2017, 12:25:44 PM
-
Background and inspirations:
Remember the hiltworks project from years ago?
HiltWorks Project Demo (https://www.fx-sabers.com/forum/index.php?topic=32098.0)
Well, ever since I found that old thread, I've been trying to do something similar.
This guy is also doing something similar, but from what I can tell, he's synthesizing his hum.
Lightsaber Tuning - YouTube (https://www.youtube.com/watch?v=-djnJXEMK1s)
And just yesterday in Profezzorn's thread Lolwel21 came up with an interesting idea for smoothly interpolating between the hum and a looping swing sound.
Announcing the Teensy Saber open source sound board (https://www.fx-sabers.com/forum/index.php?topic=50445.msg652131;topicseen#msg652131)
This all ties into what I'm about to describe. I had the basics of this working before Christmas, but have been holding onto it, because like any artist, I'm always wanting to make things perfect before showing them to anyone.
Theory:
The actual lightsaber swing sounds in the movies are just Ben Burtt waving a microphone in front of a speaker playing the hum. There are two main effects you get form this:
- You get a small doppler shift of the sound (2 to 3 semitones up or down)
- You get a volume change as the microphone nears or retreats from the speaker
When I talk about pitch shifting, I'm talking about not just changing the sample rate, but the time-invariant pitch shifting where the length of the sound stays the same. While real-time pitch-shifting is elusive on the little MCUs we use, we can fake this by playing 3 sounds at once.
Sound 1: The original looping hum from your font (main)
Sound 2: The original looping hum, but pitch shifted a few semitones higher (high)
Sound 3: The original looping hum, but pitch shifted a few semitones lower (low)
I play all three sounds at once, but the relative gains on each are controlled by the motion of the saber. When the saber is still, you have the main hum at normal gain, and the other two have gain of 0. We want the relative volumes of the two pitch-shifted swing sounds to increase according to how hard we're swinging the saber. But how do we do this?
Observations:
First, here are a few observations I noticed when watching the movies:
- Often a high-pitched swing will be followed by a lower-pitched swing. This makes sense. When swinging the microphone towards or away from the speaker, Ben Burtt can't keep swinging in the same direction. He has to swing towards the microphone and then away from it.
- There is often an effect where a single swing goes low-high-low, or high-low-high (in terms of pitch). This is the case when swinging the microphone across a speaker.
- Sometimes the swing of the saber doesn't actually change pitch in the movies, only volume. As far as I can discern, this is likely the case where the microphone was nearing the speaker without moving quickly enough to warrant a noticeable doppler shift.
- Multiple swings in the same direction don't always produce the same pitched swing sound. This means you can't just say swinging left always lerps towards the high sound, or swinging right always lerps towards the low sound.
Implementation:
So, how do we mimic these observations?
The first approach I tried was to have a single secondary track and increase the gain on one of the sounds (and decrease the gain on the main hum accordingly) in relation to the gyro readings. However, this means you are stuck with one swing sound, and no real variance in pitch. I believe this is similar to the approach Lolwel21 described.
I also tried having a single secondary track that blended various high-pitched and low-pitched hums over time, and then increased the gain on that track with the gyro readings, but that just sounded rythmic and throbbing when you swung during swings due to the premixed swing track.
That's where the 3 track method came into play. Part of the method I came up with is to treat the axes of the gyro independently. Each axis still contributes to both the high and low pitched hum. This will give you a series of weights for each of the pitch-shifted hums. The behavior of this is that for most cases you get the high-low alternation found in observations #1 and #2. The volume is controlled by the magnitude of the total angular velocity and is independent of the weights of the pitch shifted sounds. Because of this, there will be times where you have a swing, but the weights for each of the pitch-shifted hums ends up being zero. This solves the case where a swing may not affect the pitch (observation #3), but only the volume. Remember that we're modifying volume based on total angular velocity.
Great, but what about observation #4 above? With the method I just described, the saber would behave exactly the same for each identical swing. We don't want that. We want variance.
One solution is to allow the basis that you're using to measure the angular velocity to drift or rotate by itself. Right now, when you take gyro readings, you're taking them in the frame of reference of the gyroscope. X is x, y is y, z is z. If you change the frame of reference over some period (I found 2 or 3 seconds to work well for me), you get a nice variation in the swing pitch. This is especially cool when you are spinning and the effect varies and drifts over time.
Other considerations:
- Obviously, only polyphonic fonts work with this method.
- You can use the hum from another font as the pitch-shifted hums for more interesting effects. Be careful with this as it can also sound absolutely awful.
- Clipping is a huge issue here. For dark-side fonts, this is OK, as they're supposed to be grittier, but for light-side fonts, I use a pass to increase the power of the pitch-shifted hum without modifying the absolute magnitude. It's the same thing they do for pop music. I suggest having good control over your secondary stream volume per-font.
I will post a video later once it uploads to youtube.
-
As promised, here's the video:
-
Very cool stuff.
Do you already have an implementation of this that we can just put in TeensySaber? What kind of sound board does the saber in the video use?
If not, I can probably put something together from the description here, but seeing whatever code you're using would be cool. :)
-
That's pretty stellar, dude. Wow.
-
Do you already have an implementation of this that we can just put in TeensySaber? What kind of sound board does the saber in the video use?
The one in the video is using a Teensy 3.2. Your codebase and mine share no common ancestor, so the code won't come over directly. Here are the relevant bits. I was originally calling it multi-hum, so there are still remnants of that nomenclature. Another thing to note is that this is the simplified version. It doesn't use any fixed-point math. As soon as I got my Teensy 3.5 and 3.6, I wrote this version up. It's much easier to understand, but probably slower on the 3.2 without an FPU.
Here is the relevant code when reading the gyro. The key is that both m_flSwingStrength and m_flMultiHumAmount are stored off for later sampling by main loop:
// gx, gy, gz are all instantaneous gyro values
// flTotalRotation is the total angular velocity of gx, gy, gz
// m_flMultiHumCyclePeriod is actually poorly named and is really the inverse of the period.
// Periodicity / Rotation of the basis
float flCycleTime = ( nCurrentTime / 1000.0f ) * m_flMultiHumCyclePeriod;
float flYAmount = sinf( flCycleTime );
float flZAmount = cosf( flCycleTime );
// Normalize to the swing sensitivity and clamp
float flNormalizedY = max( -1.0f, min( 1.0f, gy / m_flMultiHumSensitivity ) );
float flNormalizedZ = max( -1.0f, min( 1.0f, gz / m_flMultiHumSensitivity ) );
// Apply the rotation
float flMultiHumAmount0 = flYAmount * flNormalizedY;
float flMultiHumAmount1 = flZAmount * flNormalizedZ;
// Store off total strength
m_flSwingStrength = min( 1.0f, flTotalRotation / g_flMultiHumSensitivity );
// Multi-hum amount is the sum of both axes (both go from -1..1 range) divided by sqrt(2). Think of the case where both are 1.
m_flMultiHumAmount = ( flMultiHumAmount0 + flMultiHumAmount1 ) / 1.414214f;
In the main loop, you can use these values to basically control the sounds. m_flMultiHumAmount is a -1 to 1 value where -1 is full strength for one of the pitch shifted sounds, and 1 is full strength for the other. 0 for m_flMultiHumAmount means 0 volume for the pitch-shifted swings. m_flSwingStrength is the overall swing strength.
-
This pretty epic! Ever since the Hiltworks stuff was shared here, it's stuck in my head as the ideal approach/solution to saber sound. With the recent exciting, evolutionary strides and contributions from talented folks with open source boards, I guessed something along these lines was back on the table. Really stoked to see this - great work and cheers for sharing :azn:
-
That's really cool!! Love the hums.
-
Wow, that's just incredible Thexter! By far the best swing sounds I've seen. This would work great with fonts like Darkblade which are very "noisy" in the canon material.
-
Thexter, for this terrific motion altered hum mixing you earned an eminent place in the DIY Saber builder's Hall of Fame!!! Such a hum pitch shift is more realistic than the swing sounds, and as a further advantage, all the swing sounds could be eliminated, replacing them with 1-2 additional hum sounds (or even have only one and alter the pith of that, it already gives accurate results), making sound fonts smaller in size (going for flash memory :wink: ).
I personally think that what Thexter describes here is the last piece in a puzzle to finally reach break-even with CF using a DIY saber board. Good times!
-
Wow, this is a really impressive.
The way the sound shifts according to the movement of the saber sounds so "natural".
I believe this is one of the biggest groundbreaking developments we have seen since long time.
I definitely need to find the time to complete my saber and start playing with my DIYino.
-
It's times like these that I wish I was more code savvy. :embarrassed:
-
What audio library do you use? (May I use it?)
-
I'm just using the Teensy Audio library that comes with the teensyduino software, so I have to upconvert all of the sounds to 44khz. There's an option to compile the audio library for lower sample rates (eg 22khz), but I've not done that yet.
Also, and I apologize if this is obvious, make sure to enable the Teensy sd card optimizations if you're using the 3.2, or you won't be able to read more than 1 file at a time on many sd cards.
-
I've never managed to get the teensy optimizations to work.
However, TeensySaber has better buffering code than the teensy audio library, which is why I can still play a several wav files at a time.
(I have some updates to the code that I need to post though...)
-
Thexter, have you tried this simplified code?
Does it work the same as the fixed-math code?
I'm curious, because it doesn't seem to match your description very well.
Some comments on the code:
// Apply the rotation
float flMultiHumAmount0 = flYAmount * flNormalizedY;
float flMultiHumAmount1 = flZAmount * flNormalizedZ;
This is not actually a rotation. A rotation would be something like:
rotate_x = x * cos - y * sin
rotate_y = x * sin + y * cos
m_flMultiHumAmount = ( flMultiHumAmount0 + flMultiHumAmount1 ) / 1.414214f;
Shouldn't this be / 2.0 ? As is, m_flMultiHumAmount can be greater than 1 or less than -1.
I thought two of the hums were supposed to be controlled independently by the rotated x/z axis?
Anyways, I'll try implement this the way the code says and see what that gets me. :)
-
Thexter, have you tried this simplified code?
Does it work the same as the fixed-math code?
Yes, I'm using this code in the electronics for my sixth saber and it seems to be working the same.
This is not actually a rotation. A rotation would be something like:
rotate_x = x * cos - y * sin
rotate_y = x * sin + y * cos
Apologies if this is too detailed. I'm fairly certain that you only need two sentences out of this, but for anyone else reading, and just to have it written out somewhere:
Remember, you're not rotating the actual gyro values. You're rotating the axis against which they're compared. Let's take the case of only looking at gz. Let's create an imaginary basis where positive z points in the direction the saber would rotate if gz were increasing, positive y orthogonal to both positive z and the midline of the saber... or we could just say y is up. Therefore increasing gz rotates us towards this point, and decreasing gz rotates us away from this point. Also, this point is unit length away. It should be noted that this basis is local to the saber, and not global. You never actually get nearer to the point, you just see if you're swinging in that direction.
In this case, our imaginary axis is fixed. We have a small value of let's say 0.3 for the gyro-z, and that's what we use for our hum selection. Gyro-y is basically has no influence. Remember our gyro-total still influences the total volume.
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_1_zpseopif2fn.jpg&hash=708ec214b8504956409f86a21d915a29094e2c4f) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_1_zpseopif2fn.jpg.html)
In this next example, we have a large negative gyro-z, so we have around -0.8 for the hum selection.
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_2_zpskarozwez.jpg&hash=3a80378d85a82ba37149611c551a472fcefcaa69) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_2_zpskarozwez.jpg.html)
Now let's rotate this imaginary axis around x. You are correct, the new axis is a rotation of the original:
axis_new_z = z * cos( t ) - y * sin( t )
axis_new_y = z * sin( t ) + y * cos( t )
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_3_zpso9wgqjdp.jpg&hash=ba7edc8bcc9e2f08fbe5972bc02168ff752e7209) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_3_zpso9wgqjdp.jpg.html)
But remember, our original z and y coordinates were 1 and 0 respectively. So, plugging these back into the equation yields:
axis_new_z = cos( t )
axis_new_y = sin( t )
I thought two of the hums were supposed to be controlled independently by the rotated x/z axis?
I may have been unclear on this, and it's probably also where the confusion in the rotation comes from. I should really have said that I'm making a single non-normalized vector of the two independent axes and comparing them to the swing basis (the newly rotated axis). Each gyro axis still contributes, and it's not an orthonormal contribution because it's not unit length, but I can't really say they're independent.
So, I create a swing vector for the gyro < gz, gy > and see how this vector projects onto the rotated axis. So:
projection = dot( gyrovector, axis_new )
projection = gz * axis_new_z + gy * axis_new_y
In this case, the projection of gyro-total onto the rotated axis is almost the full length of the gyro-total vector.
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_4_zpsq6ko1scm.jpg&hash=8fafce702536ae5be34a3744963a7427621ecbc9) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_4_zpsq6ko1scm.jpg.html)
In this case, the projection of gyro-total is largely onto the negative rotated axis, yielding a large negative value.
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_5_zpsvjbdxsoh.jpg&hash=37f54ea22450e03cfdb7941b0cca7b755ee706f2) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_5_zpsvjbdxsoh.jpg.html)
In my code, I've actually scaled and clamped the gz and gy, so it's flNormalizedZ and flNormalizedY, but this doesn't mean the vector is normalized, only each individual is within some scaled and clamped range.
Shouldn't this be / 2.0 ? As is, m_flMultiHumAmount can be greater than 1 or less than -1.
You would think so, but you can't actually get values of 2 with the code as written because flAmountY and flAmountZ are 90 degrees out of phase. Remember that our total gyro vector can be greater than 1 in magnitude? Well, the maximum magnitude it can have is sqrt( 2 ), since each component can be a maximum of 1 and you peak when you're swinging 45 degrees between the two gyro axes. To keep the total influence below 1, I divide by this. Think of it as a clipping protection.
(https://www.fx-sabers.com/forum/proxy.php?request=http%3A%2F%2Fi349.photobucket.com%2Falbums%2Fq367%2FThexter79%2Fsmooth_swing_6_zpsqkvf8oev.jpg&hash=bb3efbd09dcd4276771f9b08050cdbaacc62598e) (http://s349.photobucket.com/user/Thexter79/media/smooth_swing_6_zpsqkvf8oev.jpg.html)
-
Very cool!
-
I should also point out that you can apply this to accelerometer values as well. It's actually easier to think about because you don't have the added headache of thinking of the angular velocities as plots on an fake zy plane. However, the code is identical assuming you have different code to scale and clamp the accel values into the -1..1 range.
I've not actually done this as I like my swings only to work with rotation and leave the accel for clash detection, but that's just me.
-
I think my confusion comes from comments and variable names mostly.
The code does do what you say, and you're right diviging by sqrt(2) is the right thing to do.
I would probably write the code a little differently though. If you rotate the gyro values and
always project to the X axis, the code becomes:
x = clamp(x * scale, -1, 1);
y = clamp(y * scale, -1, 1);
projected_x = (sin(angle) * x + cos(angle) * y) / sqrt(2.0);
This is in fact exactly the same as your code, but shorter, and less confusing. (At least to me.)
Am I right that you then calculate the volumes kind of like this:
total_volume = 0.5 + clamp(total_swing_speed, 0.0, 1.5);
hum_balance = 1- abs(projected_x);
hilo_balance = (1 - projected_x) / 2;
hum.set_volume(total_volume * hum_balance);
hi.set_volume(total_volume * (1 - hum_balance) * hilo_balance);
lo.set_volume(total_volume * (1 - hum_balance) * (1 - hilo_balance));
?
-
x = clamp(x * scale, -1, 1);
y = clamp(y * scale, -1, 1);
projected_x = (sin(angle) * x + cos(angle) * y) / sqrt(2.0);
Fair enough.
total_volume = 0.5 + clamp(total_swing_speed, 0.0, 1.5);
hum_balance = 1- abs(projected_x);
hilo_balance = (1 - projected_x) / 2;
hum.set_volume(total_volume * hum_balance);
hi.set_volume(total_volume * (1 - hum_balance) * hilo_balance);
lo.set_volume(total_volume * (1 - hum_balance) * (1 - hilo_balance));
I feel that this part is very much up to your ear. That's very close to how I do it. In your case, you get 50% contribution from both hi and lo when projected_x is 0, which is fine because (1 - hum_balance) will be 0 as well. However, you'll still get some influence from both hums when projected_x is slightly off of zero, because of the straight lerp between the two.
In mine, I have a different summation, which only adds in any of the hi or lo hum when projected_x moves away from 0.
I believe modifying your last 2 lines to look like this would achieve the same effect as I did. However, see which one sounds better and do that.
hi.set_volume( total_volume * max( 0, projected_x ) );
lo.set_volume( total_volume * -min( 0, projected_x ) );
My min total volume is 1 instead of 0.5 because I have an additional scalar on the "total_volume" value. I do this in a per-font basis, but I often scale the "total_volume" much greater than 1 (sometimes 2 or 3) to get that aggressive volume change for smaller swings. It's all related to your thresholds and other scale factors.
-
Awesome, I've been hoping someone would try this route. I actually messaged HiltWorks to offer my assistance to try and get the project going again.
Do you have a video of how this handles with small and large slow movements? That's the nuance I think this method really has over traditional swing triggering and the reason I like it :)
-
Got this implemented in TeensySaber now, but testing/tuning will have to wait until tomorrow.
Hopefully I can find some good looped sounds...
-
What kind of looped sounds?
Does file size matter?
-
Awesome, I've been hoping someone would try this route. I actually messaged HiltWorks to offer my assistance to try and get the project going again.
Do you have a video of how this handles with small and large slow movements? That's the nuance I think this method really has over traditional swing triggering and the reason I like it :)
-
That's awesome :D Is 3 tracks the limit processing-wise or could you add more with larger pitch variations or more inbetween stages for more dynamic variation? Watching a bit of the ESB duel now there seem to be more 'pitches' in the swings. I know you said dynamic pitch shifting is too much for the microcontroller but increasing the 'resolution' with a larger number of tracks with different thresholds might feel more realistic for harder and softer swings?
-
Changing the pitch on the fly is totally doable, however it might affect sound quality to some degree, because there is not enough time to do a true high-quality conversion.
-
Changing the pitch on the fly is totally doable, however it might affect sound quality to some degree, because there is not enough time to do a true high-quality conversion.
Actually, I take that back. True high-quality conversion is possible, but harder, because the there isn't enough cpu to do it the *simple* way. :)
The teensy is capable of mp3 playback, which is similar in difficulty to resampling.
-
Actually, I take that back. True high-quality conversion is possible, but harder, because the there isn't enough cpu to do it the *simple* way. :)
The teensy is capable of mp3 playback, which is similar in difficulty to resampling.
Well that's potentially even more exciting :) I'm working on a looping version of the original projector hum and broken mic cathode tube recordings from a video interview with Ben Burtt that might be good for this.
-
Got this implemented in the teensysaber software now. (version 1.43 available from Teensy Saber OS (beta) (http://fredrik.hubbe.net/lightsaber/teensy_saber.html))
My implementation doesn't sound quite as awesome as Thexters though. Could be I don't have the right sounds, could be I don't have it tweaked right, or maybe my dynamic compressor is taking some of the omph out of it. Not sure.
To activate the looped swing mode, just add "swingl.wav" and "swingh.wav" to any existing font.
I made my swingl.wav and swingh.wav like this:
sox hum.wav swingh.wav speed -180c rate -v
sox hum.wav swingl.wav speed 150c rate -v
-
To activate the looped swing mode, just add "swingl.wav" and "swingh.wav" to any existing font.
What directroy do the "swingl.wav" and "swingh.wav" go in? /hum or /swng or doesn't matter?
-
To activate the looped swing mode, just add "swingl.wav" and "swingh.wav" to any existing font.
What directroy do the "swingl.wav" and "swingh.wav" go in? /hum or /swng or doesn't matter?
If you're using subdirectories for effects, each effect should have it's own directory, so it would be:
swingl/swingl.wav
and
swingh/swingh.wav
Really no need for subdirectories for effects that only have one file though, so just swingl.wav and swingh.wav is fine.
-
I tried this some months ago, haven't worked on it in a while. No sound fonts/wav's for buzz sound. Yours sounds pretty good!
-
I cannot wait to dive into this board and do this! you guys are my heroes. lol
-
Got this implemented in TeensySaber now, but testing/tuning will have to wait until tomorrow.
Hopefully I can find some good looped sounds...
Sorry if this has been answered somewhere else, i haven't seen it yet in my reading here but, Do i need to make or modify sound fonts for this to work? or is it just taking a soundfont and renaming the file?
-
The sound font has to be modified, at least a little bit.
Basically you have to create two more hum sounds, one with a slightly higher pitch and one with a slightly lower pitch.
One reasonable simple way to do so is to use a command called "sox"
sox hum.wav swingh.wav speed -180c rate -v
sox hum.wav swingl.wav speed 150c rate -v
This works, but the result isn't quiete as awesome as what Thexter was able to do.
More interesting results can be obtained by taking the hum from a *different* font to create the swingl/swingh sounds.
-
cool! so if i wanted to duplicate thexters results as close as i can id need to get into manipulating my own fonts? Or i think you mentioned in a message that hes using slightly different hardware? Im really interested in diving into the sound configuration. Im just waiting on a breadboard to come in so i can start learning it
-
cool! so if i wanted to duplicate thexters results as close as i can id need to get into manipulating my own fonts? Or i think you mentioned in a message that hes using slightly different hardware? Im really interested in diving into the sound configuration. Im just waiting on a breadboard to come in so i can start learning it
He uses different, but very similar hardware.
The bigger problem is that he uses different software. The looped swing implementation in teensysaber is based a description of what his V1 code does, but it's not identical. I think it works pretty well, but I haven't been able to make it sound as good as Thexter's demos. Not sure if that's because his code works better/differently, or if he just has better sound fonts than I do. According to Thexter, Smoothswing V2 blends many more sounds than Smoothswing V1, but that's about all I know about it.
-
Fascinating. Im very interested in this aspect of saber building! My favorite thing to do when dealing with plecter boards was the tuning aspect of it... Making the sounds feel as responsive as possible. Ive been considering making my own sound fonts lately and the smoothswing tech im seeing is really igniting that interest again. I work in film and im going to start asking some of my buddies in sound about making sound fonts. I might shoot you a pm her soon for some advice/ things i should research. Thanks you guys for all you do!
-
Fascinating. Im very interested in this aspect of saber building! My favorite thing to do when dealing with plecter boards was the tuning aspect of it... Making the sounds feel as responsive as possible. Ive been considering making my own sound fonts lately and the smoothswing tech im seeing is really igniting that interest again. I work in film and im going to start asking some of my buddies in sound about making sound fonts. I might shoot you a pm her soon for some advice/ things i should research. Thanks you guys for all you do!
If you haven't read it already, I suggest starting with this excellent article: Lightsaber Sound Cookbook (http://www.dblondin.com/071807.html)
-
This was pretty cool reading your and Thexter's language brainstorming. Even though most of it is greek to me, the results are not. Smoothswing is very awesome, and I thank you both for developing it. This thread might be a bit historical when the chips fall where they may. Very cool stuff.
Tom
-
Now that smoothswing has been implemented into CFX and Proffie, this thread is indeed historical, and as such ought to be pinned in this section. Thexter changed the entire custom saber community here with a few vids and a couple lines of ingenius coding. While it has been modified, and supplemented since, this is the thread where it all started. If you're running Crystal Focus 10, Proffie, TeensySaber, Brewboard, DIYino, etc. that uses smoothswing...….give Thexter some thanks! Thank you Thexter! You are the man!