I vote for both #2 (what we had, but streamlined a bit) and your old "joystick" style for beginners (with a "skip" button", plz) - a wizard.
A wizard alone must also some how deal with delete mappings and double-bind and map virtual 'midi script' functions. The way I see it, the wizard could execute asking for the obvious Mixxx UI functions (play 1, play 2, vol 1, cross fade, etc) and drop that into a table... It will serve to configure most controllers to a basic level of functionality as well as serve as an example of how the horrible-unuser-friendly-table-o-control-mappings works. :) For mode driven controllers or those that require a lot of Javascript people are just going to have to get to know the table, or if we don't go with #2 we could recommend a user friendly text/XML editor (and they'll just have to remember whatever js function they want to map). The other options alone seem like a lot of work that leave you short of covering these use cases... Maybe someone could write up a matrix of use cases to plot these against, makes some sense as these will be user driven functions... (There are some uc "descriptions" on mixxx.org/wiki/doku.php/gsoc2008_midi_control, the uc details on the page seeem implementation specifc) /2cents -G On 17/02/2009, Albert Santoni <[email protected]> wrote: > Hi guys, > > With all the refactoring going on, I had to temporarily remove our > MIDI learning functionality a couple of weeks ago. With our old > implementation, I wasn't entirely convinced that average joe DJ would > be able to figure out how to use it, since a bunch of us developers > struggled with it. Since I'll need to do some coding to re-enable MIDI > learning, now is a good time to have a quick discussion about how > people think MIDI learning should work. > > Ideas? > > How do Traktor and Virtual DJ do MIDI learning? > > In some other MIDI-capable applications that I've used, I've seen the > following approaches: > 1) If you right-click on a control in the GUI, you can click "MIDI > Learn...", move a control on your controller, and you're done. > 2) They had something similar to what trunk had before, where you > could pick a control name from a giant list and move a knob on your > controller. The workflow here was just a pain in the ass (so much > clicking and digging through controls to find the right one.) > 3) You click "MIDI learn", then you move a control in the UI, and then > move a control on your controller, which then magically creates the > mapping between the two. > > #1 might be interesting to look at doing (since our WWidgets know > about ControlObjects, I think), but it's still a lot of mousework. > #2 was less user friendly and just generally harder to use. > #3 reduced the mousework significantly, but it's still a lot of > switching back and forth. > > My own idea that I pitched to people back in the summer (but I guess > didn't get any attention) was to have a dialog that mimics the way old > computer games used to let you set up your keyboard keys. Some > emulators like zsnes work like this too. Basically, the idea is that > the dialog will ask you to move some specific knob or slider on your > controller, then you do it, and then it automatically flips to the > next control that you would need to bind. As an example, the workflow > is like: > - Dialog asks you "Push the play button for player 1" > - You push the left play button on your MIDI controller, > - Dialog then asks you (with no user intervention required), "Push the > play button for player 2" > - You push the right play button on your MIDI controller. > - etc. > > The key idea is that you don't have to touch your mouse or keyboard > while you're setting up your controller, and you're being force-fed > very straightforward instructions about what to do. > > So my parting questions are: Is this a reasonable thing to do? Can we > make this idea even better? And if we come up with an even better > idea, should I just reimplement what we had before and push MIDI > Learning 2.0 to 1.6.3? > > Thanks, > Albert > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > -- __ --- == __/ t.O ==-- http://stacktrace.org/ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
