Read the code again, and you’re right.
It looks like currently it won’t play the spin until after the first swing sound is mostly completed. (depending on the overlap) and then when it plays the spin that becomes the “swing” sound, so it won’t start another one until that one is completed.
Not sure if that’s what we want or not though.
Personally I like how this works currently, especially if “Fade out the spin sound when we (a) start a new one (b) stop spinning (c) turn the saber off” is introduced.
This way a longer file will play until the end, depending on the overlap setting.
It also means if you fall below the SwingStrengthThreshold then the current spin will fade into the new spin, for shorter tracks this works will with regard to the pitch/frequency and speed of swing like you mentioned.
For longer tracks it should mean that it’ll fade the current long track and start a new track.
Sounds ideal to me
Sorry I’m unfamiliar with the current change process, do these new ideas go into testing and then into a beta version of ProffieOS and finally into a live release?
I only downloaded ProffieOS from the main site last week (ish) and I think that was V6.9. I see 7.14 is available already, it moves so quickly!
I’ve made lots of changes to my fonts and bladestyles and my presets.ini file hasn’t been updated, I was a little hesitant to update as I think I saw in the notes that there’s a writeback from the saber to the SD card, presets.ini and if certain things are missing the board will lock up.
Will the saber write the current config back to the presets.ini and overwrite the old content?
I don’t it’s relevant unless I add the #define SAVE_PRESET anyway.
It looks like I should be able to do the above and it’ll write the current config back to presets.ini anyway, if I’m not mistaken.
Yes.
First changes are checked into github, on the master branch.
Once we feel like we have what we want, a new branch is started with all new changes. That branch will be called 8.x, and it will go through alpha and beta stages before becoming the new stable branch. No new features will be “relased” until that happens. However, all those features are still available on the github master branch, they are just not very well tested.
It’s been a couple of months since 6.9 was the main release.
Do you have KEEP_SAVEFILES_WHEN_PROGRAMMING in your config file? That tends to cause a lot of problems.
This only happens if you have KEEP_SAVEFILES_WHEN_PROGRAMMING and you change your config file so that the styles used in presets.ini cannot be found anymore. The solution is to not use KEEP_SAVEFILES_WHEN_PROGRAMMING.
If you don’t have KEEP_SAVEFILES_WHEN_PROGRAMMING then ProffieOS will simply ignore your old presets.ini and write a new one as needed.
If you don’t have SAVE_PRESET (or any of the other defines that enable preset saving) then all of this is moot, because presets.ini will never be created on your SD card.
You don’t need to do this unless you use KEEP_SAVEFILES_WHEN_PROGRAMMING.
Thanks a lot, that’s incredibly helpful.
I have a presets.ini so I’m guessing that was enabled in the config that came with the saber and was later removed or not added to a new config.
Just to confirm, is it on Github /profezzorn/ProffieOS that I should be looking for unreleased features?
I’d love to start playing with the spin changes as soon as I can get my hands on it 
Yes, that is correct.
I will most likely have some changes for the spin code later today or tomorrow for people to try out.
Perfect thanks, I’ll grab it when it’s available and keep you posted on the results 
@profezzorn Just about to flash the latest from the Github repo.
Are there any parameters in config files to look out for?
Or should the spin just fade out now under these conditions?
No new config variables to look out for.
I’m also in this camp. Good summary of viewpoints! If this were the old kung fu days, you would have made the ‘internal’ vs ‘external’ argument
Anything fun to test? Nice work @Ranger !
Hey thanks!
Figuring this out has been an absolute blast, not exactly what I do day-to-day for work but close enough that I can lean on my experience.
I’m in agreement with Profezzorn, for the saber fonts it’s epic having something like Proffie.
The weight, feel, sound, it’s all incredibly impressive!
I also want to take this slightly away from sabers though, there’s so much that we can do with this tech.
I like putting together themed fonts, whether it’s an anime one like Trunks sword or a mellow space-themed one.
If you’re interested I could put up a video somewhere showing what I mean, but in saber talk it looks like this.
Natures Storm:
Bladestyle from Fet263 - Thunder and lightening
Hum - soft music, the kind that makes you think deeply
swingh/l - electric/static sounds
swng - Thunder clashes
spin - light rain sounds
The idea is almost to feel alone in the elements, the music lays a perfect backdrop to relax and spin to, all the sounds are designed to act as a 3d layer, providing more immersion.
Of course it’s far from what Proffie was designed for, presumably, but it does it so so well.
the small things I’m mentioning here are really to find out what’s possible with the controls we have and what Proffezzorn might be willing to consider adding to allow for finer control in these less common theme fonts - although they are definitely starting to pop up more and more!
Why would the hum be the music when the “track” can be the music?
Good question
The main reason is the dynamics and control having it on hum gives you.
I could absolutely be wrong as I haven’t studied the configs but when playing a track it seems that it’ll play in the background whilst everything else is playing.
The speakers in the LGT sabers have a pretty sub-par speaker, there really isn’t a lot of room in terms of frequency because the speaker flattens the sound profile, there’s no staging and it’s a single speaking so mono, meaning no depth from stereo or panning options.
All due to it’s size of course, can’t really be helped.
With music on hum you can control the hum duck, this is really important for sound engineering because in order for sounds to work well together you need to carve out space in the sound for other frequencies.
If I had music playing from a “track” and not a hum, lets say that track had high hats in it, that would be around 20,000hz on the top end, if a saber accent swing or something was in the same frequency the sound would be very muddy, just sound like garbage really.
In an ideal world you’d work with high and low pass filters to remove certain frequencies so that other sounds can fill that gap, allowing for multiple sounds to be played with clarity.
Due to the speaker limitations we have to rely on some of the features you have for ducking, this makes carving out space a little less important. As the volume of the hum drops other sounds can take the frequency space without it sounding muddy.
You can think of it like this: playing a “track” is like covering the bottom of your speaker all the time, and using a hum is like having the speaker uncovered, there’s a lot more clarity in the sound.
If you’re trying to make a really good sound font that will bring the saber to life, you have to think about the frequency space, otherwise the sounds themselves will be of a good quality but in application, they will sound terrible in comparison.
Initially I thought about upgrading the speaker on the saber but realistically the bulk of people using Proffie or LGT-type sabers aren’t going to do that, so when creating fonts I think it’s important to use the equipment that the font will be most widely used on.
Having duck really allows us to keep a lot of the frequencies in each sound file because we can simply lower the volume of one sound when another is playing. This means more diverse frequencies can be used for each sound, rather than having to do something like this if you were using track:
Hum - base heavy saber sound
swing - mid frequency sound
Accent - high frequency sounds
Here you’d want to cut some mid frequencies from Hum to avoid muddying the hum/swing
Cut lower frequencies from swing if needed as not to muddy hum/swing
Cut the higher frequencies of swing as not to muddy swing/accent
Cut the lower frequencies of Accent as not to muddy swing/accent
Obviously this depends hugely on the frequencies within each sound, which sounds you can duck and which ones you can’t, etc.
For this reason, hum works very well as a track in my opinion.
I definitely need to look and play with this more though as I’m far more familiar with other aspects of Proffie than I am with the specifics of “track” at this point in time.
What do you think? Would love to hear your thoughts
IMHO, ducking needs to be done extremely carefully, because it’s very easy to make it sound terrible when you do it. Excessive ducking is unnatural and sounds unnatural.
For the most part, I think it’s better to let the dynamic compressor handle these problems and just play the sounds on top of each other. The dynamic compressor will automatically duck a bit when the overall volume goes up.
(Note, dynamic compression also sounds bad when you do it too much. Some radio stations use 12dB compression with look-ahead, and you can hear how the volume goes down before every drum hit, which is annoying.)
Now, ducking can also be an effect that creates a certain sound, but that’s different.
Pumping and breathing on purpose has indeed become an musical effect, sucking everything away to make room for the kick. I hate it lol.