Two things (for the dev)

[Rock Hardbuns]

I've been using Mu.lab to test my VSTis (on windows) and I've noticed two things you should be aware of:

Recorded notes are quantized (to buffer edges perhaps). If you set the buffer size to something big like 4096 and drag a finger down the keyboard you'll see the resulting notes bunched up at regularly spaced intervals. I'm guessing you are mangling your timestamps ?

Secondly, the "replace" function in the rack does not delete and recreate the window object, but rather keeps it around. This may be by design, you should be aware however that some VSTi:s depend on the parent window being destroyed and taking any children with it.
I don't think it's common these days, but if you get a crash after the replace or just a blank GUI due to a dangling HWND, you know where to look.

(If you want to be defensive, you might want to check to see that the window does not have children before you give it to a new VST.)

EDIT:
I just thought I should add, that I like mulab a lot. Very clean and easy to use. Cheers!

[muzycian]

I've been using Mu.lab to test my VSTis (on windows) and I've noticed two things you should be aware of:

Recorded notes are quantized (to buffer edges perhaps). If you set the buffer size to something big like 4096 and drag a finger down the keyboard you'll see the resulting notes bunched up at regularly spaced intervals. I'm guessing you are mangling your timestamps ?

It has to do with the realtime MIDI input;

I agree, there's room for further improvement here.

It's on the To Do list.

Secondly, the "replace" function in the rack does not delete and recreate the window object, but rather keeps it around. This may be by design, you should be aware however that some VSTi:s depend on the parent window being destroyed and taking any children with it.
I don't think it's common these days, but if you get a crash after the replace or just a blank GUI due to a dangling HWND, you know where to look.

(If you want to be defensive, you might want to check to see that the window does not have children before you give it to a new VST.)

When a plugin is deleted, it's editor window IS destroyed.

Why do you think the window is not destroyed?

The only thing i can imagine that you observe is:

When you "Replace" a plugin, then the old plugin is only deleted after the new plugin is plugged in.

So there may be a fraction of a second that the old and new editor windows live together, but this is technically 100% OK, imho.

Note that the (vst) plugins are not aware of this fact as they all have their own editor window.

EDIT:
I just thought I should add, that I like mulab a lot. Very clean and easy to use. Cheers!

Thanks

[Rock Hardbuns]

Hmm well, then something else is going on, because as far as I can tell, unless the child window destroys it self, some kind of leak happens.

I'll have another look at it and see if I can pin it down.

EDIT>
Turns out, I no longer have the code that caused this behavior. Basically it created a window and made it a child of the HWND passed from the host and if the destructor was called before the close method, it didn't call a destroy on the child. This caused some buggy behaviour with mulabs replace function, while deleteing and inserting anew VST worked.

But I don't think it's worth worrying about. I mostly posted it in case you get bug reports about it in the future or something.