osxmidi / LinVst

Linux Windows vst wrapper/bridge
GNU General Public License v3.0
674 stars 41 forks source link

-DNOFOCUS compile flag not building #222

Closed Goli4thus closed 1 year ago

Goli4thus commented 1 year ago

Hi osxmidi, hope you're doing fine!

Couple weeks ago I did a long overdue update of linvst and wine. Specifically:

As I usually had done, I tried applying the -DNOFOCUS compile flag, cause I usually vastly prefer being able to pass through keyboard events to reaper compared to having all input being captured by plugin window (i.e. various shortcuts for controlling solo/mute and playback). I used Makefile-64bitonly.

During the build, I got the following error:

lin-vst-server.cpp:1580:12: error: ‘reaperid’ was not declared in this scope
1580 |         if(reaperid)
     |            ^~~~~~~~
lin-vst-server.cpp:1763:30: error: qualified-id in declaration before ‘(’ token
1763 | void RemoteVSTServer::showGUI(ShmControl *m_shmControlptr) {

I only looked a bit at the log and code. It seems there was some refactoring done that moved some related code to another file. I could imagine that this was simply overlooked by accident.

Without that flag I was able to build linvst just fine and am using it so far (albeit with unwanted focusing behaviour).

Maybe you can have a look!

osxmidi commented 1 year ago

Hi osxmide, hope you're doing fine!

Couple weeks ago I did a long overdue update of linvst and wine. Specifically:

* versions I was on:

  * wine: 6.13 (staging)
  * linvst: 3.15
  * linvst-x: git c5d7b6c (one commit before 4.1 tag (for whatever reason))

* what I upgraded to:

  * wine: 8.7 (staging)
  * linvst: 4.78 (specifically git [adf0fe0](https://github.com/osxmidi/LinVst/commit/adf0fe0aab8343f8edf5735652f427c1d6096094))
  * linvst-x: 4.78 (specifically git fa0308e)

As I usually had done, I tried applying the -DNOFOCUS compile flag, cause I usually vastly prefer being able to pass through keyboard events to reaper compared to having all input being captured by plugin window (i.e. various shortcuts for controlling solo/mute and playback). I used Makefile-64bitonly.

During the build, I got the following error:

lin-vst-server.cpp:1580:12: error: ‘reaperid’ was not declared in this scope
1580 |         if(reaperid)
     |            ^~~~~~~~
lin-vst-server.cpp:1763:30: error: qualified-id in declaration before ‘(’ token
1763 | void RemoteVSTServer::showGUI(ShmControl *m_shmControlptr) {

I only looked a bit at the log and code. It seems there was some refactoring done that moved some related code to another file. I could imagine that this was simply overlooked by accident.

Without that flag I was able to build linvst just fine and am using it so far (albeit with unwanted focusing behaviour).

Maybe you can have a look!

Hi.

Things have changed since version 3.15 and the no focus option needs to be added to the BUILD_FLAGS_WIN and BUILD_FLAGS_WIN32 lines instead of the BUILD_FLAGS line.

I didn't update the -DNOFOCUS info in the Makefile at the time of the change (I'll do it now).

There have been a lot of changes such as faster automation and a drag and drop version that enables drag and drop between the plugin and the daw for supported plugins, the makefile for that version is in the dragwin folder.

The Makefile should be like this for -DNOFOCUS

Makefile.zip

Goli4thus commented 1 year ago

Thanks! Then I just stumbled over those comments and assumed it's still the same. And I didn't think far enough that if that logic moved to lin-vst-server.cpp, it might need to be applied to BUILD_FLAGS_WIN. And yeah, certainly sounds like a good idea to use the newer version of linvst!

Anyway, the build works fine with that and I can see a different focusing behavior. That is, at least when it comes to spacebar handling.

But the behavior is still not what it used to be (I sound like an old man here...; or it's bit like this: https://xkcd.com/1172/).

Here's what it is now (according to what I see):

The behavior I'm used to from 3.15:

Arguably, the old behavior made inputting text into input boxes impossible, which certainly wasn't the greatest solution. Still, it was a worthy tradeoff for me so far, as most plugins allow for changing input values via e.g. keyboard modifiers and scrolling and I rarely had a need to input text otherwise.

Without knowing all the details that lead to this changed behavior, I can only assume it was done for good reasons (e.g. user feedback or your own judgement).

Therefore I think I should open a separate feature request opposed to writing more here.