search

cbdevnet / midimonster

Multi-protocol control & translation software (ArtNet, MIDI, OSC, sACN, ...)
https://midimonster.net/
BSD 2-Clause "Simplified" License
500 stars 48 forks source link

wininput: mouse wheel #65

Closed GralfR closed 4 years ago

GralfR commented 4 years ago

I didn't find a support for the mouse-wheel in the wininput backend. Would be great, if this was supported. My goal: use a midi-controller as a mouse on windows. Mouse-positioning is done by two midi control-changes, the mouse-wheel is turned by another control-change-event. This makes scrolling documents easier and even allows using MA2 encoders with onPC.

cbdevnet commented 4 years ago

Hey, cool idea! :D

One problem with the mouse wheel is that it is inherently a relative channel (it doesn't output an absolute position value, but only changes in the position). Full support for mapping these channels in a proper way is an open ticket for post-1.0 (#41).

I will probably add basic support for the mouse wheel to the backend a way similar to the relative axes in the evdev backend, which means users will need to configure a range in which the wheel's relative values will be applied, which can then be used as an absolute channel.

GralfR commented 4 years ago

No problem with relative inputs. Some controllers like the BCF2000 (and I think also the BCR2000) which have rotary encoders offer some kind of relative mode for the encoders. The encoder remains in some center position like 50%. If it is turned left, a value less than 50% is send. If the encoder is turned right, a value more than 50% is send. The distance from the default 50% is defined by the speed, the encoder is turned. Maybe this could inspire some ideas...

cbdevnet commented 4 years ago

Yes, there are several different ways to represent these relative changes as absolute values (as is often done with MIDI controllers), but the problem I'm referring to is that currently, the MIDIMonster works on the mathematical basis of being able to normalize and denormalize channel values to translate events.

Normalization as a mathematical concept only makes sense on absolute values (where you have a reference/range against which to normalize). Since that's not possible with relative values directly, workarounds are in place until I have figured out how to properly handle this for all cases.

Implementing one specific way of encoding relative changes (such as the BCF one) unfortunately still leaves out all other backends.