@Christoph-Hart Thank you for wading through my message, and taking the time to thoughtfully respond. It means a lot to me as a (one of many) developer(s). (Thank you, @d-healey, as well.)
stuff that changes internal behaviour (eg. CACHING). When I implement this I will not be thoroughly testing it in all possible use cases because there are too many. And then I'll deactivate it again like 99% of all users which marks it for instant deprecation / regression.
I see your point — isn't that accounted for by making it a preprocessor flag, tho?
On the other hand having a queue not work by default is an instantly recognizable problem which you can address while actually writing the function (BTW the broadcaster system is automatically switching to a queue based messaging if it's necessary so when you eg. attach a broadcaster to a single parameter of a single module, it won't queue because it assumes to just use the current value, but as soon as you're attaching it to one or more sources it assumes that it needs to update all changes so the queue is enabled automatically).
I hear you saying some of these things are instantly recognisable (if I understand you correctly), but I'm not sure that's always the case—if something doesn't seem logical as causing a problem, we may not look there for a solution, regardless of obvious the problems was (once you know).
…lead to clogging and a sluggish UI performance…
Understood, but as a developer, I'd prefer sluggish first (and working), then optimising.
I have to look again but I vaguely remember that you can already recall the default user preset (if you're using that feature). If it's not there then it's definitely a valuable addition.
Default preset, yes (though no Callback flag); Default Values, no. I may be missing something, but I'm confused why Default Values seem linked to Presets—what is the benefit of them as a shared feature, verses the flexibility gained by keeping them separate? Like maybe…
Default Value: The value assigned to a component upon creation (in the compiled plugin), and the double-click value.
Default Preset: Values for starting with a specific configuration.
Also a bit hesitant about deactivating this (and therefore clearing out the globals with each compilation). Might lead to subtle glitches that nobody will encounter because it's not active.
Absolutely—but would it be problematic as a preprocessor flag? I'm thinking new developers here, who might not expect global persistence.
I remember you experienced this somehow but I actually don't see a reason why it wouldn't be ordered - sure some things are executed on different threads, but they should all end up in the console queue in a chronologic fashion.
(Understood - I only included it after seeing another user's post about the same issue.)
Script files should be saved though but I think I've added this a few weeks ago (somebody was complaining about external files not being saved with compilation and the fix for this should also implement the save script on save.
(Thank you — I am one of the guilty.)
However this is a thing that I could add as a function (just like setEnableQueue() with the default being on so you can deactivate it.
Be still my heart…
Yeah, I'd rather spend an evening with a glass of red wine and the default preset system to ensure that it behaves sanely than to branch between different opaque execution options.
👍
Can you elaborate on this? I would assume that all callbacks are executed.
I meant that the preprocessor flag I'm suggesting would change this behaviour, so no Callbacks were selected. (Currently, all my component callbacks are wrapped in "if-than"s to ensure they don't fire on startup, because their correct functionality depends on various states.)
I'm not sure if you've checked out the default user preset system yet but it covers a few of the things addressed with these suggestions. The defaultValue property is still useful if you want to change the double click position of a slider (which is almost always zero) from the initial state when you load the plugin (and I'm excluding Protools here because they made the decision to fuck up this distinction on their end).
What I could add is another sanity check that checks if the default value deviates from the value in the default preset and prints a warning (or even autocorrects it).
Indeed—I love (almost) everything about the Default Preset system, particularly that there are Callbacks for before and *after. I remember your note about Pro Tools in the docs…hurray for Avid.
My plugin has over 50 GUI widgets, all of which have different states depending on the other widgets and such…for my case at least, the Default Preset system is the GOAT except for the automatic Callbacks on registration (because none of them are ready to do anything).
Thanks again for your replies and thoughts. 🚀
