On Tue, Dec 04, 2007 at 03:21:57PM +0100, Jan Jockusch wrote: > 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. > > 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.
Sure :) Ok, I completely understand and agree with what you're trying to do. I'm just not sure whether having some kind of daemon is the best way to do it. I'm absolutely sure it shouldn't be in the kernel, I think we both agree on that. If you want to write something generic that applications other than mixxx could benefit from, the other option would be to write a library. The advantage of doing that is it's left up to each application how they receive and process MIDI data. They continue to use /dev/sequencer, or PortMIDI, or whatever, to read the bytes, and then optionally dispatch them into your stateful translator. Each application can then also influence the state if it needs to, which I think would be very useful. Furthermore, configuration of the translator would also be the responsibility of each application. This makes sense to me, rather than maintaining two separate configurations which have to agree on which CC numbers are being used in which circumstances. I think if your translator was a separate application, two-way state traffic would be harder to implement, and it would require more changes to applications to support just the basic reading of MIDI. That's just my gut feeling. > 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. It *only* has anything to do with mixxx. That button is not "inherently" a touch-sensitivity switch. It's just a button. It only has that specific meaning in mixxx. In your translator, I guess it would just be a toggle which switched off relaying of the keypress signals from the touch sensors (the Xponent sends these all the time -- like I say, the "touch sensitivity" button doesn't do any inherent state change, it's just a button which sends a note). Still, that's a function which is specific to the button's meaning in mixxx. I might not want it to do that for any other application. So, each configuration of the translator is application-specific, so why not let the application configure it? I absolutely take your point that this is potentially complex and it would be great for it to be generic and reusable rather than confined to mixxx, so I think a library is the way to go. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
