Page 2 of 2
Re: Updating a Module
Posted: Mon Mar 13, 2023 9:07 am
by utdgrant
Definitely have a read of
this thread, written by Andrew Macaulay. Andrew is constantly adding features to his vast collection of modules.
Re: Updating a Module
Posted: Tue Mar 14, 2023 12:59 pm
by Centripidity
utdgrant wrote: ↑Mon Mar 13, 2023 9:07 am
Definitely have a read of
this thread, written by Andrew Macaulay. Andrew is constantly adding features to his vast collection of modules.
Thanks. Very interesting and useful.
Re: Updating a Module
Posted: Wed Mar 29, 2023 1:58 am
by Centripidity
Another thing I've just discovered as an issue is controls that interact with one another. In the Slow-Scope it's possible to turn each channel on and off and this configuration was automatically preserved in the preset. I've just noticed however, that when I added the solo button, which interacts with the channel buttons, presets no longer reliably recall which traces were on or off.
Fixing has proven quite tricky.
Re: Updating a Module
Posted: Thu Mar 30, 2023 5:44 am
by UrbanCyborg
This was thrashed out in another thread, with no very clear answers. CA has told me that they intended to have a meeting to deal with initialization issues, and although I think it should have happened by now, I haven't heard anything else about it.
For the nonce, though, the way I deal with the issue is to make sure that any cross relations like that always use
SetValueNoNotification(). Remember that every notification gets called once during initialization for a new module, and twice for one in a recreated preset. Another minor mitigation is to set a flag in
initialize() that you test for and disable at the top of
ProcessSample(), allowing you to run a post-init routine to make sure things are set correctly. Not a panacea, because it isn't clear exactly
when initialization is complete, but it helps.
Check out
viewtopic.php?t=2405 to see the details we all worked out over time.
Reid
Re: Updating a Module
Posted: Thu Mar 30, 2023 6:48 am
by honki-bobo
UrbanCyborg wrote: ↑Thu Mar 30, 2023 5:44 am
For the nonce, though, the way I deal with the issue is to make sure that any cross relations like that always use
SetValueNoNotification(). Remember that every notification gets called once during initialization for a new module, and twice for one in a recreated preset.
Correct me if I'm wrong here, but I think
Notify() gets called during initialization for each GUI element at least once, depending on the state of the element, e.g. if a cable is plugged into a jack.
UrbanCyborg wrote: ↑Thu Mar 30, 2023 5:44 am
Another minor mitigation is to set a flag in
initialize() that you test for and disable at the top of
ProcessSample(), allowing you to run a post-init routine to make sure things are set correctly. Not a panacea, because it isn't clear exactly
when initialization is complete, but it helps.
My personal experience is, you don't necessarily need to handle this in
ProcessSample(). Actually you want to avoid handling this in
ProcessSample(), because it is not DSP code. If anyway possible try to use notification case
Preset_Loading_Finish or
Variation_Loading_Finish for this kind of stuff. That way you can, for instance, read data into "temporary" variables in
SetStateInformation() and write that data into their final variables in
Preset_Loading_Finish. This works great for me in my latest
VM Recorder update, where I used this method to restore the digital counter value depending on the content of the file name label (which gets overwritten during initialization process).
Re: Updating a Module
Posted: Thu Mar 30, 2023 8:00 am
by Centripidity
In my case I needed to handle the interactions better in my code. However, I was also replacing a 2-way switch with a 3-way and thePreset_Loading_Finish notification made it so much easier to keep backward compatibility with presets.
Re: Updating a Module
Posted: Fri Mar 31, 2023 12:28 am
by UrbanCyborg
Thanks, Martin. That's what I meant; it just got mangled when I said it.
Every
control gets either one or two notifications for each notification it can generate.
As for
Preset_Loading_Finish(), it's not a panacea, either, because any chained notifications will likely not all be finished by the time it runs. Of course, that's true for inserting a one-off function in
ProcessSample(), as well. I don't think it's too much of a hit to run such a function in just one iteration of
ProcessSample(), so long as it doesn't try to do too much. As I indicated, this isn't a solved problem, by any means. We really need some indication from the system as to when initialization
really finishes, including things that may have chained off of stuff set in motion during initialization.
Reid