On Tue, Dec 04, 2007 at 01:23:38PM -0500, Albert Santoni wrote: > >> 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). :)
Where should it be? It's in there because all other decisions about movement through the track (scratching or nudging) are in there. > On top of that, it's a hack to support one specific device. I don't think so. I wrote it for the Xponent but there's absolutely no reason it couldn't be used on any other device with touch-sensor wheels like the VCI-100. Or even a device without touch-sensor wheels, just define a button as the touch sensor and you can switch between jog and scratch mode at will. That said, the decision about whether a separate button is required to switch that behaviour on or off is something that ought to be in the midi.xml file. What's needed, I think, is a way to assign (from that file) an initial value to a controlobject, and then it may or may not actually have a real controller associated with it. The mixxx code could then default the touch sensitivity state to 1, so that any controller can enable scratch mode from any button of their choice, while the Xponent midi.xml could set the initial value of that control to 0 and associate the extra button with it. Does that make sense? > At least > with the Hercules stuff it's rolled off into it's own classes. I don't think that's entirely true! > 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. True. But it won't be configurable from *any* applications. > 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. Who's responsibility is it? Just because a bit of code goes into the kernel doesn't mean it automatically gets maintained for free. In my experience that frequently *doesn't* happen because it gets harder to maintain. If the translator is a self-contained library, it would be quite small, easy to maintain, and willing volunteers should be easy to find. > Take a look at how the Herc and the M-Audio Torq Xponent do their LED > controls The latter doesn't, and won't ever until M-Audio drop the requirement to sign an NDA to get hold of the details. Btw the hardware is just "Xponent". "Torq" is the software. Pretend you care ;) Ben ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
