What if someone has 300 quotes?
I thought bits too. Would it be fair to, in the spirit of making a feature work, have a finite limit on it with an explanation that things will randomize unless you have more than 31?
We could put a define on it too like GLOBAL_NO_REPEAT RANDOM or something like that so it doesn’t have to use mem.
Haha 300 quotes is like a whole movie.
I feel like this should have its own thread at this point. Not trying to hijack this one which should be about more than just one feature.
1 Like
True, bitmap algorithms get tricky when you exceed the number of bits in the architecture, but it’s still doable. 300 quotes would be 40 bytes–the space for 10 integers per tracking variable, or 80 bytes–but to simplify the processing algorithm, you could cap it, if N>31, then your only option is random any, if N<=31 then you could choose “random any” or “random play once.”
My C++ is beyond rusty–but I’ve used bitmaps to track combination over time in large longitudinal data sets–it is space efficient and binary math is generally fast.
The code would look something like:
if (num_quotes <32 && RANDOM_ONCE) {
int N = rand() % num_quotes + 1;
if ((pow(2, N) <= remaining_tracks) && (pow(2, N) & remaining_tracks == 0)) {
do {
N++;
} while pow(2, N) & remaining_tracks == 0;
}
else if ((pow(2, N) & remaining_tracks) == 0) {
do {
N--;
} while ((pow(2, N) & remaining_tracks) == 0);
}
//play quote N
remaining_tracks = remaining_tracks ^ pow(2, N);
if (remaining_tracks = 0) {
remaining_tracks = pow(2, num_quotes+1)-1;
}
}
else {
//just play a random quote
}
just a thought.
That’s not the problem.
The problem is is to dynamically allocate space causes fragmentation, and I don’t want that.
Also, 40 bytes is too much, because there are 60+ EFFECT structs, and 40 * 60 = 2400 bytes.
Using one algorithm up to 32 files and another when you have more would work though, although it still has the problem of possible repetitions when you start over.
In other news, I’ve updated all the custom character Voicepacks to include the new msdacc.wav
“SD Card access”
https://www.dropbox.com/scl/fo/mv7ej0grlmv9rwtaedifd/h?rlkey=t20s7u0vfpt7csyu97zh86x3b&dl=0
2 Likes
Cool, but it’s a bit premature.
There are currently 28 new sounds required for a V2 voice pack, and there may be more once we get closer to release.
Btw, you or Fett263 feel like you need to add voice pack sounds, now would be the time to add them!
2 Likes
I don’t really have anything new for OS8.
1 Like
ugh now I read this. I was just updating all the Default Voicepacks too.
Oh well, needed to be done anyway.
Oh I see the 28 new ones now.
Hmm new sounds. We have “random”. Would “sequential” be good?
How about anything from this collection?
https://www.dropbox.com/scl/fo/hjav7oz6tu53vbqpti3f0/h?rlkey=qtuz8qka5cdfsxhanarep8t5a&dl=0
If you ask “how about X”, then the answer is always yes, and we’d end up with millions of files in a voice pack.
If you have a setting, or a menu, or an error message that you would like to use in your prop[1], we should add that. If you’re not going to use it, it can wait.
[1] or any prop for that matter, like maybe the blaster prop could use some voice prompts?
1 Like
I don’t suppose you want to add support for turning SD mount access on/off?
I think it will lead to a lot less SD card corruption…
TBH I haven’t kept up with this, what’s the intended use? If there’s things that improve overall performance I can have a look, although the next month or so I’m pretty limited on free time.
1 Like
Basically, it makes it so that you can compile with “mass storage”, but you still cannot mount the SD card until you enable it on the saber. The idea would be to add a “setting” for this in your menu and also update the config generator to add the required define by default.
The new mode-based menus I’m building have support for it, but obviously your prop is the go-to right now, so if you don’t have support for it, then nobody will use it.
Mounting can also be enabled with a serial monitor command, and eventually with the workbench.
1 Like
Ok, I can have a look, is there an example or where does the setting reside? What happens if Mass Storage isn’t loaded when uploading?
The actual code for it is here:
If you don’t have mass storage on, then the setting is automatically disabled right now.
I don’t plan on an onboard option for this. I think if you’ve got the hilt plugged into USB, then Arduino is open, and Serial Monitor is right there.
I would however ask if you’d consider an alternate command to make it more user friendly, something like “sdcard 1” to manually mount.
I suppose I could do that.
Are you planning to support the menu modes? (Because if you do, you get an option for this, basically for free.)
Well I am using ColorChange for sure, that’s done.
Still sort of need an overview of how the rest is all supposed to work though.
Inferring what’s happening by reading code updates doesn’t get me very far.
I think I’d like to throw DYNAMIC_BLADE_LENGTH on a dial.
Probably other things too, but I’d need to look / think a bit.
1 Like
Well, in the simplest case (using the same menus as the base prop) all you need to do is to bind a button to enter the menus, and make a couple of calls to the sound queue to make sure things play.
The system is designed so that a single define specifies what menus to use, and that define can go in the config file. Right now there is only one menu spec to choose from, but that is likely to change over time.
Making your own menu spec is obviously slightly more involved, but as you saw with the color change stuff, it’s set up to make as much code as possible re-usable, and you only have to write the stuff that is new or changed.
Either way, I’m working on testing my way through the menu system right now, and once that’s done I’ll write up some instructions for how to enable it so that more people can try it out.
Another feature that you may want to add support for is the FONT_PATTERN define. Basically, it lets you specify what the font path given a specific directory. The default is of course "*;common", but you could also set it to "*;voice" if you prefer. Or "*;common;voice" if you feel like you need two common directories. Or "override;*;common" or "override;*;extras/*;*/Proffie;common".
There are functions in strfun.h that converts back and forth between a single directory, like "TeensySF" and the full font path, which in the last example above would be "override;TeensySF;extras/TeensySF;TeensySF/Proffie;common".
One possible use case for this is to have font-specific voice packs. You could for instance do: "*;*/voice;common". You would need to create a “voice” directory in every font directory, and then you can (optionally) stick a voice pack in there to override the files in “common”.
1 Like
Could you just reword that? Seems interesting, I’m not sure I see how it’s different than the current usage though. Or how it’s prop specific?
*edit - Oh, I could see how if the prop is expecting files in a certain directory and/or writing paths how that could matter.
But the rest?
1 Like