gogins / csound-vst3-opcodes

The "vst3" opcodes enable Csound to host VST3 plugin instruments and effects.
GNU General Public License v3.0
5 stars 2 forks source link

Get program change example working in the VST3 opcodes #16

Closed gogins closed 11 months ago

gogins commented 11 months ago

I know that this can be done because the JX10 unit in the mda example does change programs on command from the VSTPluginTestHost app from the VST3 SDK. So, there ought to be a way for my opcodes to do the same thing.

But I don't see the source code for this app. In fact, Steinberg says it is closed source.

How does the program change work???

gogins commented 11 months ago

Can't find working sample code for this. I'm looking at the Steinberg forum here: https://forums.steinberg.net/search?q=program%20change%20%23developer%3Avst-3-sdk.

Also see https://forums.steinberg.net/t/can-a-vst3-instrument-plugin-receive-midi-program-changes-from-the-host/871552.

https://forums.steinberg.net/t/editcontrollerex1-mandatory-in-any-plug-in-since-vst3-3-0-1/884545/2, but I'm doing this and it doesn't help.

https://www.kvraudio.com/forum/viewtopic.php?t=597225

gogins commented 11 months ago

I have instrumented the JX10 unit in the mda example. I have proved that the current program number is indeed changed by Csound, but the new program is not then used. So, there must be some additional step that must be taken.

gogins commented 11 months ago

I need to call Controller::setParamNormalized instead of, or in addition to, what I am doing?

gogins commented 11 months ago
vst3paramset::kontrol: id: 1886548852  value:    0.8627  delta_frames:    0
Process 77550 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
    frame #0: 0x000000010388e0c8 mda-vst3`non-virtual thunk to Steinberg::Vst::mda::JX10Controller::setParamNormalized(unsigned int, double) at mdaJX10Controller.cpp:169:21 [opt]
   166          {
   167              BaseController::setParamNormalized (i, JX10Processor::programParams[program][i]);
   168          }
-> 169          componentHandler->restartComponent (kParamValuesChanged);
   170      }
   171      return res;
   172  }
Target 0: (csound) stopped.
warning: mda-vst3 was compiled with optimization - stepping may behave oddly; variables may not be available.
(lldb) print componentHandler
(Steinberg::IPtr<Steinberg::Vst::IComponentHandler>)  (ptr = 0x0000000000000000)
gogins commented 11 months ago

I don't have the componentHandler. All the example code presumes it, because the examples presume program changes come from a user interface, whereas here they come from Csound. I'll try a dummy component handler.

gogins commented 11 months ago

With the mda examples, I don't see how to get this to work. Perhaps I should try with the Pianoteq, which may implement program changes in a different way. No, it doesn't do program changes at all, as far as I can see.

gogins commented 11 months ago

Where is the preset data? In the mda JXO, is that in the controller, or in the processor?

It is in the processor, as a global static array of parameter values.

Is there any way to read through this data and update the parameters using the processor's API?

I now have them updating in the controller, but they're not hitting the processor!

gogins commented 11 months ago

I figured out how to do this.

The opcode will send a program change parameter. In the preprocess function, the opcode must then turn around and query the controller for each parameter in the preset, and enqueue the new values in the process data queue for the next process call.

This was not documented by Steinberg, and I did not find it mentioned online.