Updating a Module

[utdgrant]

Definitely have a read of this thread, written by Andrew Macaulay. Andrew is constantly adding features to his vast collection of modules.

[Centripidity]

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.

[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.

[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

[honki-bobo]

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.

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).

[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.

[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