Hi guys, Although I'm not positive that I understand the current situation completely, I want to throw in my thoughts:
On 4-Dec-07, at 9:21 AM, Jan Jockusch wrote: > Hi Ben, > >> What you're talking about is not really "inner state" of the >> controller because the controller has no inner state (some do, some >> are programmable and can genuinely have different states which send >> different CCs, but I don't think the DM2 falls into this category) >> but rather is state specific to the application. >> > Well, yes, ideally they shouldn't have an inner state, and I'm > perfectly > aware of that. > > I'll try to be clearer. The DM2 has essentially two wheels, many, many > buttons, 16 of which have an LED beneath, and three CC-type controls > (joystick and fader). What I need is: volume control, bass, treble, > mids, flanger settings, speed settings, and so on and so forth. Many > more CCs than the controller has. > > My intuition would be to press a button, which then lights up and > tells > me: "you're in 'volume mode' now". when I turn the wheel, I change the > volume. I press the button again, the light goes out, I'm back in > 'scratch/scroll mode'. Different buttons could 'shift' the wheel into > different meanings, and because the buttons are in the center of the > wheel, the meanings could relate to the respective player. > > I know that this is completely non-standard and completely a matter of > taste. Different people would want different behaviour, and they > should > not have to reconfigure a kernel driver, let alone reload it to get > different setups. That's where the idea of a userland intermediary > comes > from. Different people may want different behaviour, but it's up to the driver writer to just pick something sane and go with it. If _you_ want this non-standard behaviour, then just code it. I disagree about where the userland comes in though... (below) > > > I still cannot see why this should be so harebrained. But you've once > set my head straight, you're welcome to do it again. > >> For the Xponent I implemented (within mixxx) one particular state >> change, such that the wheels were only touch sensitive when a >> particular >> button was toggled. For some other application I might have wanted >> that button to do something completely different, so it feels natural >> to me that all such interpretations of "state" are within the >> application, not the driver or even a userland intermediary. >> This is a borderline hack to begin with since it's sitting in EngineBuffer (no offense). :) On top of that, it's a hack to support one specific device. At least with the Hercules stuff it's rolled off into it's own classes. We should try to minimize this sort of thing in the future (somehow)... > See? Strictly speaking, I wouldn't expect mixxx to implement this > touch > sensitivity switch which doesn't seem to have anything in particular > to > do mixxx. Correct, but we're at the mercy of M-Audio's hardware here. Adding a mini statemachine to Mixxx to enhance support for one device might be acceptable if we can abstract it nicely, but otherwise it'll just add to our growing pile of unmaintained code. In your case, I'd implement the state machine in the driver (ie. emit different MIDI CCs based on whatever group is selected on the device). The rationale for this is as follows: 1) The device's ability to send N times more CC messages will be supported in ALL applications. 2) In device like my MPD24, the state machine is in the hardware itself in order to work with all applications. In general, keeping the state machine as close to the hardware as possible makes it harder for a coder to accidentally break the state machine. 3) Once your code is in the kernel, it's no longer your responsibility to maintain it, nor is it our (the Mixxx developers') responsibility. Keeping the icky bits in kernel space makes our lives easier. 4) Having the state machine inside Mixxx is essentially half of a userspace driver. Our experience with the Herc has shown that userspace drivers are fragile - One change in the kernel will break our application, and then we'll have a nightmare of trying to support a device which behaves different in different kernel versions. (This has happened.) End result: You just want to fire CC messages at Mixxx because it can be handled by existing code. The more device-specific code we have in Mixxx, the worse off the project is. Implementing additional MIDI controls inside Mixxx like Ben did with spread64 is the ONLY modification I'd endorse to the MIDI code right now because it doesn't clutter up the code and is useful for more than one device. (Bug fixes to the MIDI code are always welcome though.) :) > > > Now imagine implementing the 'shift' method I described above in > mixxx. > How complex do you want mixxx to become? And how do you want other > programs to benefit from that feature? > >> The only reason I can think of to have a separate translator, if it >> were >> capable of intercepting a certain event which would switch the >> device over >> to (easiest) a different MIDI channel or (more difficult) a different >> set of CCs, would be to make it possible to control more than one >> application at a time from a single controller. Whether anyone would >> want to do that is another matter! >> > The situation I described is not about one controller for many > applications. It is to use one physical control (a wheel, for > instance) > for many different CC settings. The receiving application should be > completely oblivious as to where these controls come from. > >> A logical way to do it would be to use Note On to switch a light on, >> and Note Off to switch it off. Some controllers use CCs but I think >> Notes are the right meme for something that is inherently either >> on or off. Of course, if your LEDs are variable brightness, >> or if you have say a VU meter which you want to offer as a single >> control rather than individual LEDs, a CC would be right. >> Unless your controller does soft-thru (ie retransmits what it >> receives) that you can't disable, transmit on the same MIDI channel >> that the controller sends. This makes it analogous to how synths >> work. >> >> If your LEDs are associated with buttons, using the same key number >> that the button sends would make life easiest. Otherwise, just pick >> numbers with some kind of logic to them according to the LEDs' >> relative >> positions or functions. Take a look at how the Herc and the M-Audio Torq Xponent do their LED controls before you code yours. (Again, shouldn't have to modify much/ any Mixxx code if you try to stick to the convention.... if one exists.) >> >> > Note on / note off sounds good. Using the same keys sounds still > better. > > > But Andre should also have his say in this discussion, since it's his > driver we're arguing about. Yeah, we should let Andre chime in on this too... Thanks, Albert ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
