Hey Garth, On Mon, 2009-02-02 at 23:27 -0500, Garth Dahlstrom wrote: > I was not party to the 'We' that discussed this new mockup at the > meeting... > > <sarcasm> > We (myself and a group of people who potentially use computers) met > after the Super Bowl post-game show and came up with a simplified UI > for Mixxx too.... It is focused on improving the user experince by > reducing the number of buttons, knobs and sliders - previously the > cause of too much user thought and sooo many user questions. > _____________________ > waveform1 > waveform2 > --------------------- > | Load | Load > | & | & > | Play 1 | Play 2 > > 2 waveforms + 2 buttons... > </sarcasm>
iMixxx :) > > Ok, joking aside, rather then just code something that looks an uber > simple prefs panel and then worry later about the issues like how to > jam the obviously missing functionality (midi learning anyone? > overriding device selections? saving and reseting custom mappings, > etc, etc, etc) back into it with limited screen space present, why > don't 'we' try and establish a list of use cases? Or if you covered > these during the meeting, why not document them in the minutes > annoucement? We briefly mentioned one or two use cases during the meeting, which I forgot to write up in the list. I think the consensus was that 90% of our users are just going to want to fire up Mixxx and have their MIDI device magically work right away, so our (more realistic in the short-term) goal is to try to minimize the amount of user intervention required to make a MIDI controller work. We couldn't work through very specific use cases because we're constrained by certain aspects of the current MidiObject-based MIDI code for 1.6.2. The best we could do was say, "A list of MIDI devices will show up the in tree to the left, a user will select their device, and click Activate on pane that comes up." - This was as much as I knew was manageable with MidiObject. (We should be able to resurrect my Christmas MIDI code and merge it with our new MidiMapping and bindings GUI, but that's beyond the scope of 1.6.2.) This is as fine grained as we could get at the time without knowing exactly what other limitations we might bump into. Regardless, having a model/view-based GUI is going to give us a lot of flexibility in the end anyways, so modifying the GUI should be significantly less work than it was before. :) > > I say this fully realizing that trying to have some kind of spec, > created based on use-cases, straddled atop the ever-shifting > requirements of what is in-and-out of scope with respect to the midi > subsystem is what got us into the mess of inelegant dialogs we have > now. Yeah, the "advantage" we have now is a much better understanding of MidiObject and it's limitations, along with being able to look retrospectively at the old MIDI prefs dialog and learn from that. > > BTW, it's fine to descope stuff, but its worth bearing in mind that > unless you leave a way to get it in later you are just going to end up > with another tab/panel/scrollbar/whatever to fit it in if you put it > back in scope later on. This is a valid concern, but using model/view gives us a much greater amount of flexibility for working stuff in. That said, I'm completely aware that the more advanced use-cases (where you want to use MIDI learn, etc.) are not well-defined anymore, and I'm purposely leaving this functionality until I've got a better idea of what we can/can't do with MidiObject. Good point though, so when I get stuck, I'll try to bounce something to mixxx-devel to make sure we deal with the advanced use cases well. Thanks, Albert > > -G > __ > --- == __/ t.O ==-- > http://stacktrace.org/ > > > On Mon, Feb 2, 2009 at 7:51 PM, Albert Santoni <[email protected]> > wrote: > There's one extra constraint we forgot about, and that is the > fact > that there's no association at the API-level between an input > and > output MIDI port even if they are on the same device. There > doesn't > seem to be a way for us to say "input port X" and "output port > Y" > belong to the same device because MIDI is a half-duplex > protocol that > makes no logical connection between input and output streams. > For that > reason, none of the OS-level APIs (and subsequently PortMidi) > provide > a way to figure out which streams belong to what device. > > In our current code, we skirt the issue by making the > (incorrect) > assumption that the input stream with index A and the output > stream > with index A belong to the same device. This works if you have > certain > MIDI setups, but as soon as there's any asymmetry in the > input/output > ports in your setup, this will break. > > This does wreak havoc with out side-panel device list to some > extent, > but for 1.6.2 I don't believe we'll be able to solve this > problem. > Hopefully we can get away with doing what we were doing and > come up > with a better solution for 1.6.3. > > Thanks, > Albert > > > > On 1-Feb-09, at 12:17 AM, Albert Santoni wrote: > > > Hi guys, > > > > Today a few of us met to talk over some of the issues we're > facing > > as we > > gear up to begin closing out our current release cycle. One > of our > > focuses was on the MIDI preferences dialog panes, which > we're > > currently > > redesigning. The main points from the meeting were: > > - We want a single pane. > > - There are some UI feedback and visual persistence issues > with the > > current two-pane MIDI prefs, and this was also an issue with > the > > mockup > > Garth did. > > - We spent a fair amount of time trying to figure out a user > friendly > > design by critiquing both the old panes and Garth's mockup. > > - We agreed that something like the mockup I've attached > will be a big > > improvement (in terms of usability and user experience), and > should > > address the issues we had with the old panes. > > - Essentially, each connected MIDI device will show up in > the tree on > > the left, and when you select them, a different pane for > each MIDI > > device will appear. > > - This is design should work with our crappy > MidiObject-based code, > > but > > should also integrate nicely into future device-oriented > code which > > supports multiple MIDI devices. > > > > Thanks, > > Albert > > < > > > midi_dialog_mockup_feb12008 > > .png > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > > > http://p.sf.net/sfu/sf-spreadtheword_______________________________________________ > > Mixxx-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing > skills and code to > build responsive, highly engaging applications that combine > the power of local > resources and data with the reach of the web. Download the > Adobe AIR SDK and > Ajax docs to start building applications > today-http://p.sf.net/sfu/adobe-com > > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
