As you probably know pretty well already, I don't use windows VSTi plugins that often (or at all), otherwise I could have stepped in earlier.
This issue might be caused by how Qtractor implements DSSI plugin hosting, and indirectly how DSSI-VST interfaces to actual windows VSTi plugins. In fact, there's some overhead dealing with starting and stopping playback, mute and unmute MIDI tracks, when in face of instrument plugins. For example, all plugins are de/re-activated momentarily to reset internal host buffers safely and that might just be the root of the problem you report. Although this procedure is tolerably fast on native plugins, it might be a terrible nag on DSSI-VST served plugins, with too many middle-men in between to get things done (qtractor, dssi, dssi-vst-server, wine, vsti; back and forward).
I'll investigate whether this (re)activation bureaucracy still applies. Until then, please would you give an example of a freely available VSTi plugin which can be tested against this issue?
As you probably know pretty well already, I don't use windows VSTi plugins that often (or at all), otherwise I could have stepped in earlier.
This issue might be caused by how Qtractor implements DSSI plugin hosting, and indirectly how DSSI-VST interfaces to actual windows VSTi plugins. In fact, there's some overhead dealing with starting and stopping playback, mute and unmute MIDI tracks, when in face of instrument plugins. For example, all plugins are de/re-activated momentarily to reset internal host buffers safely and that might just be the root of the problem you report. Although this procedure is tolerably fast on native plugins, it might be a terrible nag on DSSI-VST served plugins, with too many middle-men in between to get things done (qtractor, dssi, dssi-vst-server, wine, vsti; back and forward).
I'll investigate whether this (re)activation bureaucracy still applies. Until then, please would you give an example of a freely available VSTi plugin which can be tested against this issue?
Cheers