Multiple-Tracks & Button Configs?

[Benjamoose]

Hi there! First time Proffie owner here!

First of all I want to thank you sincerely for the effort of putting this software together.

As a tinkerer/modder I would have been capable of figuring out the process of setting up the Arduino, etc ultimately, to me it's needlessly tedious when something like your wonderfully robust and streamlined tool can exist in it's place.

As far as I'm concerned this thing should be the official way to manage a Proffie saber!

That's said, I have a couple of thoughts. Basically two road blocks I faced with no immediately obvious solution in the tool (road blocks that I imagine are much easier to resolve when building your own prop files and the like manually, but I'm also admittedly a newbie at this stuff):

1. I really wanted to take advantage of the many options in Fett263's drop-down, but wasn't yet ready to commit to learning a whole different setup for the button shortcuts. Could there be a way to use the "default" button shortcuts layout from one drop-down but still then have access to the other options in another?

For example; Fett263's drop-down has options for voice battery percentage. The others don't, but then I have to commit to a whole different shortcut list to use them.

But it's also completely possible that I'm just ignorant to the limitations of the system or missing something.

2. I installed a sound font that came with its own internal "tracks" folder with multiple tracks. As I understand it, it should be able to cycle between them on activating music. The problem I'm having is that when setting up a preset for the font (to add it to the roster as it were), it wants me to define only one track file with the ".wav" part permanently appended.

As I mentioned before, I imagine that's easier to resolve manually, but I couldn't seem to figure out a way to get it to just use that folder.

Other than that, this is my first ProffieBoard and I've been throughly impressed and thankful for your tool!

[ryancog]

As far as I'm concerned this thing should be the official way to manage a Proffie saber!

Why thank you, I sincerely appreciate it! :)

Could there be a way to use the "default" button shortcuts layout from one drop-down but still then have access to the other options in another?

This unfortunately is a limitation of the ProffieOS prop file system. Prop files contain all the button mappings for different controls, but for a lot of controls there is custom code to facilitate, for example, the voice battery percentage.

As it stands, there's not a "clean" way to do what you're wanting, due to the way certain prop-specific features and the mappings are intermingled. However, if you're willing to take a look at the code behind the scenes, it should be possible with relatively minimal effort to create your own prop file (based off another one) and add in the control you're wanting.

First, I'll explain things a bit: In ProffieOS there are so-called "prop files" which determine the button mappings, and certain other things. In order to present all the options of a prop file to you, ProffieConfig uses a "pconf" file that contains all the data about a prop file and its options.

So, there'd be two steps to this, copy the prop file which has the "base" controls that you like, and then add in the feature you want to it. The actual ProffieOS code resides within ProffieConfig's resources folder. The link below about .pconfs tells you where to find that.

I'll link this guide about editing/creating pconfs. It's not entirely complete (iirc it's missing explanation of the BUTTONS section, but looking through other props should make that pretty self-explanatory, and I can answer any questions if you're wanting to do this).

I'll also link this ProffieOSDocs page about making a prop file which gives a quick overview about how things kind of work inside those prop files.

Essentially, it should be as easy(ish) as

1. Copying this function into the prop file (at the top)
2. Adding these lines inside the SB_Effect function in your prop file (Check to see if the effect is already handled in your prop... you might need to replace it!)
3. Adding the effect declaration if it's not there already.
4. Adding these lines into the list of EVENTIDs. Once again double check to make sure this button mapping isn't already use.

And then you can create a new pconf and add the option and button mappings into it, and follow the steps outlined in the guide.

It's not "easy" per-se, but if you're willing to tinker it shouldn't be so difficult that I'd say it's not even worth trying. And of course, if you run into any roadblocks and/or are confused with anything, just ask. :)

I installed a sound font that came with its own internal "tracks" folder with multiple tracks. As I understand it, it should be able to cycle between them on activating music. The problem I'm having is that when setting up a preset for the font (to add it to the roster as it were), it wants me to define only one track file with the ".wav" part permanently appended.

So yes and no. Fett's prop file, for example, has a "Track Player" feature which does cycle through different track files and is able to play multiple. However by default in ProffieOS only a single track file is linked to a preset.

In this case, there's two different mechanisms in play: the default ProffieOS setup, and a custom prop-specific player that bypasses that completely to implement that multi-track feature.

Other than that, this is my first ProffieBoard and I've been throughly impressed and thankful for your tool!

Glad it's been helpful and things have been going well for you so far. Once again, if you have any more questions, comments, etc., don't hesitate to reach out!

[Benjamoose]

Why thank you, I sincerely appreciate it! :)

Absolutely! While I'm not a programmer, I've been messing around with stuff along these lines in the video-game modding scenes and working in game dev in various forms for the last 20 years, so I'm used to having to go through weird setups, tools, managers, and editing config files and the like.

But inevitably you're always waiting for someone to come along and make the tedium unnecessary with a one-and-done program, so when I saw your software I was like "yes!".

This unfortunately is a limitation of the ProffieOS prop file system... ...As it stands, there's not a "clean" way to do what you're wanting...

Ah, no worries. I figured this would probably be the case. I assumed that the software was just essentially carrying out edits for me and that something like this would probably be doable with merging stuff myself but would potentially be feature bloat and messy for the software to handle reasonably. No worries, I totally understand!

Ultimately, it's just a case of me having to "unlearn, what I have learned" with the button mapping, since a lot of sabers, mine included, came preprogrammed with the SA22C choice.

If I can just get my head around Fett263's preset, I'll probably be better off overall, haha.

So yes and no. Fett's prop file, for example, has a "Track Player" feature which does cycle through different track files... ...In this case, there's two different mechanisms in play: the default ProffieOS setup, and a custom prop-specific player that bypasses that completely to implement that multi-track feature.

Ah! Good to know. So, in the case of my situation, could I just:

1. For universal support and picking a single track as standard (SA22C, etc) ; direct right into the sound font's track folder and pick a track. Sort of like: Track: "fonts/FONTNAME/tracks/TRACKNAME.wav"* in the track box, then...

2. When using Fett263, regardless of what I have set in there, it'll just override based on it's cycling track player?

*I have my sound fonts in a "fonts" directory on the root of the SD card to try and keep things tidy.

Also, is there a cleaner/shorter way of doing this if so? I note that the box itself mentions that if a track is just sitting within the sound font's folder, you can just name the file, but it doesn't seem to work for ones in a "tracks" subfolder beyond that.

Glad it's been helpful and things have been going well for you so far. Once again, if you have any more questions, comments, etc., don't hesitate to reach out!

Thanks for offering future support and thanks for giving me a detailed breakdown of manually editing the prop file myself, should I so choose. It'll definitely come in handy.

[ryancog]

Ah! Good to know. So, in the case of my situation, could I just:

For universal support and picking a single track as standard (SA22C, etc) ; direct right into the sound font's track folder and pick a track. Sort of like: Track: "fonts/FONTNAME/tracks/TRACKNAME.wav"* in the track box, then...

When using Fett263, regardless of what I have set in there, it'll just override based on it's cycling track player?

Precisely, yep!

I have my sound fonts in a "fonts" directory on the root of the SD card to try and keep things tidy.

If you don’t experience any issues with this, then you’re all good. However I’ll note that this extra “layer” with a slower SD card (or busier blade styles) could slow things down noticeably. With Fat32 extra directories to traverse generally takes more time, so just something to be aware of.

you can just name the file, but it doesn't seem to work for ones in a "tracks" subfolder beyond that.

How do you mean? Does the software not let you type it in properly (in which case that’d be a bug), or can you type it in but it simply doesn’t work on the saber?

If it’s the latter, what exactly are you typing in?

[Benjamoose]

Precisely, yep!

Noice. It seems that the fonts that were previously dumping their tracks untidily into an SD root "tracks" folder are now no longer seeing their tracks. I assume this is just due to the different tracks format in the Fett263 prop file?

It is it because it's now using a "common" folder. As in, should I move the root "tracks" folder there? It's no big deal either way as I can always just put the individual tracks in a "tracks" folder inside the individual fonts.

If you don’t experience any issues with this, then you’re all good. However I’ll note that this extra “layer” with a slower SD card (or busier blade styles) could slow things down noticeably. With Fat32 extra directories to traverse generally takes more time, so just something to be aware of.

All good so far. Zero issues at all. But I'll keep this in mind!

How do you mean? Does the software not let you type it in properly (in which case that’d be a bug), or can you type it in but it simply doesn’t work on the saber?

It doesn't really matter, as I believe you clarified the correct usage, but what I was describing;

When you hover over the box to input the path/filename of a track, it gives you a little tooltip blurb that tells you that you have to path to where the trackname.wav is, but that if the trackname.wav is sitting inside the individual sound font folder's root area, that you can just type the track's file name and it'll be able to see it.

That's all I was really referring to.

So, basically, I was saying "given trackname.wav is actually only one folder deeper, is there a handy short way I can tell the box that without pathing all the way from the root of the SD card".

[ryancog]

Noice. It seems that the fonts that were previously dumping their tracks untidily into an SD root "tracks" folder are now no longer seeing their tracks. I assume this is just due to the different tracks format in the Fett263 prop file?

There's two different controls for tracks w/ Fett's prop. One to trigger the preset track and one to enable the "Track Player."

If you're using the preset track and the track worked on another prop it should still work.

It is it because it's now using a "common" folder. As in, should I move the root "tracks" folder there? It's no big deal either way as I can always just put the individual tracks in a "tracks" folder inside the individual fonts.

No, that shouldn't cause issues, but it's possible if your font folder had ;tracks added to it, Fett's prop file will erase that. (i.e. any additional folder directories besides ;common are erased)

If there's a tracks folder at the root of the SD Card, then you should be able to reference that with /tracks/ in the "Track File" entry. Note the leading /, which indicates to start looking at the root of the sd card, and not the font directory. (For example: /tracks/track1.wav)

So, basically, I was saying "given trackname.wav is actually only one folder deeper, is there a handy short way I can tell the box that without pathing all the way from the root of the SD card".

Yep, just (following from the earlier example) don't include the leading / and that'll do it.

Example being /tracks/track1.wav will point to a track1 file inside a tracks folder at the root of the SD card, but tracks/track1.wav will point to a track1 file inside a tracks folder inside the current font directory/directories.

[Benjamoose]

Oh, huh!

I only have ";common" for the voice pack, but that's interesting. Does that mean outside of Fett's file you could specify multiple folders at once?

Thanks for clarifying about the slash vs. no slash. I think it helped fix up all the fonts I already had for the new Fett file.

One of these days I need to go through and clean all the font folders up. The inconsistency in layout and file names drives my OCD nuts, haha.

Also, you'll be pleased to note I've already adjusted my memory of the combinations and Fett already feels second nature!

Edit: A bit unrelated, but three quick questions:

1. Is there a way to test sound fonts in the blade style editor? I know there is a way to upload individual .wav files to the browser version by Fett, but it'd be great if you could just point the .exe version at a folder then swing the 3D saber about and test buttons.

2. It was probably covered in the tutorial at launch, but what are the benefits of the blade array section? I find myself not really using it and have all my presets and styles under one array.

Is it just for organization? Like a category of presets (e.g. "original trilogy", "fun sabers", etc) or does it have a more technical usage like defining multiple blades or something (e.g. a cross guard saber).

3. Can I just stick things into folders in a sound font and them get recursively checked if they're non-track related? I noticed that some fonts have their sounds in subfolders that group them into sound types.

[ryancog]

Does that mean outside of Fett's file you could specify multiple folders at once?

Yeah. That's exactly what you're doing with ;common, in fact. Fett's just allows only ;common whereas on other props you can have a bunch. I've seen a few different use cases, but it's not super common. (no pun intended :laughing:)

Is there a way to test sound fonts in the blade style editor? I know there is a way to upload individual .wav files to the browser version by Fett, but it'd be great if you could just point the .exe version at a folder then swing the 3D saber about and test buttons.

Not that I'm aware of. It's a technical challenge to try and recreate the way the audio would sound on the board. When you mean .exe version do you mean what opens when you choose Tools->Style Editor? If so, then that's just a local copy of the ProffieOS Style Editor.

V2 will have its own Style Editor, and if you think it'd be useful I could put it on the todo to make it play font sounds. However it'd still only be the static effect sounds, not smoothswing. (The preview won't be able to swing like the aforementioned one due to, once again, technical limitations, but maybe just the normal sounds would be useful?)

It was probably covered in the tutorial at launch, but what are the benefits of the blade array section? I find myself not really using it and have all my presets and styles under one array.

Separate blade arrays are used for Blade Awareness. So, if you have different types of blades with ID resistors inside, you can change the blade configuration to automatically reflect that. If you have a removable chassis, you could add ID resistors or you detection to change effects based on whether it was removed or not. You could also just change preset arrays based on whether a blade was in the saber or not. Lots of those types of applications.

Is it just for organization? Like a category of presets (e.g. "original trilogy", "fun sabers", etc) or does it have a more technical usage like defining multiple blades or something (e.g. a cross guard saber).

Well, there's two parts to the blade arrays page. The first is adding/editing blades for a particular array. In which case, yes, a cross guard would be a good example where you might add another blade for the quillions.

To avoid confusion, the second is what I was referring to above was that you can have multiple blade arrays with completely different sets of blades with its own set of presets.

Can I just stick things into folders in a sound font and them get recursively checked if they're non-track related? I noticed that some fonts have their sounds in subfolders that group them into sound types.

Kind of. The sounds need to be in a subfolder whose name matches their sound type. If you've a hum file buried inside a stuff folder, it (to my knowledge) won't be found. It's ideal to group sounds into their own subfolders though. The FAT32 filesystem likes that (so long as there's more than one of that sound).

[Benjamoose]

Yeah. That's exactly what you're doing with ;common, in fact. Fett's just allows only ;common whereas on other props you can have a bunch. I've seen a few different use cases, but it's not super common. (no pun intended 😆)

Haha! I can't really think of a use case for myself, but definitely interesting. Any particular reason why Fett's strips it out or ignores it? Just a case of it not being overly used by the majority or something? As I say, I can't really think of how I'd want to use it.

Not that I'm aware of. It's a technical challenge to try and recreate the way the audio would sound on the board. When you mean .exe version do you mean what opens when you choose Tools->Style Editor? If so, then that's just a local copy of the ProffieOS Style Editor.

That's understandable, and yeah, I meant your tool. I didn't mean to make it sound so dismissive by reducing it to an executable though, haha!

V2 will have its own Style Editor, and if you think it'd be useful I could put it on the todo to make it play font sounds. However it'd still only be the static effect sounds, not smoothswing. (The preview won't be able to swing like the aforementioned one due to, once again, technical limitations, but maybe just the normal sounds would be useful?)

Cool! I figured that the 3D model reacting to SmoothSwing would probably be an unreasonable ask, but I also didn't know how it was set up internally, so I figured "you never know".

Yeah, that'd be great. It'd be nice if your version could have the option to point at a sound font folder rather than selecting individual files for each noise-type and could then play each numbered file randomly, similar to when it's in use on the saber.

It'd also be great if there were some "dummy" methods of making some animations. One of the things about the current blade editor, is that while having buttons and categories to generate the code you're after is definitely a much easier process than making it by hand, it's still a bit of a learning curve when I'd much rather be able to just jump in, drag the blade to create animations, etc.

I don't really know how you'd dummify/newbie-friendly the process that wouldn't be an unreasonable ask or become convoluted to set up, but just a thought.

If it were possible though, you could toggle between a "simple" and "advanced" editor.

Separate blade arrays are used for Blade Awareness. So, if you have different types of blades with ID resistors inside, you can change the blade configuration to automatically reflect that. If you have a removable chassis, you could add ID resistors or you detection to change effects based on whether it was removed or not. You could also just change preset arrays based on whether a blade was in the saber or not. Lots of those types of applications.

I sort of get it now, I think? Correct me if I'm super dumb and getting it wrong, but are you saying that in this use case, a blade array could define a physical neopixel blade.

So, say you had a standard neopixel blade and one of those fancy shmancy quad-star blades and had them set up that way with ID resisters to identify them, you could swap the blade in the hilt (or alternatively swap out the chassis with the proffieboard and put it in another hilt with the other blade) and suddenly have a whole different set of blade styles?

I'm trying to imagine a use case for that. I suppose like, you could have the same set of fonts and the same color styles, but when switching to a Kylo hilt you could have all your blade styles be unstable or something?

If I'm correct, I assume there's no real case where I could use that in the way I hypothesized?

To avoid confusion, the second is what I was referring to above was that you can have multiple blade arrays with completely different sets of blades with its own set of presets.

Haha! Forgive me, but I'm confused!

Basically, as someone with currently one neopixel blade and one hilt, is there anything I could benefit from by having more than one blade array set up? At the moment I've been heavily editing a copy I downloaded of the default config that the saber came with, so there's just one array called "blade_in" and I've been sticking all blade styles under that one array (as far as I understand it).

Kind of. The sounds need to be in a subfolder whose name matches their sound type. If you've a hum file buried inside a stuff folder, it (to my knowledge) won't be found. It's ideal to group sounds into their own subfolders though. The FAT32 filesystem likes that (so long as there's more than one of that sound).

Gotcha. That's what I'd seen, so I'd somewhat assumed, but wanted to be sure. So, if I wanted to group up "in1.wav", "in2.wav", etc. I'd make a folder called "in".

[ryancog]

Any particular reason why Fett's strips it out or ignores it? Just a case of it not being overly used by the majority or something?

He rewrites the folders so that it plays nice with his prop internally. I'd imagine it just makes it easier to handle the code if you only have to account for a single possible case.

drag the blade to create animations, etc.

I don't really know how you'd dummify/newbie-friendly the process that wouldn't be an unreasonable ask or become convoluted to set up, but just a thought.

You never know what might the future might hold...

I sort of get it now, I think? Correct me if I'm super dumb and getting it wrong, but are you saying that in this use case, a blade array could define a physical neopixel blade.

So, say you had a standard neopixel blade and one of those fancy shmancy quad-star blades and had them set up that way with ID resisters to identify them, you could swap the blade in the hilt (or alternatively swap out the chassis with the proffieboard and put it in another hilt with the other blade) and suddenly have a whole different set of blade styles?

I'm trying to imagine a use case for that. I suppose like, you could have the same set of fonts and the same color styles, but when switching to a Kylo hilt you could have all your blade styles be unstable or something?

If I'm correct, I assume there's no real case where I could use that in the way I hypothesized?

To avoid confusion, the second is what I was referring to above was that you can have multiple blade arrays with completely different sets of blades with its own set of presets.

Haha! Forgive me, but I'm confused!

Basically, as someone with currently one neopixel blade and one hilt, is there anything I could benefit from by having more than one blade array set up? At the moment I've been heavily editing a copy I downloaded of the default config that the saber came with, so there's just one array called "blade_in" and I've been sticking all blade styles under that one array (as far as I understand it).

Take a look at the Blade Arrays page:

Blade Awareness and Blade Arrays are two fundamentally interconnected concepts. There's two parts to Blade Awareness. Blade ID and Blade Detect. Blade Detect uses a latching switch type mechanism with a separate pin, whereas Blade ID measures resistance between (typically) your data pin and GND.

You can also use just Blade ID with an "infinite" resistance to emulate Blade Detect, but that's besides the point.

For example if you wanted to detect if a blade that's in at all w/ Blade Detect, and then also have an ID measuring for a neopixel (blade_in at 0) and tri-cree (tricree at 40000) to differentiate between the two, you could do it like this:

Now, you'll have 3 Blade Arrays, each with their own preset arrays. But how is this useful?

Well, first and foremost in the case of Tri-Cree vs NeoPixel, they either need to be controlled differently and/or should have different setups for length. In this case having a separate preset array might be a bit annoying (having them share a preset array is possible w/ ProffieOS, it's a limitation of ProffieConfig at the moment that they can't), but alas it allows you to control these two different blade types correctly.

Or what if you had a short 28" blade and a 36" blade? You could put ID resistors in them and then make sure the blades were set to the right length.

And in the case of no_blade vs having a blade, you might want only one preset in that preset array with some no blade type sounds. For example Sabertrio does something like this and when you try to ignite the saber there's a fizzle-out sound instead. You can also change bladestyles to act differently.

So there's a few different things going on here that are all kinda interleaved.

If I'm correct, I assume there's no real case where I could use that in the way I hypothesized?

No, not for having "Folders" of presets. Blade Arrays are really more focused on switching out hardware, with the ability to, as something as a side-feature, having different preset arrays.

Gotcha. That's what I'd seen, so I'd somewhat assumed, but wanted to be sure. So, if I wanted to group up "in1.wav", "in2.wav", etc. I'd make a folder called "in".

Exactly.

[Benjamoose]

You never know what might the future might hold...

Noice!

Blade Arrays are really more focused on switching out hardware, with the ability to, as something as a side-feature, having different preset arrays.

Got it. So, you could in theory do what I said about the Kylo hardware being an unstable array?

And in the case of no_blade vs having a blade, you might want only one preset in that preset array with some no blade type sounds. For example Sabertrio does something like this and when you try to ignite the saber there's a fizzle-out sound instead. You can also change bladestyles to act differently.

I really love this idea! I might give that a go! Create one sound font that's broken/fizzled out for when the blade is removed.

At the moment the array is called "blade_in". Does it matter what I call the arrays? As in, is that part of the detection, or is that just for my own reference?

Thanks for humoring me by the way. I've been enjoying chatting!

[ryancog]

Got it. So, you could in theory do what I said about the Kylo hardware being an unstable array?

I guess so? If you had another ID setup you could have a preset array that had a preset that had an unstable bladestyle... depends on what exactly you're looking for...

At the moment the array is called "blade_in". Does it matter what I call the arrays? As in, is that part of the detection, or is that just for my own reference?

Entirely for your own reference. There's some backend things that use it, and it'll be used for the names of the folders state files are saved in on the SD card, but it doesn't really affect anything.

To be honest blade_in is the default, non-renamable and non-removable because it would've been significantly more work to allow that. Perhaps it's something for me to revisit in the future.

Thanks for humoring me by the way. I've been enjoying chatting!

Of course!