VST3, Loading A Preset And Accessing State From Processor

[spoonman2]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

I'm writing my first (instrument) plugin using VST3 SDK, in C++ in Visual Studio 2022 on Windows. I'm having real trouble loading a saved preset. I'm using the supplied TestHost for testing. On loading a preset, it appears to call the Processor's method SetState(IBStream* state) and then the Controller's method SetState(IBStream* state). The problem I have is that while in the Controller::setState method I have no problem accessing the preset data from the variable state something like this-

Code: Select all (#)

IBStreamer streamer(state, kLittleEndian);
float testVal;
	if (streamer.readFloat(testVal) == false)
	{
		return kResultFalse;	//Read failed?
	}
return kResultOk;	

If I attempt the same thing in the Processor::setState method it just throws an error, like the state variable contains no data at all. I am presuming the Host should supply the same data as "state" in both calls, so I don't understand what I'm doing wrong.

I thought it might be the VST TestHost not working correctly but it does the same in Cakewalk. I'm completely baffled. Can anyone help?

[spoonman2]

mistakenly posted twice, apologies

[noizebox]

Are you sure it's not the other way around? Vst3 has 2 sets of states, a processor state, which is the state of the audio processor (all parameter values etc) , and a controller state, which is the state of the gui and everything that is unique to that and not part of the audio processing.

Iirc, a host calls Processor::SetState() with the processor state and then EditController::SetComponentState() with the same state, and finally EditController::SetState() with the controller state. Maybe not exactly in that order, but you get the idea.

[spoonman2]

Hi noizebox, thanks! I got the right hint on the Steinberg forum also a few minutes ago; I thought there was only one state to save, not both, so wasn't saving anything out of Processor::getState() so there was nothing to read back. As is often the case, it makes sense to me now I know the answer!