On Thu, 2007-12-06 at 23:18 +0000, Ben Wheeler wrote: > 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.
Your code checks the value of a ControlObject and performs some tweaks to the rate in response. All of this can be done outside of EngineBuffer::process(), and since it's sitting in the heart of the audio processing right now, it's out of place. The other code in EngineBuffer::process() is: - Fetching a buffer of audio from the reader class (checking how much we have decoded already, waking the reader if we need more audio) - Performing pitch stretch - Unfinished looping stuff (which shouldn't be in there) - Unfinished auto-crossfader stuff (also shouldn't in there) - Updating the play position - Unfinished ramping out stuff I don't think it fits in, but I'm fine with it staying where it is for now. There are bigger things to worry about... (and EngineBuffer:process() is going to get a grand cleaning one day anyways, so don't worry about it.) > > > 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. Fair enough, I didn't know that. > > 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? I find it hard to understand this touch sensitivity stuff without having seen what the hardware behaves like, so I'm in over my head here. > > > At least > > with the Hercules stuff it's rolled off into it's own classes. > > I don't think that's entirely true! hercules.cpp and herculeslinux.cpp? :) This isn't a fair analogy anymore though because like you said, your touch wheel code* is just a generic control that can be used on any device. So my argument that it should be rolled off into it's own class doesn't hold because it's not only for one device. *avoiding using the word "hack" > > > 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. Perhaps I misunderstand - I'm saying you won't need it to be configurable. You'd just have a button that acts like a bank switch which changes the CC #s for each of the controls (all at once). > > > 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. I completely disagree because of the nature of the beast here. This is a MIDI driver and the only maintenance it will need is when there's an API breakage inside the kernel. The kernel developers WILL ensure all drivers are fixed if they change the aseq API. That's how it works. Do you have any specific concern over having a MIDI driver in the kernel? > > If the translator is a self-contained library, it would be quite > small, easy to maintain, and willing volunteers should be easy > to find. > It's never easy to find volunteers to help maintain stuff, don't kid yourself. If it was, we'd have had 1.6.0 out the door months ago. :) But honestly, why make more work by splitting this up into the user space? So that 10 users can rearrange the buttons on their $50 controller? Is that worth the effort? > > 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. Damn those LEDs... > Btw the hardware is just "Xponent". "Torq" is the software. > Pretend you care ;) Ahhh, the whole bundle's called "Torq Xponent", and since you can't buy the Xponent part of it without the software, I assumed that's what the hardware was called. Good to know. :) The only reason I'm involved in this DM2 MIDI discussion is to make sure we keep the amount of device specific code inside Mixxx to a minimum. You guys can do whatever you want, just don't make life more difficult than it has to be. Albert ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
