> Here is what a "normal" user can expect from a software
> (especially music / abc related).
> - open files with "drag and drop" (for windows, but maybe for
> other O/S too)
>
>- when you open file from the dialog box (file...open... etc.),
> give the choice in the file type filter to choose other extensions
> (not only *.abc, but *.* )
Both of these are normal behaviour for any Mac application.
>- allow to enter data directly into the application, without
> opening any file (from an other application with "copy and paste,
> or from scratch)
That depends on whether the application integrates an editor. If
it doesn't (as with an ABC-to-some-other-format filter), the option
doesn't make sense. On the Mac the standard way for an editor to do
this is to create a new document; it doesn't really exist until you
save it. On Unix most people would use a conventional editor, maybe
with an ABC-specific mode, and feed chunks of text into filter
programs that could never change the ABC itself.
>- not "lock" a file loaded especially if it doesn't write anything
> in it : in iabc it's not possible to make correction in an abc
> file (with an ascii editor for example) and then save it to review
> it later in iabc : the file is write protected by iabc.
On the Mac (and Unix) file write permissions are handled by the OS.
>- save folder preferences (favorite folders ) and keep the last
> directory used in a configuration (log or .ini) file.
Done by the OS on the Mac.
>- add keyboard shortcuts for every command (or for the most used
> at least)
I like this to be configurable; on the Mac it usually is, with
variable degrees of difficulty. And definitely NOT every command
by default (though this is a good idea if the program is to be
usable by the disabled). I have one word processor which has such
a disconcerting number of key bindings that I keep having to use
undo when I hit one by mistake.
>- follow the general convention for shortcuts ("ctrl + c" for
> copy, "ctrl + a" for select all etc.)
Any Mac application will do that.
>- when several tunes are processed, not stop if it detects an
> error in a tune : just ignore the tune and follow on with the
> other tunes
This ought to be configurable.
>- eventually try to display the tune nevertheless if an error is
> detected (but gives warnings) : it's maybe a minor one
> (unsupported feature) and the tune may look quite the same
It's useful to be able to set levels of error checking or tracing.
>- gives a lot of option (possibility to allow / disallow a display
> option, a command, to change the fonts, the size etc.)
I don't think many programmers would disagree with that. The problem
is whether they've got the time to implement it all.
>- if there is a lot of tunes in a file, doesn't process all of
> them at the opening, but process / check those on request (the
> specific ones we want to display) : it will save times.
The user needs to be in control of that. For some applications only
batch mode makes sense.
> An interesting tune which doesn't display (unless editing them) in
> both skink and iabc : [...]
> K:Am [...]
> A2B cBA|BAG AGE|A2B cee|dBA G2({A/G/}E)|
> Grace notes gives error in skink
Unfortunately, given the current ABC spec, it should. Grace notes at
present have only one length; you should have written {AG} instead.
This needs to be fixed but you can't blame Skink for following the
rules.
> Iabc doesn't understand the K:Am
That's completely unacceptable; the program should never have been
released in that state.
> there is also a limitation in iabc which cause tunes with a X:
> field with a high number to be well processed but it won't be
> displayed later.
Okay, all programs have size limits; eventually they always get
increased. If the documentation's up-front about what they are
it's not usually a problem. Putting 955 tunes in one file is a
bit ambitious.
Here are a few more application-level things that might make life
easier:
- cascading stylesheets. BarFly has a reasonable (if unreadable)
way of encoding preferences local to a tune with its %%Bfly lines,
and has application-level preferences, but except for the special
case of its way of handling HP or Hp signatures, nothing in between.
It would be nice to be able to define a "style" for, say, fiddle
music with guitar accompaniment, that would select the right
QuickTime instruments for playback, and say where the chords
should go; or define a standard look for everything in a tunebook.
- source manipulation tools. BarFly has a few of these but nowhere
near enough. We need:
* transposition (which understands the mode of what's being
transposed)
* change the default note length (e.g. most of Bruce Olson's
earlier transcriptions have L:1/4 where it should be L:1/8,
so they're an unreadable mess of /2 fractions)
* introduce or eliminate broken rhythms
* expansion of guitar chords to [...] chords and vice versa
* bar length checkers and (for barlineless music) alignment
checkers that can tell whether notes in different voices
are simultaneous)
* pretty printers; align the notes of a tune in 8-bar units
and you can tell immediately if you've miskeyed something
that ought be a literal repetition of something else.
- for players, highlighted playback of either the ABC source, the
staff notation, or both. BarFly provides highlighted playback
only for single-line music in ABC source; it would be very
helpful if it could do multi-voice too. Highlighted playback
of multi-line staff notation was supported on a music editor
for the Xerox Dandelion I saw on a video in 1985, so it can't
be impossibly difficult on modern machinery. It's a great tool
for spotting mistakes.
- for editors, multilevel undo/redo.
- (so far only affecting BarFly, I think) distinction of document-
related and display-related non-textual data. BarFly records
font information in the resource fork of the file, probably much
as the Nisus text editor/word processor does. But it also records
information specific to the display (which Nisus doesn't, thank
god). I often look at the same ABC file on three different sizes
of screen on the same day, and it's so inconvenient to have the
application assuming the last screen size I used that I prefer to
trash the resource fork and just do without the font data. (In
general BarFly's control and recording of preferences and other
configuration data is a bit of a mess: they are scattered all over
the user interface and all over the filesystem with not much logic
about what goes where - it probably has to record more state than
any other ABC application and it "just growed", I guess. Unix
enforces more structure so maybe the OS X version will be tidier).
- it would make BarFly's styled ABC text more portable (does any other
system yet support persistent font assignments and text styles in ABC
source?) if font information were done in a generic way, as HTML 4.x
does it. We don't want to repeat the mistakes HTML 3.2 made ("use
Verdana or all bets are off") - from the abcm2ps-oriented tunes I've
seen here it looks like exactly those mistakes are already being made
at the staff-notation level. Getting the font stuff right, both in
source and output, is essential to making ABC properly multilingual.
(I once sent Phil a song with a bilingual Turkish/German text; I had
to send him a Turkish font at the same time to make sure he could
read it. That shouldn't be necessary).
And one irritating problem I can only speculate about solving: the
behaviour of programs that generate many output files from one ABC
multi-tune input file. None of the Unix ports I've seen on the Mac
do this in a remotely sane way and I imagine they look just as bad
on Windows (imagine something that made NT filenames by truncating
all the tune titles starting "The Road to..." in O'Neill). There
are two options:
* interactive choice, with the user getting the chance to tinker with
each guess the program makes (not much fun with 955 tunes in the file)
* deriving the filename from a line in the tune header specially for
that purpose. We already have the F: line in the spec and it's very
under-used. I suggest the following:
% if an F: line occurs in the file before any tune, derive a basename
from it, extending it with the number in the X: field for each tune
(tough if they aren't unique, earlier files might be overwritten;
fix it, you're supposed to know what you're doing)
% if there is no file-global F: line, but there is in a tune, derive
the basename from that line (again, tough if those lines aren't
unique).
-----------------------------------------------------------------------------
Jack Campin * 11 Third Street, Newtongrange, Midlothian EH22 4PU, Scotland
tel 0131 660 4760 * fax 0870 055 4975 * http://www.purr.demon.co.uk/jack/
food intolerance data & recipes, freeware Mac logic fonts, and Scottish music
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
