[Bug] Drag window of VSTi plugin... stop/snag sound with OSC Server?

(Win 10, R3.1.1 x64) I have noticed a specific Renoise behavior when playing a plugin (VSTi) and while it is playing I move the plugin window. The result is that all the sound that is playing is paralyzed (it stops and does not sound again until you release the mouse).

Is this behavior normal? I consider it very annoying. Why does moving a plugin window have to stop the sound?Is it some strange security measure?

I am using OSC Server and a step sequencer built with timers for one of my tools.

This behavior happens with all the plugins. It is moving the plugin window and the sound is lost. This prevents, for example, the use of Renoise for live playback.

Is there any option to deactivate that is related to this?

I will have to do more tests, but I suspect that the problem is generated by the use of OSC Server and the window selection change.For some reason, when using the OSC Server in a tool(for example, automatically using timers (in step sequencer)) to produce sound when playing a VSTi instrument, if the user drags the VSTi window with the mouse, he will experience strange things with the sound. The sound is blocked, stopped, or lengthened as if it were hooked. It seems as if through the OSC Server, if you are playing a note, dragging a window will force this note to always remain playing. That is, moving a place VSTi window causes strange things with sound when using OSC Server. Although I have not tried it, it may also cause editing problems when using OSC Server (sound + editing).

To check this problem it would be possible to do the following steps:

  1. Build a tool that uses OSC Server to play notes (produce sound).
  2. Load VSTi instruments into the instrument slots.
  3. Open the windows of VSTi instruments, for example, open 4 windows.
  4. Start playing with the tool, through OSC Server, to play the notes.
  5. While playing the notes (reproducing and stopping notes with OSC Server (use a timer or something that allows it), use the mouse simply to drag the VSTi windows and move them around.At first you are touching through the tool window (this window is selected). But the problem occurs when selecting the other window of the VSTi instrument or simply by dragging this window.
  6. Repeat steps 4 and 5 and pay attention to what happens with the sound.The sound can be stopped (locked) briskly or it stays “stuck” sounding. This should not happen. Any graphic movement should not influence the audio playback.

Is it possible that there is something inconsistent here? Some bug or bad programming that causes the simple movement of a window to block or lock the sound? Apparently, this does not happen if you do not use OSC Server. It is not something that breaks Renoise, but it is tremendously annoying. It should not happen.

Can anyone confirm this problem?

I suspect it is because, not having the tool window in the foreground, the OSC Server loses priority and is ignored and if there is some automatic command (such as using a timer to turn off a note), this command will be ignored. Then using a tool window with OSC Server together with VSTi instrument windows becomes a problem of reproduction. How to make the tool window (using OSC Server) not be ignored when the window is not selected in the foreground?

Note: maybe this topic should move to the scripting forums. But it seems something directly related to the use of OSC Server to play sound.

Edit:I think I can confirm that this problem does not happen when selecting or dragging the Renoise window (the tool does not lose priority). It only occurs when selecting or dragging the windows of VSTi instruments when they are playing (the tool loses priority and is ignored).

Please, could fix this?

Edit:I think I can confirm that this problem does not happen when selecting or dragging the Renoise window (the tool does not lose priority). It only occurs when selecting or dragging the windows of VSTi instruments when they are playing (the tool loses priority and is ignored).

Ah, what you have described is obviously annoying. I agree, it would be good to have this fixed. It’s a limitation of the Renoise API.

The scope is not limited to the OSC server - there are a few other gotchas.

For example, I have a few dialogs in xStream which are modal. I want to get rid of those, because a modal dialog blocks the script - just like you have experienced when moving plugin windows around.

In the case of xStream, it means that the selected modal will not produce any output while/if you choose to e.g. rename a model (as the rename dialog is a modal).

This is obviously not optimal, but in the case of those modal dialogs it can be worked around by replacing them with non-modal ones - so I never considered this a “biggie”.

But in your case, since there is no real alternative to moving plugin windows around, it’s a problem without a real solution.

Thanks for looking at this matter!!!

Ah, what you have described is obviously annoying. I agree, it would be good to have this fixed. It’s a limitation of the Renoise API.

The scope is not limited to the OSC server - there are a few other gotchas.

For example, I have a few dialogs in xStream which are modal. I want to get rid of those, because a modal dialog blocks the script - just like you have experienced when moving plugin windows around.

In the case of xStream, it means that the selected modal will not produce any output while/if you choose to e.g. rename a model (as the rename dialog is a modal).

This is obviously not optimal, but in the case of those modal dialogs it can be worked around by replacing them with non-modal ones - so I never considered this a “biggie”.

But in your case, since there is no real alternative to moving plugin windows around, it’s a problem without a real solution.

I am a little confused with your comments:

Ah, what you have described is obviously annoying. I agree, it would be good to have this fixed. It’s a limitation of the Renoise API.

Does this mean that an update of the Renoise API could solve this problem?

But in your case, since there is no real alternative to moving plugin windows around, it’s a problem without a real solution.

I understand that you are referring to the current state, in version 3.1.1 of Renoise. I’m wrong? Right now there is no real solution to this issue. So, is it necessary to wait for an API update?

We have not known anything for many months about possible future improvements, or your plans with Renoise.Taktik is informed about these problems?I remember that with the last update Taktik solved some problems reported by the users.As I understand, Taktik is working on another project, that’s why there is nothing announced with Renoise, road map, plans …Is there anything new I could know?

I tell you these things because I have not known anything about Renoise’s development, error correction, additions and all those things for a long time. If users are reporting things that we see that Renoise could improve, as is the case, will they finally be served?

Thanks again!

Does this mean that an update of the Renoise API could solve this problem?

The problem you are experiencing is due to the reliance on communicating with the OSC server via scripting, so yes.
And since Renoise API updates are tied to the program itself, we’ll have to wait for an update to Renoise itself.

Taktik is informed about these problems?

Everything important reported on the forum gets relayed, yes.

I tell you these things because I have not known anything about Renoise’s development, error correction, additions and all those things for a long time.

I’m not surprised, and would do the same thing if I was you -
but I can also understand taktiks’ point of view: honing one’s skills on something a little bit different must be a refreshing experience.

Don’t worry - 3.1.1 is not the last Renoise release. It’s just taking (a lot) longer this time :slight_smile:

@Danoise. Ok, following with my tests, the conclusion is that the window tool enter in “a kind of pause” when selecting or dragging any VSTi window. If you select, you may experience a short pause, and if you drag, until you release the tool it will be “locked”, paused. I suppose you already know what the cause is. I hope these comments help to solve it …I suppose that, if you use a timer, for example, it will also go into “pause”, although it does not use OSC Server. I believe that none of these scenarios should happen.

About the Renoise’s updates, it’s a small relief to know that everything continues, even if it takes a long time. Cheer up! Meanwhile, we will continue to play with the window tools :lol:.

Thanks!

FYI, there are more bugs with VST GUIs / popup windows in Renoise:

  • In some situations, moving a VST GUI control will heavily slow down the Renoise GUI in the background for the moment of the movement. (Seems to be the same problem as described above). e.g. happened here in Synthmaster1, but also seems to be dependent on the other loaded plugins? Maybe as soon as one of the plugin is bridged? (I never use the sandbox, only as a bit-bridge)

  • Bridged plugins’ GUIs won’t be updated, or updated on next click only, so it is not possible to see the change you just made

  • Some bridged and non bridged plugins do not show a gui at all since 10.11

  • An opened file requester will not close immediately after a song was selected for loading

  • A opened save file requester will slowdown the audio engine and GUI the more the longer the requester stays open, without any action. Try to save with a playing song using VSTs.

  • A error dialogue on Renoise start will overlap a song comment popup (for example if the template song contains a faulty plugin), making it impossible to close the comment.

So is it possible to run only the GUIs of plugins and the file dialogues in a separate thread/process? Some kind of “bridge light”, so it is not bridged for audio, only for GUI?

FYI, there are more bugs with VST GUIs / popup windows in Renoise:

  • In some situations, moving a VST GUI control will heavily slow down the Renoise GUI in the background for the moment of the movement. (Seems to be the same problem as described above). e.g. happened here in Synthmaster1, but also seems to be dependent on the other loaded plugins? Maybe as soon as one of the plugin is bridged?

FFX, thanks for report these things! I can confirm that this happens. Even just selecting the VSTi Renoise window can be momentarily blocked (UI+sound of VSTi), even if you select a VSTi that is not currently playing (even if “Run all plugins on startup (separate process)” is enabled).

I suspect that this is not just a matter of fixing the Renoise API, but also something under the hood of Renoise. For some reason, the selection or drag of the VSTi windows generates blockages, it is not optimized, and the graphic movement influences the audio.It is tremendously annoying.

This causes unbearable situations while you are using some VSTi and you need to move the place windows to sort the desktop. Imagine that you are using 4 VSTi’s that you need to have ordered on your screen for the control. If the audio is playing, it becomes chaotic!

It seems that Renoise works well with instruments loaded with samples. But if you use VSTi the stage changes, Renoise loses fluency when trying to move windows and it gives the feeling that even the VSTi is blocked/slow (UI and sound) when moving its window. All these things should not happen. It should be possible to move any window and the audio and the UI of the VSTi continue to operate smoothly and that the scripts tools do not lose their leadership when their window is not selected (window in the background or closed).

For the time being, I suggest that two issues related to performance be seriously reviewed:

  1. Treatment of textures + Renoise API, in dynamic tools (redefined objects, add_child / remove_child, visible = true / false (and movement with the sliders/rotary???)) can cause important graphic and audio blocks when textures are enabled (Preferences/Theme/Textures).
  2. General revision of the VSTi plugins treatment and your windows and audio (UI + sound of VSTi/s), both of the Renoise API and under the Renoise hood. This issue may be one of the most serious problems of the current version 3.1.1 of Renoise, since it directly affects the graphic interface and the sound when the VSTi’s windows are used, and possibly also affects the window of the instrument and the own selection of the instrument inside the instrument box, if it have a VSTi loaded (you may also experience blockages).