Subject: Re: [linux-audio-dev] what's wrong with glame
From: delire (delire_AT_selectparks.net)
Date: Fri Jul 27 2001 - 05:50:09 EEST
----- Original Message -----
From: "Richard Dobson" <RWD_AT_cableinet.co.uk>
To: <linux-audio-dev_AT_music.columbia.edu>
Sent: Friday, 27 July 2001 2:42
Subject: Re: [linux-audio-dev] what's wrong with glame
> (bearing in mind I haven't installed, much less used, GLAME, or
> anything, yet...)
>
> Alexander Ehlert wrote:
>
> >
> > Yeah, hmm, that's just naming. We could add something called open in the
> > menu which creates a group with the wavfile in it. But, importing it
makes
> > sense because we convert everything to float internally to allow for
high
> > quality dsp. So you have to import and export it. But that's not really
> > an issue compared to open/close, it's just getting used to it. Ok, I
have
> > to admit that the file importing(opening) gui is rather bad. But I
wasn't
> > motivated yet to change that.
>
> I think this is a semantic misunderstanding.
>
> All the ~multi-track~ programs I have had experience of (Cubase, Cool
> Edit Pro, and most recently, cakewalk SONAR) use the semantic 'Import',
> for a simple reason - in a multi-track project, you have N tracks, and
> any soundfile must be 'imported' to one of these (You may indeed need to
> select a track before 'Import' becomes active). Cool Edit Pro has a nice
> feature in that if you right-click in a track, the File menu appears
> with Import, and the file is inserted at the cursor point. In a plain
> stereo wave-editor, there is by definition only one track, so 'Import'
> is unnecessary, and 'Open' is more idiomatic.
'import' is perfect for the multracker, because it means 'adding to the
existing session'. however in the the editor it is less appropriate- which
is why in all the above applications 'open' to reach audio data for editing.
Glame may not need to use 'import' because it is [atm] primarily an editor.
Open is also used in the Multitrack window of CEPro to open a 'session'
file, the same applies elsewhere.
but you're right, it is semantic - though semantic differences also mark
intuititve differences - i see this alot when teaching new tools to
students.
>
> At least in Windows and the Mac, the File->Open command is always
> understood to relate to the main file associated with the project (the
> file you might double-click on from Windows Explorer); this would for
> most users be a Session, Project, name-it-what-you-will. Double-clicking
> on a soundfile name would be expected to play it using the default
> player. However, at least under Windows, you can change a file
> association so that selecting a soundfile opens it in your preferred
> application (assuming it can accept the file in that way). This merely
> requires a 'multi-document' capability where the command-line passed to
> the program can contain the name of either a Project or a SoundFile (or
> a MIDI file, or...), and either can be opened.
>
> SONAR cannot do this (for the above reason - where would it go?), but
> Cool Edit Pro can, possibly uniquely, because it implements two parallel
> modes - multi-track project, and single-track editor mode.
>
>
> Interpreting 'Import' as format conversion is, IMO, a typical
> programmer's tinted spin on how the user thinks, or, rather, doesn't
> want to have to think. After all, you don't 'Import' a Word document
> into a word processor because it happens to be converted to Unicode,say,
> internally. The user, generally, couldn't care less about internal
> representation. They will only want to know that the highest audio
> quality is maintained internally (however that's done - 32bit ints?
> doubles? quads?), and they will sometimes want to 'Save As' a different
> format, or explicitly do a Format Conversion as some programs require
> you to do - which even I find a complete pain in the A.
>
>
> Designing User Interfaces is a real challenge, not merely from an
> implementation point of view (all those debates about libraries!), but
> literally from a design, i.e. HCI, point of view. Certain procedures
> become de-facto standard, and a developer takes a great risk in changing
> this; on the other hand if the change very clearly leads to an increase
> in intuitiveness and efficiency for the user, they will generally accept
> it after a moment to re-orient. Nevertheless, there is a simple HCI
> measure of efficiency for the user, which is to find the number of
> discrete steps the user must perform to achive any specific operation,
> and, wherever possible, ensure that the most frequently performed tasks
> (which may be the most argued-over parameter, of course) require the
> least number of steps. A sub-menu requires at least four, possibly five
> steps:
>
> Menu-->scroll-to-Item-->(Click-item-->)scroll down submenu-->click
> sub-item.
>
however i would happily substitute a sub menu for a long top-level menu most
of the time if my cut /copy /paste /mixdown /apply last filter etc where all
there.
> Of course a keyboard shortcut can be used, but you have to know what it
> is first, and preferably not requring three or four keypresses; so this
> can conflict with the goal of a shallow learning curve
it takes a pretty extensible app to require the scale of
<ctrl><alt><shift><l> commands. just a few of the now global key binds that
follow from other apps /Os's would suffice for Glame. eg: we all know what
<ctrl><c> will probably do ; )
>.......................
>it follows that a design that allows both projects, and
> soundfiles, to be opened with one mouse-click (!), is the Holy Grail.
>
good words!
>
>
de|
_ / a -> b, b ->c, a -> d, d -> c ...and so on... \ _
This archive was generated by hypermail 2b28 : Fri Jul 27 2001 - 05:52:55 EEST