Carla does not store/load skin/color for LADSPA plugins

[bergfried]

When using a LADSPA plugin in Carla 2.5.2, it is possible to select a skin and color, and it actually works for the current session. However, saving a project file and then reopening it reveals that

• neither skin nor color are stored in the carxp file in the first place,
• nor are the respective values respected when loading a file manually patched to contain the relevant XML, e. g.

   <CustomData>
    <Type>http://kxstudio.sf.net/ns/carla/property</Type>
    <Key>CarlaColor</Key>
    <Value>255;0;0</Value>
   </CustomData>

   <CustomData>
    <Type>http://kxstudio.sf.net/ns/carla/property</Type>
    <Key>CarlaSkinIsCompacted</Key>
    <Value>false</Value>
   </CustomData>

as copied from an LV2 plugin where the skin/color feature actually works (i.e. is stored in the carxp file and later restored from that file).

Also, lines like the following appear in the log whenever one sets the color for a LADSPA plugin, for example:

[carla] Carla assertion failure: "fDssiDescriptor != nullptr" in file CarlaPluginLADSPADSSI.cpp, line 748

As already stated, everything works with, for example, LV2 plugins. So it might be a shortcoming of either LADSPA or Carla. It should at least be made consistent. That is, either

• remove the ability to set skin or color for LADSPA plugins in the first place, or
• store and load the the corresponding data in the carxp file.

Since we can see the skin and color selection actually working during a given session, I very much prefer the latter approach.

Please keep up the good work.

[bergfried]

I just experimented a bit more and found that, for LADSPA plugins, apparently, neither CarlaColor nor CarlaSkinIsCompacted nor CarlaSkin are stored in or read from the file.

Also, when you try "Move Up" or "Move Down" on a plugin, neither color nor skin are moved accordingly. Instead, they stay where they are, position-wise. This seems to happen even accross LADSPA and LV2 plugins, and is probably not specific to the types of the plugins involved. (This seems to be a different bug, but it might make debugging the other one more difficult.)