Page 3 of 4

Re: Initialization Woes

Posted: Sat Feb 04, 2023 2:53 pm
by Steve W
I haven't started making VM modules yet, but this detailed discussion (as well as other recent discussions) are chock full of amazing insights and tips! Thanks!!

Re: Initialization Woes

Posted: Sat Feb 04, 2023 7:25 pm
by seal58
Hi Martin,

the link to your message is very helpful. Many thanks!
First I will create a small training module to get familiar with these data conversions before I might damage the real module.

Roland

Re: Initialization Woes

Posted: Sat Feb 04, 2023 7:38 pm
by seal58
Steve W wrote: Sat Feb 04, 2023 2:53 pm I haven't started making VM modules yet, but this detailed discussion (as well as other recent discussions) are chock full of amazing insights and tips! Thanks!!
You are fully right. It's almost impossible to be familiar with all knowledge categories. That's why I'm a member of several forums. I appreciate hints from user to user very much.
It takes time to read and understand other user's problems, and it takes time to write answers and examples. That lets me be very thankful to all the active members, who take their time for such help.

Re: Initialization Woes

Posted: Sat Feb 04, 2023 7:45 pm
by ColinP
I'd like to contribute more to this but am really busy but one thing I feel I should raise (given that in the other thread I recommended using strings to store states) is the problem of locale specific encoding of doubles.

I had a really nasty bug that I only managed to track down because one of my beta testers lives in Austria and was usng a German setup.

In the UK and USA we always assume that the decimal separator is a period but in many countries it's a comma.

So when formatting and scanning doubles be careful to handle this properly! Check out the java.text.DecimalFormatSymbols class.

Re: Initialization Woes

Posted: Mon Feb 06, 2023 5:27 pm
by seal58
This decimal separator can be very curious. When I enter a number value with an editable label, I often get exception error because I use the comma at the numbers block of my german PC keyboard, while string to double conversion wants a period. But when I edit a controller value in VM, I must use the comma.

Whith data handling it's going forward.
I created a test module with editable labels and knobs. That was published and tested in VM. It was a surprise, that all controls are restored after reloading the preset correctly, even when the module was placed within a huge preset at high CPU load. (Why not with my new developed module?)

Then I filled GetStateInformation() and SetStateInformation() with code and many Log() statements. That showed me that SetStateInformation() is processed twice within VMD. At first run variables contain their initial value that is set during declaration. At second run previously safed values will be set.

All worked fine with primitive variable types. First there was some trouble with restoring strings and I tested various methods. Finally I came to this with GetStateInformation():

Code: Select all

public byte[] GetStateInformation()
{
   ByteBuffer buffer = ByteBuffer.allocate( bufferSize );
   //
   String str = editableTextLabel.GetText();
   int strLen = str.length();
   byte[] stringBytes = str.getBytes();
   buffer.putInt( strLen );
   buffer.put( stringBytes );
   // 
   return buffer.array();
}
and with SetStateInformation():

Code: Select all

public void SetStateInformation(byte[] stateInfo)
{
   ByteBuffer buffer = ByteBuffer.wrap(stateInfo);
   int strLen = 0;
   //
   if ( buffer.remaining() >= 4 )     // 4 byte for string length
    {
      strLen = buffer.getInt();     // string length
      if ( buffer.remaining() >= strLen )
      {
         byte[] strByteArray = new byte[ strLen ];
         buffer.get( strByteArray );
         String tempString = new String( strByteArray );
         editableTextLabel.SetText( tempString );
      }
   }
}
Somebody of the manufacturers in this forum reported problems that occured, when an meanwhile updated module trys to restore from an old version data set. He supposed to save a version number at the beginning of the buffer. That can be used to handle different buffer structures for compatibility.

Thanks again for all helpful hints. I just learned a little more of Java. :D

Roland

Re: Initialization Woes

Posted: Mon Feb 06, 2023 8:43 pm
by UrbanCyborg
@seal58: Somebody of the manufacturers in this forum reported problems that occured, when an meanwhile updated module trys to restore from an old version data set. He supposed to save a version number at the beginning of the buffer. That can be used to handle different buffer structures for compatibility.
That was Andrew Macaulay.

Reid

Re: Initialization Woes

Posted: Tue Mar 21, 2023 7:20 pm
by seal58
Time goes by and I'm still struggling against unvisible enemies. I mean data restoring after a preset with a distinct module is reloaded.

Hereby I had to dive into VMD debugger timing and found this:

1 - After debugger is started with F5 key, module class is loaded. Debugger window appears and stays empty.
2 - Initialize() is processed. Though this is done very early, a Log from here appeares in ModuleDesignerTestClient.log only after step 4 is done.
3 - GetStateInformation() is called first time in order to save initial variable values.
4 - SetStateInformation() restores variable values with just saved data.
5 - Module "dummy class" has done it's job and gets deleted.
6 - Module class is loaded again.
7 - GetStateInformation() is called second time. Variable initial values get saved.
8 - SetStateInformation() is called second time. Variables get restored with their initial values.
9 - Module code seams to start running. Log() statements are executed. Outputs are displayed on output pane and logged in ModuleDesignerTestClient.log.
10 - Notify() reports controller events though module is not visible yet.
11 - SetStateInformation() is called third time. Now variables are restored with values that user modified before a previous module test was finished.
12 - Now first log messages come from ProcessSample().
13 - Module gets visible on debugger window.
14 - (test session)
15 - When debugger is closed, GetStateInformation() is called third time and saves last values to anywhere.

I tried to find a file, that could contain these saved data but I couldn't find any. I let Windows search for any file that might be created or modified at a distinct time. (including hidden, protected or system files) But - nothing.

These log file lines are the only hint of a save to operation:
17:05:37.733 saved test mode settings to vtSettings:
17:05:37.733 ****************** Log Test Mode Settings ****************
17:05:37.733 testModuleXPosition = 173
17:05:37.734 testSignalsModuleXPosition = 0
17:05:37.734 test mode polyphony = 8
17:05:37.734 cablesTree has 0 children, 0 properties
17:05:37.735 testSignalsState has 0 children, 10 properties
17:05:37.735 testSignalsExtraInfo has 0 children, 1 properties
17:05:37.735 testModuleState has 0 children, 43 properties
17:05:37.736 1 cabinet trees
17:05:37.736 cabinetsChild 0 has 0 children, 0 properties
17:05:37.736 Sending dmcTestModeSettings from client, 0 cables
17:05:37.737 CInterAppCommChannel::SendMessage: wrote 2236 of 2236 bytes; isOpen=1, part 1 of 2, 2777 bytes total buffer size, segment ID eed9afdab2e846e6b22289523b044700
17:05:37.836 CInterAppCommChannel::run: read 95 of 95 bytes; isOpen=1, 0 ms elapsed
17:05:37.836 Read: received ack for eed9afdab2e846e6b22289523b044700
17:05:37.841 CInterAppCommChannel::SendMessage: wrote 1013 of 1013 bytes; isOpen=1, part 2 of 2, 2777 bytes total buffer size, segment ID ff202f836a474cd1acf53e055069a651
17:05:37.842 CInterAppCommChannel::SendMessage: wrote 72 of 72 bytes; isOpen=1
17:05:37.843 Sending dmcQuitting from client
17:05:37.844 CInterAppCommChannel::SendMessage: wrote 34 of 34 bytes; isOpen=1
17:05:37.850 MIActionmsg: queuedMsgFromMaster
With GetStateInformation() I gave exact 1106 bytes as readable text back to parent system. That number is not mentioned in a VMD log file.

Re: Initialization Woes

Posted: Tue Mar 21, 2023 7:52 pm
by UrbanCyborg
Interesting list, Roland. I'd bet your 1106 bytes are in there; the sizes listed in inter-app transfer processes tally up to something just a little over that, so I'd bet that's the system data saved other than your specific data, your data, and some protocol bytes. Without a means of tapping those processes, it's hard to be sure. I wonder if there's a way to do something functional at various places in a module's startup code that would show up in the VMD log? Maybe the CA devs know of such a way.

Re: Initialization Woes

Posted: Thu Mar 23, 2023 1:27 pm
by UrbanCyborg
Colin, how are you using the DecimalFormatSymbols class? That's buried pretty deeply in the localization library. Are you just assuming that the user's machine will have the correct locale for his country already set, so that initializing this class for the default locale will work, then getting a few properties that might matter from this class for use in input/output routines? Or are you actually doing something more profound with the localization library? This one's going to play hob with my IO routines, which often use regexes; beast to arrange for a regex to vary by locale. :shock:

Reid

Re: Initialization Woes

Posted: Thu Mar 23, 2023 4:55 pm
by ColinP
UrbanCyborg wrote: Thu Mar 23, 2023 1:27 pm Colin, how are you using the DecimalFormatSymbols class? That's buried pretty deeply in the localization library. Are you just assuming that the user's machine will have the correct locale for his country already set, so that initializing this class for the default locale will work, then getting a few properties that might matter from this class for use in input/output routines? Or are you actually doing something more profound with the localization library? This one's going to play hob with my IO routines, which often use regexes; beast to arrange for a regex to vary by locale. :shock:

Reid
Hi Reid,

Nothing profound at all.

In my asString() code I use this at the end to guarantee that the .voltagepreset file always uses dots...

Code: Select all

   // locale fix...
   result.replace( ',', '.' );
   return result;

And at the beginning of my fromString() parser...

Code: Select all

   // handle locales that use comma instead of dot for decimal separator...
   DecimalFormatSymbols dfs = new DecimalFormatSymbols();
   if( dfs.getDecimalSeparator() == ',' )
      scan = new Scanner( string.replace( '.', ',' )  ); // convert dot to comma
   else
      scan = new Scanner( string );
So that the localized Scanner gets fed commas rather than dots if that's what it's expecting.

It did take me ages to get my head around this, even though it's actually quite simple! :roll: