Re: [abcusers] iabc, and features expected in softwares in general
Laura Conrad wrote: > > "laurie" == laurie griffiths writes: > > laurie> Why does transposition need to understand the mode? > > Currently, the abc2midi transposer only understands the key > signature. So if I have a piece in D dorian, and I transpose it up 3 > half notes, the transposed output is in Ab. It should be in F dorian. And after writing my last comment, I realized that this is abc2midi, and midi may care more about the sharps and flats in a key signature than the actual name of the key or mode, so that's why it's written that way, but when it's also used for making a new abc file, it really needs to keep the mode right. In trying to transmit folk music to others, it's hard enough to help people to learn how to think in modes rather than only major and minor in learning backup and chording without having transposing sw doing it wrong in the abc files. ;-) Rick To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] iabc, and features expected in softwares in general
Laura Conrad wrote: > > "laurie" == laurie griffiths writes: > > laurie> Why does transposition need to understand the mode? > > Currently, the abc2midi transposer only understands the key > signature. So if I have a piece in D dorian, and I transpose it up 3 > half notes, the transposed output is in Ab. It should be in F dorian. Exactly. Is abc2abc part of abc2midi? That's what I use to transpose tunes, anyway, and whenever I have a tune in a mode, it always puts in the abc file the major key associated with the key signature of the mode the original was in, and I always have to go in and manually change it. Very irritating. Is it really that hard to simply change the key or mode letter in the key signature up or down the correct number of half-steps like it does for guitar chords? Seems like it's just a text filed for the transposer sw, and it could be treated the same way. I had thought about writing a standalone transposer, but found I like playing the music more than writing sw for it. ;-) Rick To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] iabc, and features expected in softwares in general
> "laurie" == laurie griffiths writes: laurie> Why does transposition need to understand the mode? Currently, the abc2midi transposer only understands the key signature. So if I have a piece in D dorian, and I transpose it up 3 half notes, the transposed output is in Ab. It should be in F dorian. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] iabc, and features expected in softwares in general
From: "Jack Campin" <[EMAIL PROTECTED]> ! ! !Here are a few more application-level things that might make life !easier: !We need: ! * transposition (which understands the mode of what's being ! transposed) ! ! Why does transposition need to understand the mode? Am I missing something? Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] re : Broken rhythms / triplet rhythms
>Here's your example with "general tuplets" thank you very much Frank ! I didn't know this feature because it's not in the abc-draft 1.7.6 but in the standard-propose.txt so I missed it. It's not really quicker to write than my notation with slurs (sorry, ties... ;) ) but it had the advantage to display the good notation. Will it be revised in the future to make it shortened ? ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] iabc, and features expected in softwares in general
> 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
Re: [abcusers] iabc, and features expected in softwares in general
| >- add keyboard shortcuts for every command (or for the most used | >at least) | | Yes, although with over 100 menu commands there aren't enough | keys to go round. I think I counted that Muse has about 70 shortcuts defined (so there's heavy use of Ctrl+this and Shift+that). It would be a very expert user that knew them all. I have recently been putting more and more function into right-click pop-up menus (for instance to change the length of a note, the clef, etc) and even more effort into "in-place" editing. As soon as you have a few bars entered, the music becomes a palette of things to do for the rest. So you can clone (almost) any symbol and enter it elsewhere. By definition, the more common symbols in your style of music are the ones that are right there on the screen ready to clone. Beyond that, many symbols can be edited in-place. The usual mechanism I use is to hold down Ctrl and use the cursor keys. Thus you can edit a tempo indication to change the value of the note or the number per minute, the length of a note, the pitch of a note (nudging it up may introduce a sharp, nudging it up again may kill the sharp and move it up on the staff). A chord symbol can be cycled through the possible chord roots and types (G7 <=>G#7 <=> A7 etc or G <=>G7 <=> Gm <=>Gdim etc). In fact most music symbols can be edited this way. This is much easier than trying to memorise all the shortcuts. [weasel words - some of the above function is not yet published, but if anyone with Windows wants to volunteer as a beta tester they can have a look]. Now I appreciate that this is not "ABC" and some people may se me as wearing horns - but I just see this, ABC, my fiddle and so on as complementary ways of making and communicating music. Laurie To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] iabc, and features expected in softwares in general
Interesting. The thing that has bothered me for a long time is whether
being able to have files dropped on you is worth a megabyte of download
time.
When I built Muse I avoided MFC because the instant you touch it the file
size goes up by a megabyte (it may be more). Now it may be possible to be a
drop target "the hard way" and only use a few bytes, and the Internet is
getting faster, but are we there yet. (In fact I compile Muse with MSDev 4
because that also gave a smaller executable).
This is the reason why you can't drop files onto Muse.
On the other hand, it gives huge amount of function, I am frequently told
that it's very easy to use (contrast the endless notes on this forum about
how do you tweak this or that abc app to overcome its limitations) and is
just over 300K to download and that includes the online help which is about
the same size as the executable.
So, while I agree with all of the sentiments expressed - I also must add
that a "normal user can expect" the Internet to download a 3MB file in 10
seconds.
Of course he/she will be disappointed!!
So (and obviously this is a matter of opinion) what are these functions
worth in download space?
And incidentally, was Muse one of the programs that you tried? I'm
currently doing a massive re-write and "being a drop target" is actually not
one of the things I was going to do. I thought that before doing that I
would do:
* Much better support for piano-like scores
* Much better support for lyrics
* Much better ease of entry (and it was already very good)
(I'm keying in the choruses of The Messiah as a test case for that lot)
* Much easier control of play (quite a few choral singers use it to help
learn their parts).
* Live MIDI input (which has always been just over the horizon because it
sort of works, but gives more effort in post-editing than it saved in
typing).
* Easier/better guitar tablature generation
An I may throw in a "suggest a guitar chord" function because it looks like
fun.
The lyrics stuff will probably include support for w: and W: in ABC.
Opinions?
Incidentally, I presume that Muse was not one of the ones you tried as it
has not been recently announced on the list. If you give it a try, do let
me know what you think. If you want to be a guinea pig for the rewrite, I
have fairly robust running code, though obviously not all the above features
are yet working and the on-line help is very much behind.
Laurie
- Original Message -
From: "Forgeot Eric" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 21, 2002 8:46 PM
Subject: [abcusers] iabc, and features expected in softwares in general
I've downloaded the recent softwares annonced on the list. For
iabc, the display is really better than previous version (even if
it's not at the level of postscript application) and it looks
promising. But there is still some limitations.
Here is what a "normal" user can expect from a software
(especially music / abc related). It's only my preferences and
several users would not understand my wishes but it may help
nevertheless. It's not about display / hearing abc, but it's about
program conveniences and file management.
In my opinion this software should :
- 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 *.* ) otherwise (especially if there is no
"drag and drop support"), there is no way to open a file which
have a bad choosen extension (for example *.txt instead *.abc),
unless to rename it. There is this limitation in iabc
- allow to enter data directly into the application, without
opening any file (from an other application with "copy and paste,
or from scratch) : skink does this very well with its conveniant
field when we can enter notes.
- 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. And if you
load an other file in order to "free" the previous file, the
previous is still locked : you just have to close iabc and then
open the application again, find the right folder, reload the file
etc.
- save folder preferences (favorite folders ) and keep the last
directory used in a configuration (log or .ini) file.
- add keyboard shortcuts for every command (or for the most used
at least)
- follow the general convention for shortcuts ("ctrl + c" for
copy, "ctrl + a" for select all etc.)
- 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
- 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
- gives a lot of option (pos
Re: [abcusers] iabc, and features expected in softwares in general
Forgeot Eric wrote:
>Here is what a "normal" user can expect from a software
>(especially music / abc related). It's only my preferences and
>several users would not understand my wishes but it may help
>nevertheless. It's not about display / hearing abc, but it's about
>program conveniences and file management.
Interesting to compare this list with what BarFly does. It's now
a mature application after five years of development, and I think
does everything you suggest (allowing for some differences in
convention between Mac and Windows).
>In my opinion this software should :
>
>- open files with "drag and drop" (for windows, but maybe for
>other O/S too)
Yes.
>- 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 *.* ) otherwise (especially if there is no
>"drag and drop support"), there is no way to open a file which
>have a bad choosen extension (for example *.txt instead *.abc),
>unless to rename it. There is this limitation in iabc
There's no file filter - it will open any text file regardless
of extension.
>- allow to enter data directly into the application, without
>opening any file (from an other application with "copy and paste,
>or from scratch) : skink does this very well with its conveniant
>field when we can enter notes.
Yes.
>- 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. And if you
>load an other file in order to "free" the previous file, the
>previous is still locked : you just have to close iabc and then
>open the application again, find the right folder, reload the file
>etc.
Yes, although strictly speaking Mac programs are supposed to leave
files open when the data is on display to prevent another program
from modifying the file behind the user's back. In the early
days of development I decided to close files except when reading
or writing to reduce the chances of file corruption if the program
crashed (which it did a lot in those days).
>- save folder preferences (favorite folders ) and keep the last
>directory used in a configuration (log or .ini) file.
That's a system function in Navigation Services on the Mac.
>- add keyboard shortcuts for every command (or for the most used
>at least)
Yes, although with over 100 menu commands there aren't enough
keys to go round.
>- follow the general convention for shortcuts ("ctrl + c" for
>copy, "ctrl + a" for select all etc.)
Yes (command key rather than ctrl on the Mac, but the principle's
the same).
>- 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
Yes.
>- 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
Yes.
>- gives a lot of option (possibility to allow / disallow a display
>option, a command, to change the fonts, the size etc.)
Yes.
>- 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.
Individual tunes get processed only when they are on display or
being played.
>for the tune reels.abc you give as example with iabc, it takes 1
>minutes to process all the 373 tunes in it. With AbcMus it takes
>only 1/2 second ! It only check the numbers I guess and make the
>calculation on a tune request, and if there is errors in some
>tunes it won't be blocked and even try to play them as well. I can
>also add that AbcMus can most of the other features I mentionned
>above (it's a coincidence because I've just checked this
>afterwards, but it may indicate AbcMus is a conveniant,
>well-designed, software). Anyway, it's not a nasty critic for the
>other programs which are works in progress and grow in features. I
>hope they will make their marks in the future !
AbcMus is a very well designed program. Another useful feature
which you don't mention, but which both AbcMus and BarFly possess
is multiple document architecture, so that you can open multiple
files in different windows and copy/paste tunes between them.
(This is easy on the Mac, but I think much more difficult on
Windows.)
>
>An interesting tune which doesn't display (unless editing them) in
>both skink and iabc :
All these tunes work fine on BarFly, which is not surprising since
Dan G Peterson is a long-time BarFly user. He was one of the program's
most useful critics in the early days, and several of its features
were added in response to his suggestions.
Perhaps I should point out though, that ({c/d/}c2) is actually illegal,
since the abc 1.6 standard says:
"Grace notes have no time value and so expressions such as
