Hosting Slate VCC, FG-X

[mystran]

Finally, I've found the cause for this misbehavior:

Moving processReplacing call to the main "audio callback" function of my host solves mentioned problems. Previously it was called from a separate, synchronized thread.

Looks like processing call not being 100% bound to audio interrupt is causing anomalies with GUI of these plugins.

That sounds pretty weird, considering most hosts these days will process on multiple cores, which implies processing in multiple threads. Maybe there's some problem with your threads .. especially on Windows you have a dozen ways to create threads, and the "correct" one is almost certainly _beginthreadex (maybe _beginthread works too, can't remember) and while some code (especially simple DSP code) might not care, the other options can skip CRT init or such (specifically CreateThread(Ex) would be a terrible idea).

[zabukowski]

Finally, I've found the cause for this misbehavior:

Moving processReplacing call to the main "audio callback" function of my host solves mentioned problems. Previously it was called from a separate, synchronized thread.

Looks like processing call not being 100% bound to audio interrupt is causing anomalies with GUI of these plugins.

That sounds pretty weird, considering most hosts these days will process on multiple cores, which implies processing in multiple threads. Maybe there's some problem with your threads .. especially on Windows you have a dozen ways to create threads, and the "correct" one is almost certainly _beginthreadex (maybe _beginthread works too, can't remember) and while some code (especially simple DSP code) might not care, the other options can skip CRT init or such (specifically CreateThread(Ex) would be a terrible idea).

I am using QT's thread classes.

It looks like it doesn't matter in which thread actual processing is done, what matters is that plugin's processReplacing must be called 100% in timing to have its GUI updated properly, otherwise it gets rather confused. So the key is when, not where. Note, that audio is processed correctly in any case.

As I said, VCC and FG-X are the only plugins which expose this kind of problem. I've talked with Fabrice Gabriel about this, as well. He didn't go much into details, but mentioned some kind of "buffer problems", which will be fixed in the future updates of these plugins.

Zabukowski

[mystran]

It looks like it doesn't matter in which thread actual processing is done, what matters is that plugin's processReplacing must be called 100% in timing to have its GUI updated properly, otherwise it gets rather confused. So the key is when, not where. Note, that audio is processed correctly in any case.

Oh ok.. sorry about it then. =)

[zabukowski]

I am slowly & nicely progressing with my VST hosting

But ... I've just encountered another misbehaviour ...

Using Slate's VTM, tape wheels are not moving in x64 version. But, they are working fine with 32 bit version !??!

Any ideas or hints ? I see plugin is constantly sending audioMasterGetTime to host. I currently don't handle this opcode. Is this required ?

Looks like Slate's plugins will provide me a bunch of special situations ...

Thanks!

[zabukowski]

Solved, set some with vsttimeinfo flags, now it works in x86/x64 ...

[metamorphosis]

I am experimenting with VST hosting in my app. So far I've managed to load and process audio thru many diff plugins (PSP, IKMultimedia, Nebula etc. etc.) without noticeable problems.

I have a problem with Slate VCC and FG-X, though. They load ok, controls are working. The only thing is that meters are not working, regardless of input signal.

VTM is surprisingly working

Does anyone know - do Slate plugins require some kind of special treatment ??

Thanks in advance!
Zabukowski

VBC certainly does - doesn't work on most older hosts, even in vst 2.4 form...