What is misleading here is that when the ‘z’ computer key is pressed, the Redux hexagonal ‘z’ button is greyed. It means that the computer keyboard key press is recognized by Redux, isn’t it ? Which would mean in turn that Ardour does not block the key, would it ? If there was no reaction on Redux part I could understand that keys are blocked. But there is reaction. Are you certain Ardour has a blocking role and if so, can you explain technically what it would be. This is Ardour 4.2.0.
If the hexagonal Z is reacting on the keypress it should work, yes. Have tested Redux in Ardour 4.0.something only, will check 4.2.0.
Regarding the not implemented function I meant “LXVSTPluginUI::forward_key_event (GdkEventKey*)”:
In the mixer view you’ll have an instance of Redux on your track. Click your right mouse button on it and go to the option ‘Edit’ (Don’t double click on the Redux insert to open up the GUI !!!)
Now the Redux GUI should open with the instrument AND you will see that popup box stating that this is a demo version.
Don’t click anywhere with the mouse!!! AND Don’t move the Redux window!! (This is really important!)
BUT, make sure your mouse pointer is floating somewhere inside the Redux window.
Hi, can’t do that. Because Redux does not start in editor mode. I would tend to think that the computer keyboard would work also when Redux is not in editor mode, but it does not. I use KDE.
From what avoca said it looks like a desktop manager issue. Then I fear there might be a dead end. I know as a fact that Paul, Ardour’s creator does not hold KDE in high esteem at all. Any bug fix that is related to KDE would be difficult, I fear, from that side.
Also check the little keyboard icon on the top right of Ardour’s plugin UI.
Thanks for mentionning this. Although, even when it’s green, the computer keyboard still does not work. In both regular use, and the ‘edit use’ described by 4Tey. When trying with 4.2.0, please use a desktop manager such as KDE, or the ones that avoca listed.
I know as a fact that Paul, Ardour’s creator doe snto hold KDE in high esteem at all. Any bug fix that is related to KDE would be difficult, I fear, from that side.
If it is bug in ardour which can be replicated then Paul or rgareus will have no issue with trying to fix it. If it is something on the KDE side then there’s not much he can do about it, report it to KDE.
If it is bug in ardour which can be replicated then Paul or rgareus will have no issue with trying to fix it. If it is something on the KDE side then there’s not much he can do about it, report it to KDE.
So far the keystroke is received by Redux since the hexagonal on-screen key responds. It is not clear that after receiving it, a desktop manager would prevent subsequent handling within the Redux application. Any idea how this could be ?
Hi, can’t do that. Because Redux does not start in editor mode.
On the preferences GUI tab of Redux there is an option to allow Redux to start in a non compact mode so you can see the hex keyboard from startup.
My two cents… If I was writing a Redux and I came across this problem my first point of call would be to triple check my code, not assume that Linux, window managers, Ardour was the root cause of the problem. In other words, when I program something on a computer (and it doesn’t quite work) I ALWAYS assume I’m in the wrong
Yup. Am working on it but will need more time for this to compile, debug with the latest Ardour and co on various Window Managers and stuff.
Right and Wrong in a fuzzy environment like Linux desktops is impossible to define though. It’s more about getting it “working” in most of such environments instead of getting it “right”
Also check the little keyboard icon on the top right of Ardour’s plugin UI.
Did a few more tests. The missing “LXVSTPluginUI::forward_key_event” implementation really seems to be the problem here:
Ardour’s window, which hosts the plugin window, grabs away key events, so Redux does not receive any key events. LXVSTPluginUI::forward_key_event is then responsible to forward the keys to the plugin window, when the plugin window is not a GTK window.
The hey keys in Redux’ UI do light up, because they poll the keyboard state, ask the system which keys are currently held down - they do not reflect the state of key events that got received by Redux.
I’m unfortunately not very familiar with GTK, especially not on Linux, so I’d forward this to the Ardour devs. If someone here has some experience with GTK and Linux development, any help would be very apropriated. Of course we’re very interested to get this working.
Just a thought. As a quick (only partial, as phrases would have to be edited with the mouse) side step around that unimplemented function for the moment. It may be possible to use VMPK (which turns your QWERTY into a piano keyboard) to send midi notes into ardour and then ultimately Redux
Are there any news about that issue on the Redux side or could any Redux dev comment on that?
Same issue is apparent with Reaper / Redux.
Original poster of said post here. Would be very interested as well in any news regarding this issue, as it affects whether or not I will buy the full license.
As I won Sononym or Redux I have to bring this topic up again. I discussed the topic with the Ardour devs and they said it’s likely a problem with Redux.
Redux works fine in Bitwig and Tracktion, but not with Ardour and Reaper. Hexagonal keys are flashing, but the notes don’t find their way to the pattern editor.
The “XEventProc” thing is now implemented in Ardour
So I’ve tried implementing it in Redux ´too to check if it’s working, but it’s not. Not exactly sure why. I’ll need to build and debug Ardour from sources to find out more info here. This unfortunately will take a longer while.
Basically, the reason why the keyboard in Redux is working in Carla, Renoise, Bitwig and Co, but not in Reaper and Ardour, is because the latter hosts are embedding the plugin window into child window frame. In order to receive/handle keys, the Redux window needs to gain focus.
The highlights in the Hex keyboard are generated by polling the global keyboard state. So they always work, even when the window is not focused.
