Well, the good news is that I’ve managed to reproduce this gremlin, now I just have to figure out the cause and fix it. 
1 Like
Ah, excellent. Thanks Prof. I just started another thread on this in case my post got missed in the temp file mellee! 
Will delete it now…
Maybe the whole presets.ini file stuff should move to its own thread?
Tested a handful of my intended uses and it appears to be working as expected in all cases so far.
However, I did run into something that may need handling, “true” doesn’t set off a template error if used in a slot for an Int<>, so if you miss either WAVNUM or LOCATION parameter and input “true” it compiles without error but does not work as expected, which took me a little bit to discover.
So:
TrDoEffect<TrInstant,EFFECT_QUOTE,1,true>
and
TrDoEffect<TrInstant,EFFECT_QUOTE,1,-1,true>
will both compile fine BUT only the second one actually works when the blade is OFF. Took me a little while to figure out why it wasn’t working so may need to consider how to get a compile error on the template if true/false are in the wrong position.
This is because “bool” in C++ is just an integer type with 0/1 values, so anywhere it expects an int, true will also work.
There are ways to work around this I suppose, like:
- build True<> and False<> classes and use those instead.
- re-arrange the argumens to TrDoEffect so that we don’t have an
intand aboolnext to each other. - Some other magic that I haven’t thought of yet.
Yeah, I figured it was something with the 0/1 = F/T. Might be worth flipping the LOCATION and WHILE_OFF. I think LOCATION is the least changed parameter so moving to the end might help alleviate.
The counter-argument to that is that LOCATION logically goes with the event, and it makes sense to keep arguments that go together together. Not sure which way is actually better though.
Now that I know to look for it when something isn’t working as expected I’m fine either way, but other users may get lost trying to figure it out. If we’re worried about users I’d flip, if we’re worried about grouping we can leave, I don’t have a strong opinion either way.
So the gremlin turns out to be related to the clock control.
I’m not sure exactly what happens yet, but it could be that the clock dividers get thrown off.
I’m also not sure why it works without the display code, because it doesn’t seem to be directly related.
1 Like
I wish I could contribute somehow to finding the answer, but it’s way deeper than my knowledge goes already. The only thing that occurs - which I know you’re already on top of - is the fact that it works OK in OS 6.8. Which in my very limited understanding points towards the changes that were made to OLED function between 6.8 and 7.x, like the reading file configs backwards thing, or the thing where OLED effects are timed to wav files.
If I get time tomorrow, I may experiment with ditching the config file in the OLED folder and just leaving it all to run as per the settings in the hybrid_fonts.h file. Maybe that will make a difference? Or maybe I’m barking up a tree in completely the wrong district. 
Happy to go to another thread, but I’ve considered this item solved, given that the Python Script works to accomplish the core task. If we can just document, I imagine there isn’t much more to do there.
For Mac, it has solved the text editor issue (don’t need a hex editor any longer), and it has solved the most recent savefile issue. All in all, the script + Python Launcher on MacOS is the complete solution even for someone who has never used Python before.
Do we need to document a different process? Can I help in any way?
I can only contribute with my rather newby taste in programming, but getting new class seems like the foolproof solution. We don’t know what sort of mechanics we might need in the future and trying to re arrange parameter because bool is confused with int seems kind of broken. It will keep the API nice, avoid future user problems, and avoid any gremlims from the infinite monkeys that are we, the users.
Maybe the easiest thing to do is to not have a parameter, but to create a new style called TrDoEffectAlways<>.
I’m fine with that.
Ok, I think the gremlin has been microwaved now.
The fix is checked in on the github master (no zip file yet) please give it a try and see if it works for you.
1 Like
TrDoEffectAlways<> added (WHEN_OFF removed)
Hi, Ive been reading some but not all of theses comments, I was just wondering if alt sounds / kyber select 2.0 is on the 7.2 beta and if so could someone help me out with it, I don’t really understand the style code part of proffie yet
Alt sounds are in the beta, Kyber Select 2.0 will be built into the OS7 library after beta testing.
I am working on some demo styles with a few font makers for some of the new sound features but it will take time.
1 Like
Okay thank you (that sounds like fun) I cant wait for it to be ready its such a cool feature and opens up so many possibilities
Just tested it, and yep that seems to have cracked it! 
Thanks so much Prof!
If I asked what the problem was, would I understand the answer?