Ruby & REAPER 64bit

[Drnkhobo]

No worries Nubeat, I added the code you mentioned and it still wont work. The mouse cursor changes when you hover over it, but it doesnt do anything when you click on it. I do think its an issue with the bridge though...

[Drnkhobo]

So I tried adding other Ruby elements (knob, button) and they seem to work... maybe there is an interaction function that the editbox does not have in it? Im not that good at Ruby so I wont be able to tell... Nubeat?

[Nubeat7]

after there are no specials inside the code i also would assume that its an DAW based issue... did you try without the cursor style definition?

[RJHollins]

ahhh ... the 'dead in the background' issue

It affects my 32-bit system as well [using Reaper].

It's not just 'edit boxes' .... which I believe NuBeat had resolved. Additionally, I had made a tone generator that is affected and will stop working when the plugin loses 'Focus'. I've never personally tested on 64-bit systems [don't have], but I wondered if the bridging [with floating GUI window] can add to the de-focus and lose of operation.

I'll follow this thread closely ... thanks Guys.

[MyCo]

Might help:
In the recent version of FL-Studio they have changed the keyboard handling because of the vst-bridge stuff they added. Now the problem is, that some VST Plugins like to take away the keyboard focus, so instead of controlling FL-Studio with the keyboard, you actually control the plugin. There is an option in the VST-Wrapper called "Don't allow keyboard focus", that fixes this issue, by blocking the plugin from taking the focus. Anfortunatly this stops any keyboard action inside the plugin.

MAYBE, other hosts use this option per default?
Image-Line explained: the reason for the keyboard problem is because of the wrappers being seperate executables. I guess that would be true for other hosts with 32/64bit wrappers, too.

[tulamide]

Image-Line explained: the reason for the keyboard problem is because of the wrappers being seperate executables. I guess that would be true for other hosts with 32/64bit wrappers, too.

That's a very good hint, MyCo! For Reaper I can tell that there are several options from running embedded (one Reaper + several plugins = one process), running seperated (Reaper one process, all plugins in a second process) and running individually (Reaper one process, each plugin in its own process). Since Reaper uses its own bridge, I'm not sure how it will additionally influence these process settings.
Also, many DAWs must seperately be activated to run in the background. So, if the focus is lost to the bridge and the background option not activated, the plugin will not execute.

[Nubeat7]

ok tested in reaper 64 bit, its a very strange behaviour, first i thought cool my plugins are working well, which they do as long as play is active!

when you stop playing the mess starts it looks like it is losing the focus then, it saves the actions and when you click on the sequence or outside the plugin window it gets updated...

thats what i found out till now i will investigate a little more..

[Nubeat7]

ok, i found the problem, reaper per default closes the audio device when stopped playing!

if you unset this flag in the audio settings (under preferences) it works also when not playing!

i don't know why ruby doesn't work when audiodevice is there but not connected or closed - you also can see this when you save a project in FS with your soundcard activated - disconnect the soundcard and activate the project, then there is no audio device connected and all ruby components don't work! maybe this is an issue which could be solved by FS.

I also think that this behaviour was introduced in 3.06 or maybe earlier, but i'm not sure if it always was like this or not... i only know that i recognised this in version 3.06

i don't know if it could be stated as bug, but maybe it should be stated to malc!?

[MyCo]

seems to be related to the bug fix for version 3.0.3:

Fixed an issue with muting exported VST plugins in a host where Ruby events would stop being processed

[Nubeat7]

while it is only happening in the bridged version where the plugin is opened in an extra window while in the 32 bit version of reaper the plugin is inside the reaper plugin window which doesn't affect the usage when not playing..

i also recognised that (i'm testing it with the asio4all driver) in the 64 bit version of reaper there is always a little popup window in the lower right corner of the screen that asio4all is started or closed (in the default settings of reaper) which doesn't happen in the 32 bit version.. so its difficult to say for me where the problem is based

but for shure the 64 bit version of reaper handles this setting in a different way then the 32 bit version...