Initialization Woes

[UrbanCyborg]

Yeah, that's what I thought you meant. I guess you don't bother with group separators. Thanks for the response.

Reid

[ColinP]

Actually I've just spotted a bug in my code!

Code: Select all

   result.replace( ',', '.' );
   return result;

...should be...

Code: Select all

   return result.replace( ',', '.' );

As strings are immutable in Java so the result object doesn't change and the new string created by replace() is just being thrown away.

This means that some presets for some of my modules originating in locales that use a comma as the decimal separator won't load correctly in locales that use a dot.

I'll get that fixed tomorrow and submit for approval.

Edited to add:

It turns out I got the code right everywhere except in the Granular Synth. Build #113 of GS fixes the problem and is already available (thanks to Danny).

As a lot of us have come from C/C++ where strings are mutable it's worth noting that they are immutable in Java as it impacts on how one thinks about things. It's important to distinguish between string objects, references and variables. String objects can never be changed but string variables can be, but only by making them reference a different (still immutable) string object.

[seal58]

Here is an update to main topic.
Now (after 10 weeks of research) I assume that I found the reason why variable restoring failed when my module was reloaded.

As I mentioned before, a module seems to be loaded twice each time. At first time initial values will be stored with GetStateInformation() and restored with SetStateInformation(). At second time VM restores switches, sliders and knobs to their states at a previous session. These settings provide event messages in Notify() even when the module GUI is not visible yet. At that time not every variable or control has got it's final value or state.

Though I tried to prevent code from execution when distinct control events occured, it did not work all time because not all used boolean switches were restored correctly yet.
At least I created an init interval by counting samples in ProcessSample(). Notify() became divided into two blocks:

Code: Select all

Notify()
{
   if ( !init )
   switch( notification )   // all events, that need to use restored variable values and control states
   {
      case ...   
      ...
      break;
   }

   switch( notifikation )  // all events, that will work alltime
   {
      case GUI_UpdateTimer:
      {
       ...
      }
      break;

      case Named_Timer:
      {
      ...
      }
      break;
   }
}

After an init interval of 48000 samples duration (= one second) the code worked as it should. (Mostly, but that'll be another story.)

Some time ago I sent a feature request to CA support for a VoltageLabel.SetValueNotification() method. Now I recommended the use of SetValueNotification() instead of SetValue() when VM restores GUI controls state. That might fix variable initialization issues. I wonder what CA team will think about that.

Roland