Re: some usability review

[Will Light <filterchild gmail com>]

On Thu, 16 Dec 2004 04:47:43 +0100 (CET), Tim Janik <timj gtk org> wrote:
> On Thu, 16 Dec 2004, Stefan Westerfeld wrote:
> 
> > I've just made an informal usability review, in which a first-time BEAST
> > User, who knows enough about music to know what he wanted to accomplish
> > try the GUI. The task he wanted to perform was to enter a drum beat and
> > create an ogg file from it.
> >
> > We used Debians beast-0.6.2 package for the test, and I gave some help
> > over the phone.
> 
> hm, i'd not call that a "usability review" yet ;)
> 
> > 2. it may be useful to allow click & drag note setting, that is
> >   (a) you click on the start of a note
> >   (b) you move the mouse while still holding the left mouse button, to
> >   adjust the length
> 
> that works already.
> 
> > 3. when editing drums, the default behaviour of the piano roll, to round the
> >   note value to the next/previous quantization value is not intuitive -
> >   since drums are virtually zero length, truncating down to the note
> >   start would be more intuitive
> 
> i'm sorry you don't make sense here. first, you talk about the default
> quantization setting of a piano roll which is obviously tuned to be
> suitable for notes, not drums. then you talk about "rounding" notes.
> do you mean quantization based alignment of the note start or the
> default note length which is 1/4th?
> finally, what do you mean by "truncating down to the note start"?
> at what point should truncation occour, what's it's purpose and
> when do you envision that to occour?
> 
> >   implementing a drum editor with zero-length notes, which are set on
> >   grid crossings would solve the problem:
> >
> >   Snare  -----|--------|--------X--------|----
> >               |        |        |        |
> >   HiHat  -----|--------X--------|--------X----
> >               |        |        |        |
> >   Bass  ------X--------|--------|--------|---
> >               |        |        |        |
> >   Tom1  ------|--------|--------|--------|---
> >
> >
> >   for drum multisamples such a drum editor could provide intuitive labels
> 
> implementing a drum editor will obviously suit the user better than a
> piano roll, when editing drums.
> 
> 
> > 5. the user wanted to edit a 2/4 beat, for which the grid lines in the
> >   piano roll editor are misleading - configuration would be useful
> 
> implementing different piano roll grid settings is currently blocking on you.
> 
> >   => other items:
> >
> > 6. the beast.gtk.org site does send Text/Plain as mimetype for .bse
> >   files - this makes downloading the files with browsers such as
> >   firefox harder than it should be, because firefox's default is to
> >   show the text file, rather than to save it, which in our test made
> >   the browser crash (during trying to download 808-kit.bse, a 4.7 Mb
> >   multiwave drum sample)
> 
> file a bug against firefox for the crash, and send an email off
> to yosh <yosh gimp org> for any issues you have with the apache
> setup at gtk.org.
> 
> > 7. 196.73282883 bpm in the song doesn't look too nice; maybe it would be
> >   better if adjusting the slider would only set the bpm value to
> >   integer values
> 
> it definitely wouldn't be better, because that would allow much
> coarser settings only. you attempt to trade aesthetics for
> usability here which is basically always wrong.
> to improve the display of the bpm setting, reduction of the amount
> of displayed fractional values seems like a better idea to me (say
> (2 ior 3).
> 
> >   BEAST should do one of the following:
> >    * show parameter tabs in separate windows
> >    * show a dialog "file has been modified, save?"
> >    * autosave, so that the file could be recovered
> 
> these are all items mentioned in the TODO already.
> 
> > 10. a file filter, to see only those files that are relevant for the
> >    current save operation would be beneficial, i.e.
> >
> >    [ *.bse   BSE files ]
> >    [ *       all files ]
> >
> >    or, likewise *.wav for export audio, or *.mp3, *.ogg, ... for load
> >    wave
> 
> Gtk+ has traditionally not employed file filters. well see whether that
> changes if beast is ported to the Gtk+-2.6 file chooser.
> 
> > 11. the export audio function isn't easy to understand
> >    * it is not clear how to start audio export
> >    * it is not clear how to make no audio export happen
> >    * the file save dialog can't be used for unactivating audio export,
> >      the only way to accomplish this is to delete the text entry AND
> >      press return, which doesn't lead to confidence that nothing will
> >      be overwritten, once this was done
> 
> i do not understand why or how the file save dialog should stop
> beast from recording sound.
> 
> >   suggestion: replace the whole functioniality by "File -> Export Song as
> >   Audio" and "File -> Export Loop as Audio"
> 
> i don't see how this would be an equivalent feature. the Export Audio
> feature records everything that is produced by the current interactive (!!)
> session to a WAV file. offline rendering of the sound file is not a
> suitable replacement for that.
> 

a way to do this would be to switch the audio driver to null, play the
file, then restore it.  try this: create a song in beast, save, quit
beast, reopen beast with "-p null", and try to export it.  depending
on how complex your song is, the export will be much faster.  here's
what an "export song" menu command should do:

1) prompt user for file to save to
2) switch audio driver to null
3) play song (exporting to a wave file)
4) switch audio driver back to oss/alsa

> ---
> ciaoTJ
> _______________________________________________
> beast mailing list
> beast gnome org
> http://mail.gnome.org/mailman/listinfo/beast
>