On the way to Crystal Focus V4

[Luke-SkyMarcher]

The GUI sounds awesome! I had a similar idea a while ago, glad to see I wasn't the only one!

One idea I've had that I've mentioned before is a modification of swing depending on direction of saber movement. For example, you execute a swing from up to down, the saber takes a generic swing and slows the last 1/4 or so depending on the angle. You move from down to up and it takes the last 1/4 of the sound and speeds it up slightly.
I'm not sure how it would actually sound in reality, just in concept it seems to me that it would aid in reality.

Also, with the pitch bending of the normal hum, would it be feasible for the module to raise the volume of the hum slightly during pitch bending for a sort of "mini swing" effect?

[Madcow]

I love v. 3.0 as is!

The only thing I can suggest is...

I'd love to utilize the bargraph animations as a standby feature... when the board is active but the saber is off. ie - when the rechage key is out.

I'm a big fan of Erv's work, and his customer service.

Cheers,
MC

[xwingband]

CF has always been WAY above other boards so the GUI and all the fancy stuff is just the icing on our butterscotch cake. I'm happy as is with the software.

If you could save 2mm on width though I'd love it. My Parks sabers are an utter pain to fit the CF. It fits like a fat man in a speedo.

[sekrogue1985]

i just got my 2.6whatever repaired woots. this will be interesting the new board. yes size does matter a smaller board would be better because then one can then build casing for it to prevent for shock if your hilt ever get's hit and then **** happens and your SD card holder becomes dislodged. yeah... anywho Erv I'd like to say woots to the idea of the micro cards. as for this - RGB mode to drive a endor / prolight or multiple LEDs, but ONE at a time...i prefer the single LED stuff the RGB yet to get one or see what they do and what not. and not smart on that end. that stuff about the software very very interesting would make doing stuff much well more entertaining IDK. Over all i'll probably get one but yeah i like my board and the fancy stuff the board already does enough hahhaa.

[Jeescook]

Mac and vista support for configuring the sound fonts would be nice

[Onli-Won Kanomi]

Erv please forgive me if this is a dumb question I shouldnt ask but would the "RGB mode to drive a endor / prolight or multiple LEDs, but ONE at a time" also allow driving one of the WHITE endors [specifically thinking of the 540 lumen white Endor] with all the whites on full power??? I'd be very happy with a CF4 running RGB Endor for night uses but I'd be ECSTATIC with a CF4 running white Endor to 540 lumens!

[erv]

ONE led at at time, endor is composed of 3 LEDs.
I still have to check if my board can handle more power supply voltage to get a full endor (wired in serie) working with CF.

[Novastar]

CF has always been WAY above other boards so the GUI and all the fancy stuff is just the icing on our butterscotch cake. I'm happy as is with the software.

If you could save 2mm on width though I'd love it. My Parks sabers are an utter pain to fit the CF. It fits like a fat man in a speedo.

LOL @ fat man + speedo, hahahahahah

More like... raspberry jam and whipped cream on your buttered toast?

RE: RGB stuff...

Yup, this concept is best handled by Erv, but the general jist is... well, MOST RGB LEDs would require three separate drivers to drive each LED, all at possibly differing voltages and currents (although G & B are usually pretty identically driven). Anyhow... I think what Erv is saying is... you're not going to get *ALL* of the colors to individually behave differently... and you may not even be able to drive all of them at once. He'll have to further extrapolate.

However, WHATEVER the case--you could always:

CF goes to the "R" let's say...
direct drive + resistor/whatever to the "G"...
direct drive + resistor/whatever to the "B"...

or...

CF goes in series for G & B... (current needs to be set correctly)
R is set as the "clash flash" option w/ power Xtender.
or whatever combo you like.

etc.

Anyhow... let's see, a list of
What can possibly work:

* GUI... duh... oh! and many are mentioning MAC support--very good idea. I don't think it should be a problem *IF* it's relatively easy to do a workaround "copier" program/instruction set for the way the files are constructed on the SD. Macs add extra file headers and do weird things that are troublesome for CF... although those with Macs should play around--test it out. It won't hurt CF... it just won't work if the fonts/configs fail to "copy correctly".
* Reduce CF's size... looks like request is both a little < width, a little < length... but more requests thus far on width... by 2mm for X-wing... lol fat man + speedo. Ate too much Buttered T.
* "Bubble randomizer"... simple bubble sort when choosing a random # that might take up a bit more CPU, but prevents any one clash/swing sound from playing twice in a row (on a random or dynamic setting)
* Swing/clash SELECTION... that is, what acceleration range plays what sound (in a particular option) could certainly be more specific. Like swing1 = 0-32, swing2 = 33-64, etc. for a rough example. I don't know WHY this would matter too much anymore, but... I guess it could be done.
* Force "touch"... essentially a touch sensitive switch. This is "just another" switch, although yep, these can produce results that people might not want--despite how "good" it sounds. Depends.
* Bargraph indicators active during "idle"... this seems like a cool idea--maybe even an "idle" sequence and an "ON" sequence. After all, "on" would look quite alive and idle... should... uh... be kinda idle. Methinks.


Things that cannot work (for whatever reason provided, whether you think it is "good" or not is irrelevant, hehehh )

* Lockup w/o button press = possible but VERY complicated for so little ROI. No can do, no way, Furrgett it...
* USB = hellishly "complexifies" things. it's MUCH more than just "another type of connector", it opens an entire can of Pandora's whoop-ass that a small 8 to 10Mhz CPU just doesn't need to be burdened with... so... No can do, sister. Forget it! It's road nachos.
* Digital volume = too much CPU, too little ROI. Besides... if you don't want sound, I have another idea... put on iSaber mode. Don't play music. Turn on saber. Done.
* Swing / clash classification (more of a maybe instead of "no") = this may be better left to the user to define a "lighter" swing1 up to the most aggressive and "hardest" swing8 (or clash1-. Technically, I already pay attention to this with *MY* sound fonts. I know Erv does. I can't account for other folks' fonts.

That's the best summary I can give for now.

[erv]

excellent summary
for the bubble random mode, it's not really complicated, I'll see if I have some more RAM bytes to implement that !

[Novastar]

Awesome! The way I figured it, really two ways to do it... one using more CPU, the other--more RAM:
-------------------------------------
(quasi) Bubble sort 1 (possibly more CPU, especially if it picks the same number a few times in a row and has to go back for another):

Initialize: Rnd_num.
Initialize: Snd_last. It can also begin as 1, or whatever, 1 to 8.

Get Rnd_num.
If Rnd_num = Snd_Last... go back and get another, dangit!!
Got one. Set Snd_Last = the currently received Rnd_num.
Play the current sound as "swingX", where X is Snd_Last, # from 1-8.
...Aha, the user triggered yet another swing... (repeat)

It's alright. Not the most efficient, heheheh.
-------------------------------------------

Bubble sort 2 (more of an array, where the "used" number is left out until the new one has gone through a "round")

Initialize: array of 1,2,3,4,5,6,7,8.
Initialize: Rnd_num.
Initialize: Snd_Last.

Get Rnd_num from array.
Play the clashX where X is Rnd_num, # from array table.
Replace (or skip step if 1st run) Snd_last back into the array.
Set Snd_last = the currently received Rnd_num.
Remove Snd_last's value from the array.
Repeat when new clash detected...
----------------------------------------
NOTE: Personally, I like this one BETTER, since it SEEMS like it is more efficient... but I'm not sure, you'll have to do your stuff, Erv!

I realize my little "psuedo-code" may not actually HELP someone like Erv... (and I'm sure Edwin is LAAAAUGHING, heheh!!!) but it helps me to be certain that the idea is feasible and not some giant memory/CPU hog... by fleching out the details, giving myself a reminder of the old C++ days.

I actually used to use the first "bubble sort" in an old retarded text-only video game I wrote WAAAAAAAY back in the day! It was pretty neat, but... I was the only one of my friends who liked it, hahahaha...