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>
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?
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.
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.
-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
