Test VST3 opcodes

[gogins]

Instead of VST2 presets and programs, VST3 uses units and programs that are implemented under IEditorController. It seems program list data is saved in a PresetFile. A component can support unit preset data via the IUnitData interface or the IProgramListData interface, but the host doesn't need to care about that.

When a plugin (rather, Component and Controller) saves its "complete state," that means the number of its current program and the state of all the parameters and metadata for that program only. There is an ambiguity between the terms "program" and "preset" but the VST3 SDK continues to use "preset" for persistent programs, so I also will do that.

There is no external preset storage in the VST3 SDK, but there is a MemoryStream that grows. The PresetFile can write to and read from a MemoryStream. Its buffer can than be written to or read from external storage.

For Csound, typical use cases can be supported by loading and saving individual programs, so I am going to remove the bank load and save.

• [x] The first thing to do is add program list information to vsts3info.
• [x] Remove vst3progset. It seems VST3 plugins don't always enable this and if they do it is by using a self-defined parameter. That can be done in Csound using vst3info and vst3setparam. Not quite sure how to create a new program.
• [x] Change vst3bankload to vst3presetload.
• [x] Change vst3banksave to vst3presetsave.

[gogins]

Sound is now good! It basically seems to be working.

• [x] Clean up the code. I got rid of the tutorial base classes from the Steinberg SDK and removed unnecessary methods.
• [x] Use valgrind to check for memory leaks and to profile the code. There are no apparent memory faults and not much leaking, and it's hard to say where the leaking really comes from. The opcode state deletes at the end as designed. As for profiling, the OpcodeBase::audio call for the plugin has 22% self and almost everything else is in the plugin. So, the copying loops are definitely incurring some overhead, but it is not fatal.
• [x] Resolve "Main" ambiguity with busses. I will not make an issue of this at this time, as it does not seem to be a real issue.
• [x] Test effect with audio output and input.
• [x] Add the editor UI if possible. Not doing this now.
• [x] Test parameter input (and output?). Input tested.
• [ ] Test preset saving and loading.

[gogins]

The host's ability to open a plugin's editor window was written with no thought at all of avoiding main. I may not be able to use or adapt this code. But first I will try just calling main.

[gogins]

I am leaving GUI support out of the initial release.

[gogins]

One more run of valgrind:

==8386== 
==8386== HEAP SUMMARY:
==8386==     in use at exit: 170,368 bytes in 226 blocks
==8386==   total heap usage: 46,083 allocs, 45,857 frees, 23,212,483 bytes allocated
==8386== 
==8386== LEAK SUMMARY:
==8386==    definitely lost: 9,480 bytes in 12 blocks
==8386==    indirectly lost: 4,408 bytes in 32 blocks
==8386==      possibly lost: 0 bytes in 0 blocks
==8386==    still reachable: 156,480 bytes in 182 blocks
==8386==         suppressed: 0 bytes in 0 blocks
==8386== Rerun with --leak-check=full to see details of leaked memory
==8386== 
==8386== For counts of detected and suppressed errors, rerun with: -v
==8386== Use --track-origins=yes to see where uninitialised values come from
==8386== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

The 2 errors are in the mda Ambience plugin, not directly in my opcodes.

[gogins]

One more run of callgrind. Not too bad. Not much overhead between the vst-opcodes code csound::OpcodeBase<VST3AUDIO>::audio and the actual plugin code (non-virtual thunk).