SynthLab SDK
|
If you want to allow the user to select any core for any module, then you have another pair of options:
Approach (1) above has the advantage that you will still pre-code the strings using the a priori information about the strings that you glean from the same sources as the previous section shows. However, the GUI may require some tricky kinds of controls that show and hide list boxes or drop-down combo boxes. In this case, your GUI will still trigger a call to the selectCore( ) function, but your GUI will adjust itself to reveal the module strings and mod knob labels for that core. You will still need to hard-code these strings using the same resources as the previous section.
Approach (2) is what the SynthLab projects use and assumes that you know how to manipulate your plugin GUI to dynamically adjust the string content at run-time. Note that this is going to be highly dependent on your plugin framework. It will also require that you come up with a plan for knowing which controls need updating and when to make these updates happen. There are several things to understand and ponder as well:
Although SynthLab is not tied to any framework, I have included a tiny chunk of code from the ASPiK implementation that will help get you started. The majority of how this object works is based on my own scheme of "update codes" which contain boolean flags encoded in individual bits of uint32_t datatypes. The only ASPiK dependent parts involve the ICustomView pointers which are used to dynamically update the string lists. I designed a helper object named DynamicStringManager that deals with the issue of dynamically updating the strings at run-time. You can find this object in the files:
files: synthlabds.h and synthlabds.cpp
Dymamic Core Procedures/strong>