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