There is nothing in the Renoise settings that allow you to turn it off. It simply has the focus function for those who hate to press a modifier key and click or don’t want to use the left mouse button for it.
I think it’s pretty unlikely that we’ll add some way to override the standard actions coming from your mouse. This is simply quite a pest for us.
If you want to add special behaviours to your mouse buttons (sending key-combos or macros, for example), this is really the job of your mouse drivers, not Renoise.
For example, I remember that my old Logitech SetPoint mouse drivers allowed me to assign key functions and other custom actions to the buttons, and it was also possible to choose which applications those custom actions applied to (so it’s not system-wide, for example). Hopefully you can find something similar.
It might also be possible to do something interesting with AutoHotKey. I’m not too familiar with it myself, but I do know that quite a few people here use it.
Yes, I understand that to make it configureable creates a bunch of new problems. And I agree that tools like AutoHotKey or GlovePIE are in general a better choice. Indeed was the usage of GlovePIE the initial reason for my request to disable the middle mouse button in Renoise. I wrote a GlovePIE Skript which translates middle mouse button clicks into midi messages:
// Translate middle mouse button clicks into midi message
// and send them via virtual midi cable/port (LoopBE) to Renoise
// Scan for our MIDI Out Device by name
var.name = "LoopBe Internal MIDI"
var.index = 1
var.max = midi.NumOutDevs
var.found = false
while ((not var.found) and (var.index <= var.max)) do
midi.DeviceOut = var.index
if (midi.OutDevName == var.name) then
var.found = true
midi.Button1 = Mouse.MiddleButton
//midi.Button1 = Swallow(Mouse.MiddleButton)
//midi.Button1 = Swallow(Keyboard.RightShift)
midi.Button1 = Joystick.Button2
midi.Button2 = Joystick.Button1
midi.ByteControl14 = Joystick.Button4
// PREVIOUS/NEXT TAKE
midi.PitchWheel = Joystick.x
midi.Button3 = Joystick.Pov1Left
midi.Button4 = Joystick.Pov1Right
In Renoise I map the midi message to play/pause action, so that I can start/stop playing using the middle mouse button. Normally I use the default space bar binding for that, but there are situations where the space bar just doesn’t work, because the Renoise window hasn’t the focus. This is especially the case when VST plugins with GUI are active and the Renoise “enable keyboard” property is set. When working with VST Plugins it’s really necessary to repeatedly start/stop playback in order to compare different parameter adjustments without ear fatigue. The middle mouse button comes in very handy for doing that.
So I managed to get the above skript working. Means: whenever I press the middle mouse button a midi message is sent to Renoise. BUT THE PROBLEM: Renoise also receives the message that the middle mouse button is pressed and I haven’t found any workaround to avoid that, yet. The mouse driver provides only on/off for the middle mouse button. GlovePIE provides a “swallow” feature that consumes the mouse click event, so that it isn’t forwarded to other applications, but this doesn’t work for Renoise, since Renoise obviously uses some kind of low level device access (DirectX or whatever). According to the GlovePIE manual it’s not possible to consume events on that level.
Conclusion: it seems that the only chance to alter the behaviour of the middle mouse button is to write a new driver for Win7 64 (not exactly funny), or beg for the feature to add a preference property for disabling the middle mouse button. Would this be difficult to implement ?
How about the solution where you get yourself a mouse that also has two side buttons?
There exist mice with 5 or more click buttons all together and these suit the purpose you want to use them for a lot better, plus you also have an extra mousbutton to program for other options.
In the other case you are really in the minority regarding such feature request, whether it is easy or not, it is another option required to add in a menu which will not happen to please only less than a handfull of people.
I have exactly such a mouse, but the problem is that the driver just supports the three Microsoft standard buttons. The other buttons are mapable to normal keyboard keys.
And if a VST plugin has the focus the keys are sent to the plugin - same problem. Maybe I could search for another mouse, though.
Regarding handfull people: ok I understand that another preference menu entry would bloat things up and so on. But what about something like about:config in Firefox, direct editing of XML preference file maybe ? Coding-wise this would be just a few lines of code I suppose. Other than that I guess that I’m not the only one who has the problem with the focus while using VST Plugins.
I regularly stumble upon that. The only chance to avoid it is a non-keyboard way like midi-controller etc… But this isn’t as handy as mouse/keyboard.
I use e.g. Kontakt and there I use for example the search field. I also use the voxengo plugins and like to enter values directly. Then I use e.g. DMG Audio Compassion which also provides handy text fields, where I like to directly enter values like compression ratios and so on. Moreover I’ve made the experience that a lot of plugins still receive text input despite I disabled the keyboard feature in Renoise. I guess these plugins also use low level API’s like DirectX to receive keyboard events, thus Renoise can’t effectively block them. The result is a mess where I never can be 100% sure if it really works as expected. For example Voxengo Elephant: “keyboard feature disabled”, space key is assigned to “play/stop”. I open the Elephant, open the Elephant mode editor (floating child window), turn a knob and bingo space doesn’t work in Renoise anymore, means I can’t stop/play the music while tuning Elephant’s compression settings. As a result I leave the “enable keyboard” feature always enabled. Thus I have at least a consistent behaviour. Nothing is worse than an inconsistent GUI / control system.
My experience is, that Renoises transport is - beside space key - best controlled by using MIDI-commands, because in this case no keyboard/mouse focusing issues arise. Also I can switch to any other windows application and still control Renoise. It’s GUI independent.
But as I’ve written above: MIDI-controllers are mostly a third component beside mouse/keyboard, and when editing or mixing it’s not efficient when I have to reach out for some midi button for every start/stop. I want to control start/stop at my fingertips. I tried even a foot pedal, but it didn’t work for me. Than I saw a video where Deadmau5 mixed a dubstep track in Cubase or Ableton. He had this workflow:
change a parameter, click the mouse (side button) = start playback and listen to the impact of the parameter change,
click the mouse = stop playback.
change another parameter, click the mouse and listen to the impact of the parameter change
click the mouse, stop.
and so on repeatedly
The big advantage of this workflow is: avoid ear fatigue, keep your ears fresh, make better mixes. This workflow is also recommended in one of my audio mixing books. BTW: I created the FullStop.xrnx exactly for this reason: immediate stop without delay or reverb tails. It’s a totally simple tool, but for me most important.
In general I focus on mixing a lot and try to optimize my workflow for mixing and a bit mastering. I use Renoise and Reaper.
I don’t think that disabling the mouse feature in Renoise would help you either in that regard if the plugins really abuse DirectInput themselves.
I myself was capable of routing some specific renoise play/stop functions to the special media keys on my keyboard, which were a great help as well and within handreach. But now am trying to get used to my BCF controller and frankly, it works pretty fine for what i need. I don’t know what kind of PC keyboard you have, but a lot of keyboards these days come with these buttons and there is a big chance they can be assigned in the Renoise shortkey assignment table (I could assign mine).
So far I had no problems with middle mouse button clicks inside plugin windows. Nonetheless, I have to agree that a plugin theoretically could react to middle mouse button clicks.
The media keyboard hint is indeed interesting, I’ll check this out. Did you experience any focusing issues with the media keys, or are those keys focus independent ?
BTW: I also used a gamepad together with GlovePIE and have to say that this works really great, especially if you want to record something away from keyboard.