plugView->attach not working correctly

Developer VST 3 SDK
1

I am developing support for VST3 into some of my VST hosts. I have a nearly working system now, but there is one set of VST3 plugins I cannot figure out. I have based my code on the “editorhost” code found in the vst3sdk. To my surprise, “editorhost” cannot either handle these plugins correctly. An exception occurs when attaching the

plugView-attached-exception
plugView-attached-exception1867×486 152 KB

plugView to a window. What makes this strange is that Cubase (and other host) can handle these plugins perfectly. What may be wrong in “editorhost” (and my code)?

2

Looks like the same issue as Plugin plugin window attach issue.

3

Yes, exactly the same! Sorry I did not see it. But the question remains: how come hosts like Cubase and Reaper and many others I have tested manage to show this editor window?

4

And the answer is the same, ask the developers of these plug-ins. The editor host is the reference implementation and plug-ins should work with it. I’m not aware of anything we do in Cubase different.

5

Well, I don’t think Roland will give me an answer. You surely must do something differently in Cubase. I actually think there may be something important missing from the editorhost sample.

6

I downloaded “Vst3SampleHost” from GitHub and it works (made 2019). Hope to be able to analyze the source code (C++).

7

Let me know if you find the difference.

8

I took a session with Claude Code and asked it to create a simple VST3 host just for displaying the plugin’s editor. Well, it took Claude more than five hours (and two separate sessions) to get this simple “editorhost” clone together. However, this simple host had the same problem with a certain plugin. I did not give up and spent a few more of Claude’s hours to fix this issue. We succeeded. I asked Claude for a summary of required fixes. Find it here:

forum_post_setComponentState_fix.zip (2.1 KB)

9

Hi,

I just tried to incorporate your fix into my VSTHost in attemtping to get a … guess what … Roland PlugIn (SH-101) to behave properly, but it failed miserably. The sequence

if (component->getState(&stream) == kResultTrue) {
  stream.seek(0, Steinberg::IBStream::kIBSeekSet, nullptr);
  component->setState(&stream);

leads to instant death in the PlugIn. With my normal sequence

if (!bSingleComponentEffect && /* only if proc & ctrl are separate! */
controller &&
(component->getState (&stream) == kResultTrue)) {
stream.seek(0, IBStream::kIBSeekSet, nullptr);
controller->setComponentState (&strm);
}

it works. So, greetings to Claude, but no. Not the solution to all things.
(My problem, BTW, is that I can’t get the SH-101 Arpeggiator to work and don’t know why, but that’s another story … and I just fixed it anyway :slight_smile: ).

10

Claude actually also proposed "controller->setComponentState (&strm); Without it it doesn’t work. This is the code:
Steinberg::MemoryStream stream;
if (component->getState(&stream) == kResultTrue) {
stream.seek(0, Steinberg::IBStream::kIBSeekSet, nullptr);
component->setState(&stream);

stream.seek(0, Steinberg::IBStream::kIBSeekSet, nullptr);
controller->setComponentState(&stream);

}

11

Yes, but the component->setState(&stream); is what kills the PlugIn. It doesn’t make any sense anyway to set the component to the state we just got from it.

12

Well, maybe. It indeed looks like component->setState(&stream);is not important. In my setup it doesn’t seem to hurt.

13

same here; Access Violation at 0x00000000 when using that line; without it, it succeeds