[abcusers] Modular ABC
On Wed, 2 Jul 2003, I. Oppenheim wrote: Application dependent meta information such as page width, font colour, midi track no could also be standardized, but in a meta standard that is separate and does not interfere with the abstract ABC standard. The ABC standard itself should only deal with purely musical elements. this the what I'm doing in the new draft I'm preparing! I kept musical information and low-level details completely separated. So, don't worry. Therefore I think the ABC standard should be highly modular; ABC software should be able to implement a minimal amount of ABC in a well defined way that is still standard compliant. The software developer is then able to clearly indicate which ABC modules are supported and which not. Stuff such as bagpipe notation, modal key signatures, microtonal accidentals, tablature support could go in separate modules that are optional. this is a _very_ sensible proposal! I'll keep to the basics for now, but I'll add a comment reporting your suggestion. Later, Guido =8-) -- Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN. Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
On Wed, 2 Jul 2003, I. Oppenheim wrote: The ABC standard itself should make it possible to specify the code page in which the text inside the ABC tune is coded. It is probably safe to assume iso8859-1 (Latin-1) as default, if nothing is specified by the user. This way the user could also choose e.g. Unicode as codepage. Irwin, although I see your point I'm afraid I disagree with you. It looks like most users want to keep ABC and low-level details - especially computer-related details - completely separate. In the draft, I didn't mention codepages, iso and some such. I'm sure 95% of ABC users would not understand what it's all about. All I wrote is that ABC tunes are written using characters: A-Z, a-z, and some symbols. Everything outside this range is taken care in the 'Low-level details' section. Please wait for the draft... Ciao, Guido =8-) -- Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN. Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] About BarFly m: macros
On Wed, 2 Jul 2003, I. Oppenheim wrote:
m: ~n3 = n{o}n{m}n
Phil, thank you for sharing this, this is a wonderful
idea! I strongly suggest to include this mechanism in
the upcomming standard. Guido, what do you think?
My personl view is that extensions are always welcome if the make life
easier, but calling them 'standard' is only possible if/when they are
actually implemented by a large number of applications. Remember, I
believe in 'de facto' standards.
I think that m: is a wonderful and very useful extension to the standard,
but AFAIK BarFly is the only program that supports it. In my view, macros
shouldn't be part of the notation, and should be implemented using
external tools like preprocessors. But that's just an opinion. I think
I'll extend abcpp to add m: support.
That said, if all developers are willing to implement m: in their
programs, that't fine. Otherwise, abcpp will do the job for them.
Ciao,
Guido =8-)
--
Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager
Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN.
Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy)
Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
There's been a lot of traffic on this topic already. Two things I'd like to emphasize: 1) I agree that the standards committee should have a chairman, but I think the committee needs to elect him/her. 2) We seem to be in danger of falling into the trap of everything that any known ABC-related application does has to be included in the standard. This runs the risks of a) making the standard too difficult to interpret and/or implement, and b) adding features to the standard before they've been used widely enough to figure out if they're actually workable as implemented. I'd recommend that in general, we try not to add features to the standard unless: a) there is consensus (or at least an overwhelming majority opinion) as to what the feature should do, and either b) several (or at least a few significant) applications already use it, or c) more than one developer (or group of developers) is planning to implement (or in the process of implementing) the same feature Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Barfly on other platforms
On Wed, 2 Jul 2003, Jon Freeman wrote: I'd guess you are on Linux and don't know what could work with that but, with help from Phil Taylor, I did manage to get Barfly running on a Win PC using an emulator caled Executor. I liked it a lot - IMO, it's the best of the dedicated abc programs where you can type in the abc, see a score, play a tune (and do things like get a suggested mode/key) that I have tried. I wasn't prepared to pay $150 for the emulation software though and was limited to 1 month to try Barfly as a result. I use BarFly successfully on a wonderful, free emulator called BasiliskII which runs nearly everywhere. Please feel free to contact me for tips/suggestions. Ciao, Guido =8-) -- Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN. Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Free notation program for Windows - let's write it...
On Wed, 2 Jul 2003, Donald White wrote: I am using runabc.tcl (or runabc.exe) on both my PC and on Linux as a front end to abcm2ps and gsview, and it is extremely easy to use. To a novice user, once it is setup, you hit display and it generates a pdf file directly and launches gsview32.exe (on Windows). I also used it, it's nice. I remind you that my JedABC, too, makes the dreaded command line invisible to the user! I think the biggest thing lacking on Windows is an open source graphical score editor. I use abcm2ps extensively for generating music for church, and I have a large library of ABC worhip music, but I can interest anyone else in learning the syntax and writing music in a text editor. I tried to convince Joerg Anders of NoteEdit fame to make a QT-only version of his wonderful program (this will make it possible to compile it under Windows), but unfortunately there are technical problems... too bad. Any talented programmer experienced with QT or FLTK...? Ciao, Guido =8-) -- Guido Gonzato, Ph.D. guido . gonzato at univr . it - Linux System Manager Universita' di Verona (Italy), Facolta' di Scienze MM. FF. NN. Ca' Vignal II, Strada Le Grazie 15, 37134 Verona (Italy) Tel. +39 045 8027990; Fax +39 045 8027928 --- Timeas hominem unius libri To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
On Thu, 3 Jul 2003, Guido Gonzato wrote: In the draft, I didn't mention codepages, iso and some such. I'm sure 95% of ABC users would not understand what it's all about. Probably; but the software packages that write ABC should specify the codepage in a standardized way, unless the default one (i.e. Latin-1) is used. If Latin-1 is set to be the default, those 95% of the ABC users that use Western European lyrics or no lyrics at all, won't notice a difference. But those 5% of us that wish to write e.g. Hungarian (latin-2), Russian, Hebrew or UTF-8 will have an easier time. One can refer to a document as http://czyborra.com/charsets/iso8859.html for details. All I wrote is that ABC tunes are written using characters: A-Z, a-z, and some symbols. And what about \'a style accent notation? Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About BarFly m: macros
From: Guido Gonzato [EMAIL PROTECTED] My personl view is that extensions are always welcome if the make life easier, but calling them 'standard' is only possible if/when they are actually implemented by a large number of applications. Remember, I believe in 'de facto' standards. In the case of the m: macro given by Phil, the solution is easy. Just document the existence of m: as something that goes beyond the standard (if you don't want to include it), and programs can either use it or not. The key is (in this example at least) that the music makes syntactical sense if you ignore the macro. If all macros are like that and the existence of m: is documented, it will ensure that macros do not break programs which ignore them. Dave David Webber Author of MOZART the music processor for Windows - http://www.mozart.co.uk Member of the North Cheshire Concert Band http://www.northcheshire.org.uk To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About BarFly m: macros
On Thu, 3 Jul 2003, Guido Gonzato wrote: I think that m: is a wonderful and very useful extension to the standard, but AFAIK BarFly is the only program that supports it. I'm fair enough to admit that BarFly is a widely used and significant ABC program; so if Phil says that his macro facility is well-defined and documented, and proven in practice, I think that's enough to include it in the standard. I'm convinced that it's a useful feauture. I'm also convinced that when it get's into the standard, most packages will start to support it within a year or so. In the meantime, your preprocessor could be used to handle the macros. In my view, macros shouldn't be part of the notation, and should be implemented using external tools like preprocessors. It's fine if it's handled by a preprocessor, but it still should be part of the standard. In C, #define is also part of the ANSI-C standard, although it is actually implemented in a preprocessor. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About BarFly m: macros
On Thu, Jul 03, 2003 at 09:03:24AM +0200, Guido Gonzato wrote:
On Wed, 2 Jul 2003, I. Oppenheim wrote:
m: ~n3 = n{o}n{m}n
I think that m: is a wonderful and very useful extension to the standard,
but AFAIK BarFly is the only program that supports it. In my view, macros
shouldn't be part of the notation, and should be implemented using
external tools like preprocessors. But that's just an opinion.
I suspect this may be one of those Linux user things, and people who
use software that gives them buttons to push may be less comfortable
with such an approach ?
That said, if all developers are willing to implement m: in their
programs, that't fine. Otherwise, abcpp will do the job for them.
Which is nice :)
--
Richard Robinson
The whole plan hinged upon the natural curiosity of potatoes - S. Lem
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
On Thu, Jul 03, 2003 at 09:25:46AM +0200, I. Oppenheim wrote: On Thu, 3 Jul 2003, Guido Gonzato wrote: In the draft, I didn't mention codepages, iso and some such. I'm sure 95% of ABC users would not understand what it's all about. Probably; but the software packages that write ABC should specify the codepage in a standardized way, unless the default one (i.e. Latin-1) is used. If Latin-1 is set to be the default, those 95% of the ABC users that use Western European lyrics or no lyrics Umm. Even if you only write in Spanish, French, German, Danish, Norwegian, Swedish ... you're going to want non-127 accented characters. If you don't write lyrics you'll want them for a tune title. -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
On Thu, Jul 03, 2003 at 09:34:03AM +0200, Guido Gonzato wrote: On Thu, 3 Jul 2003, I. Oppenheim wrote: And what about \'a style accent notation? obviously, I've added a section that deals with it! :-) Is there a list anywhere of which programs recognise which of these sequences ? -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About BarFly m: macros
Guido Gonzato wrote:
| On Wed, 2 Jul 2003, I. Oppenheim wrote:
|
| m: ~n3 = n{o}n{m}n
|
| I think that m: is a wonderful and very useful extension to the standard,
| but AFAIK BarFly is the only program that supports it. In my view, macros
| shouldn't be part of the notation, and should be implemented using
| external tools like preprocessors. But that's just an opinion. I think
| I'll extend abcpp to add m: support.
|
| That said, if all developers are willing to implement m: in their
| programs, that't fine. Otherwise, abcpp will do the job for them.
Macros are usually best handled by a separate pass that
just expands them. One of the interesting things about the
history of C is that there were a few compilers written
that had the macros integrated into the language. This was
generally considered a bad idea. In some cases, the macro
code was stripped out, and replaced with a separate cpp
pass.
In the case of the C pre-processor, one of the interesting
arguments was that the pre-processor is useful with a lot
of other languages. If you look at C's macros, they really
have little to do with C. About the only syntax that is
really C is the /*...*/ comment; the rest is generic and
works with most other languages. This was especially seen
when the Berkeley folks came out with the compiler with
multiple parsers, so the same compiler could handle C,
Fortran and Pascal. New parsers could be (and were) written
as plugins. The macro phase was done first, so C's macros
could be used with all of the languages in the list. Perl
has an option to run the code through cpp. So keeping C's
macros in a separate program is a benefit to many other
languages.
It's not obvious that abc macros would be very useful to
anything but abc. The above macro is pretty obviously
musical, and of no obvious use anywhere else. But I
wouldn't be too surprised if people found other uses for
it. In any case, one of the vague and general lessons from
the field of computing is that things that do text
transformations like this are often more useful than you
think at first. They are best done with standalone
programs, so you can easily retarget them. You can invoke
them by default (as C compilers do) or with an option (as
perl does), but you probably don't want them integrated
into your other programs.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Line breaks
From: I. Oppenheim [EMAIL PROTECTED] Date: Wed, 2 Jul 2003 00:32:27 +0200 (W. Europe Daylight Time) [...] All the standard says is : Generally one line of abc notation will produce one line of music, although if the music is too long it will overflow onto the next line. But I take it that the sentence above means that it WILL break at a line end and MAY break elsewhere... Maybe you're correct on that. Generally does not translate to WILL in my book. In standards- speak it sounds like a suggestion - maybe even a strong suggestion - but not a mandate. In pure English it sounds like a description of what most programs at the time of writing were doing, and I find that a weak argument for implementing this interpretation as a standard. The problem as a developer is that we're second-guessing writers of bad abc notation. Anyway, I think it's a better approach to let the software do the formatting of the music lines unless the user forces a line break, with for example the ! notation found in the BNF standard. In general, software should not assume that an ABC file was meant to be print so it would bad to give to much weight to the exact position of newlines in the file. I wholeheartedly agree, for several reasons: 1. Text file formatting is notoriously succeptible to modification. Text editors and word processors can help you by providing a word- wrap feature unexpectedly; moving text files between DOS, VMS, Unix and Mac systems can cause interesting interpretations of the newline characters; web page authors may cut-n-paste without prepending a forced line break (BR or lt;BRgt;), and the list goes on for quite awhile. Someone here called it the line break daemon -- excellent coinage. I think I'll use that to summarize this family of problems in the future. 2. Writers of ABC text may have different motivations for line breaks than the formatting of the music score. I break my ABC into the lines of the quattrains of the verses of the song, since in traditional folk music there's often much repetition-except-for-two-measures going on. Formatting the text file to follow the quattrains allows me to use basic cut-n-paste techniques to great time-saving advantage. But when the music prints, I don't want to waste the right half of the page; print it like normal music, eh? 3. Imagine the frustration of trying to manually format ABC such that your line breaks line up with where the end of the musically printable page is located. Oops, missed by three notes. Okay, let's re-edit the whole file so *THIS* line breaks properly and print again. Darn, now I appear to be a measure short on the second line. Re-edit again and print. Shucks, now it wraps mid-bar. Darn it! Re-edit again. Print. Examine. Re-edit. Print. Examine. Re-edit... May as well draw it with a felt tip pen on school paper. My first commanding officer had a huge banner on the wall behind his desk: Using a computer should be easier than not using a computer. A motto to live by. I would urge the standards-developers to STRONGLY consider letting ABC be a mostly-freeform, mostly-whitespace-ignorant langauge. Using a special character (such as the aforementioned ! character) to indicate a forced line break on the music is far preferable (and infinitely more flexible) than assuming line-break in the ABC source file must be an actual break in printing. Two cents, and all that rot. ___ Steven K. Mariner [EMAIL PROTECTED] http://home.earthlink.net/~marinersk/ http://www.whirlyjigmusic.com/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Jeff Bigler writes: | | 2) We seem to be in danger of falling into the trap of everything that |any known ABC-related application does has to be included in the |standard. This runs the risks of | |a) making the standard too difficult to interpret and/or implement, | and | |b) adding features to the standard before they've been used widely | enough to figure out if they're actually workable as implemented. ... Good points. There's a well-known phrase in the computing industry that describes this: the Second-System Syndrome. This refers to the way in which a first successful product is followed by a new, improved version that tries to solve all the world's problems. It is invariably a disaster. A much more successful approach is an evolving system, that adds new things after they have been tested. This includes field tests with users who have been warned that the new things are tentative and users are expected to provide feedback. The standard then includes only the things that have been widely accepted and implemented, and the rest are proposed extensions. It's worthwhile to document all of them, but you should make a clear distinction. One of the important parts of this is something we've discussed here lately: You will get new things that the old software can't handle. This means that the software in general needs to be written so that it doesn't choke on things that it doesn't recognize. We do have abc software that gives up (or dies) when it hits something it considers illegal. We should be pointing out to the programmers that this isn't acceptable. New things should at most get a warning, but should be handled (i.e., ignored) gracefully. This way, we can try out new ideas, and if they turn out to be good ideas, they can be added to the growing standard. One of the things that impressed me with abc2ps when I first started using it was that it did a pretty good job of this. I fed it abc from email and web sites that contained all sorts of funny things. It told me about them, and barged ahead. Sometimes there were things missing from the output, but at least the notes were there. (There are the cases where the tune doesn't end with a blank line, mostly when people attempt to embed abc inside html. This produces some rather bizarre modernistic music after what should be the end of the tune. But this is mostly funny.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
I. Oppenheim wrote: | | All I wrote is that ABC tunes are written using | characters: A-Z, a-z, and some symbols. | | And what about \'a style accent notation? Those are a slightly-abbreviated version of the TeX notation, supported by abc2mtex and abc2ps. What other abc tools implement these? (One thing I just noticed is that abc2ps and my jcabc2ps don't implement \\ as a way to get a single backslash into the output. This is an oversight that should be fixed.) (I recently added \'y and \'Y to the list that jcabc2ps handles. So now I can do Czech lyrics. It's interesting that Czech is a Latin-1 language. How did that happen?) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Jeff Bigler wrote: There's been a lot of traffic on this topic already. Two things I'd like to emphasize: I'd recommend that in general, we try not to add features to the standard unless: a) there is consensus (or at least an overwhelming majority opinion) as to what the feature should do, and either b) several (or at least a few significant) applications already use it, or c) more than one developer (or group of developers) is planning to implement (or in the process of implementing) the same feature Maybe adopting the IETF policy that there has to be at least two independent interoperable implementations of something before it becomes standard. Or something similar. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
In message [EMAIL PROTECTED], Laura Conrad [EMAIL PROTECTED] writes Richard == Richard Robinson [EMAIL PROTECTED] writes: Richard Umm. Even if you only write in Spanish, French, German, Danish, Richard Norwegian, Swedish ... you're going to want non-127 accented Richard characters. If you don't write lyrics you'll want them for a tune Richard title. Or even English: The First Noël That would be French. In English it's The First Nowell. Or if it's a boy's name you're referring to it's Noel ;-) Bernard Hill Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] My point of view on the abc standard
I suspect that the only things the abc standard has to worry about, as far as applications on different platforms go, is to do with specification of text fonts and definition of (accented etc) characters in text. And instrumental sounds. BarFly does this via the numerical codes from the instrument set provided with QuickTime - I think these numbers are in fact the same for other distributions of the same sounds, but it certainly isn't the most readable way to do it, and it isn't obvious that MIDI is the only way to specify such sounds that might ever be used (do soundfonts use the same scheme?) A human-readable standard namespace for sounds used by ABC applications would be helpful. Presumably there are other applications besides BarFly that let you control what timbre is played by typing something into the ABC source? - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] About BarFly m: macros
I think that m: is a wonderful and very useful extension to the standard, but AFAIK BarFly is the only program that supports it. In my view, macros shouldn't be part of the notation, and should be implemented using external tools like preprocessors. But that's just an opinion. I think I'll extend abcpp to add m: support. Anselm Lingnau (I think) did a Perl implementation and posted it here a few months ago. I am not totally happy with macros as they are in BarFly at present; perhaps if somebody took Anselm's implementation and stuck it into another implementation, user input evolve something better. (The particular problem I have is that by far my commonest use for macros is to abbreviate chords in triadic keyboard bass parts, and the present setup means I have to write a new macro for every duration I use. The mechanism understands the pitch modifiers _=^', as part of the note, but not the duration modifiers like numerals and /). - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
There are lots of abc2win files on the net which use the exclamation mark for a different purpose Can you be specific there? As a developer I'd like to know! It's a line terminator. In ABC2Win, it's the only way to start a new line of staff notation at a user-defined point, which is unfortunately non-standard. But having a line terminator is a great help in resolving the conflict between making ABC source- readable and having it generate readable staff notation. [warning, if you are not using a fixed-width font, what follows will be incomprehensible] Consider this, from the Aird volume 1 transcription on my website, laid out for optimal source readbility: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:| BGG GAG|BAG ABd|BAG GAG|ABG E3 | BAG GAG |BAG ABd|Bee e2d |BAG E3|] As it stands, four bars to a staff line is too little. What I'd like is to put the tune on two six-bar lines. BarFly unfortunately doesn't use ! the way ABC2Win does, so I have to write this: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:|\ BGG GAG|BAG ABd| BAG GAG|ABG E3 |\ BAG GAG |BAG ABd|Bee e2d |BAG E3|] Even though I've managed to keep parallel phrases vertically aligned so beats fall in the same column, the extraneous, musically meaningless line breaks destroy the visual flow, and are a serious impediment to readability of the source in a large score. What I would like to write is this: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG| Bee Te2d |BAG E3:|\ BGG GAG|BAG ABd|!BAG GAG|ABG E3 |\ BAG GAG |BAG ABd| Bee e2d |BAG E3:| which resolves the conflict in the simplest way I can imagine. : It seems to me that in some cases, having the !...! in the : abc is better than defining a single-char symbol. [the reason offered for this being] : Now, people who think that abc should always be translated : to staff notation might wonder who would ever read abc : directly. But there are, in fact, people who do this. In practice ABCs intended for processing by abcm2ps are among the least source-readable on the net, and the proliferation of long words enclosed by !...! is one the main contributing factors. It makes formatting to show structural parallelisms in the music (as I've done above) impossible. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] bloody ! again
would allow people to go beyond the standard in a way in which other apps could ignore. (Or pick up.) The rule would simply have to be that if such elements are omitted, the remaining music has to obey the standard and make sense. For this kind of in-line stuff, maybe you could use the established !! notation: !appname:info! Far from being established, this is peculiar to abcm2ps and will completely screw up ABC2WIN (which uses ! as a line terminator). I think what it will do is generate an interpolated line with the contents of appname:info interpreted as ABC notes, insofar as the program can manage to do so. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
Bernard == Bernard Hill [EMAIL PROTECTED] writes: Richard Umm. Even if you only write in Spanish, French, German, Danish, Richard Norwegian, Swedish ... you're going to want non-127 accented Richard characters. If you don't write lyrics you'll want them for a tune Richard title. Or even English: The First Noël Bernard That would be French. In English it's The First Nowell. In American, it's The First Noël. In any case, there are lots of other English words that need some kind of non-ascii character to be spelled correctly: naïve, fiancée... Noël was just the first one that occurred to me as being in the title of a commonly known piece of music. -- 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] A bit of history
Bernard Hill writes: | | Is there a difference between a macro and a simple symbol such as | !trill! ? | | What exactly are we implementing here? | | U:T=!trill! | | is not what I'd call a macro but | | U:T=!abc! | | is if you mean it to be the notes abc written in where T is seen. This makes it obvious that one of our problems is the different meanings of the term macro that are in various people's heads. In the usual programming-language sense, calling U:T=!foo! a macro definition means that the symbol T wherever it occurs is to be replaced by !foo!. So the effect of | CEF TG3 | is the same as | CEF !foo!G3 | This is, of course, merely a string substution that happens before any abc parser sees the text. We've had a few confused discussions in which some participants insist that there's a difference between a macro and a string substitution. But to most programmers, a string substituion is merely a special case of a macro without parameters. That's certainly how the best-know macro preprocessor (cpp) handles the concept. What we seem to have so far is two kinds of definitions. The m: line defines a macro with parameters; the U: line defines a parameterless string substitution. To most programmers, especially those who grew up with C, these are the same thing. But to some people here, they're clearly not the same thing. Part of the problem seems to be that a few years ago, the Microsoft Outlook package introduced a sort of programming language that they called macros. Why they used this term is somewhat of a mystery, because the result isn't like macros in any other programming language. Maybe they just like the sound of macro. But this has probably led to much of our confusion. People who work on other systems will generally have no clue about Outlook macros, and will mistakenly think you're talking about something that's conceptually like C macros. While I haven't used BarFly, and only vaguely understand how its macros work, it's pretty obvious from the examples that they are not anything like C macros. I also don't know whether they're conceptually like Outlook macros. So I conclude that I don't really understand what people are talking about here. Terms are being bandied about with unstated meanings about which I can only guess. I'd be reluctant to let it into a standard for this reason alone. Anyway, if we can't get this straight amongst ourselves, the chances of doing something that non-programmers find sensible and usable are pretty slim. We will merely continue to talk past each other, with little understanding of what we're talking about. One suggestion: Maybe we should not refer to the U: lines as macros. They are just string substitution. The m: lines look a lot more like macros (of some sort). To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Kind of solved (Re: [abcusers] Accented characters in lyrics(abc2ps))
On Thu, 3 Jul 2003, Manuel Reiter wrote: sorry to answer my own post, but I've gotten a bit further after some reading up of Postscript specs and a lot of guesswork. ;-) By modifying 'subs.c' and 'syms.c' modified from the current (08-Apr-2003) version of jcabc2ps jcabc2ps can handle macron (\=), dot (\.), breve (\u) and hacek (\v) accents in what I hope is a fairly portable manner not depending on any special postscript hardware. Thank you for the good work. I hope it'll find its way to abcm2ps as well. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] U: assignable symbols
Do any of the implementations allow multiple assignments per U: statement? ex. U: T = !trill! X = ^+ rather than: U: T = !trill! U: X = ^+ The examples in the draft standard all follow the latter example, but the explanation doesn't specifically state that there can only be one symbolic assignment per line. -John To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
On Thu, 3 Jul 2003, John Chambers wrote: Part of the problem seems to be that a few years ago, the Microsoft Outlook package introduced a sort of programming language that they called macros. Why they used this term is somewhat of a mystery, John, the Wordperfect wordprocessor had already macros in the same sense of the word way back in the '80s. Terms are being bandied about with unstated meanings about which I can only guess. I'd be reluctant to let it into a standard for this reason alone. How one calls these mechanisms is utterly unimportant. The only important thing is that these facilities should be available to those who would like to use them. In an earlier mail this day I already explained the difference in semantics between the m: and the U: mechanism. If you're still confused, I suggest that you (re)read my remarks. The bottomline is that both notations are useful and should be available. Anyway, if we can't get this straight amongst ourselves, It's completely straight, because both mechanisms have been well documented and implemented. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] U: assignable symbols
On Thu, 3 Jul 2003, John Norvell wrote: Do any of the implementations allow multiple assignments per U: statement? ex. I'm pretty sure most implementations will not allow that, so don't rely on it. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
Buddha Buck writes: | | Maybe adopting the IETF policy that there has to be at least two | independent interoperable implementations of something before it becomes | standard. Or something similar. Good idea. We might go over the multi-voice implementations with this in mind. One that might satisfy the two-implementation requirement now: The original abc2ps insisted that V: lines all be after the K: line, in the music portion. At least one other program requires that voice definitions be in the header. In jcabc2ps, I replaced the error message that it gave for V: in the header with code to put the line on the end of a list of V: lines and report success. Then, when the code went into its music phase, I added a couple lines to run down this list and call the routine to process them. It worked fine. So jcabc2ps now accepts V: definition lines anywhere before the first use of a voice. All we need now is a non-abc2ps-clone program that is as liberal, and we can state in the standard that such lines can go anywhere (but probably before the first music for each voice). To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Re: My point of view on the abc standard
On Thu, 3 Jul 2003, John Chambers wrote: All we need now is a non-abc2ps-clone program that is as liberal, and we can state in the standard that such lines can go anywhere I do not agree with this approach. A standard should document advisable behaviour, not all the possible errors that people make when writing ABC. I think the only relevant question is: would there be anything against allowing those V: lines to go anywhere? I see no objections, so I think the standard should indeed allow that. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
On Thu, 3 Jul 2003, Jack Campin wrote: There are lots of abc2win files on the net which use the exclamation mark for a different purpose Can you be specific there? As a developer I'd like to know! It's a line terminator. The BNF standard http://www.norbeck.nu/abc/abcbnfx.htm explicitly allows both the !...! and the !-newline notation. There's no reason why these two notations couldn't go together. I argued already in another e-mail why ABC software should NOT assume that a bare newline indicates the end of a music line. The software should do the line formatting itself, and if the user should wish to override the default behaviour, he could use the !-newline notation to force a linebreak. In other e-mails I argued why the !...! symbol notation is a good thing. To sum up: Both usages of the !-sign should be included in the upcomming standard. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
On Thu, Jul 03, 2003 at 06:05:19PM +0200, I. Oppenheim wrote: I argued already in another e-mail why ABC software should NOT assume that a bare newline indicates the end of a music line. The software should do the line formatting itself, and if the user should wish to override the default behaviour, he could use the !-newline notation to force a linebreak. However, since there are tens of thousands of abc tunes out there written in the expectation that text newlines _will_ break the line of music, it would be a bit disruptive if software were to stop behaving like this. It would be nice to have the option ... -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
In message [EMAIL PROTECTED], Laura Conrad [EMAIL PROTECTED] writes Bernard == Bernard Hill [EMAIL PROTECTED] writes: Richard Umm. Even if you only write in Spanish, French, German, Danish, Richard Norwegian, Swedish ... you're going to want non-127 accented Richard characters. If you don't write lyrics you'll want them for a tune Richard title. Or even English: The First Noël Bernard That would be French. In English it's The First Nowell. In American, it's The First Noël. Interesting. In any case, there are lots of other English words that need some kind of non-ascii character to be spelled correctly: naïve, fiancée... Noël was just the first one that occurred to me as being in the title of a commonly known piece of music. Not to forget encyclopædia and pædophile of course... Bernard Hill Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
In message [EMAIL PROTECTED], Jack Campin [EMAIL PROTECTED] writes There are lots of abc2win files on the net which use the exclamation mark for a different purpose Can you be specific there? As a developer I'd like to know! It's a line terminator. In ABC2Win, it's the only way to start a new line of staff notation at a user-defined point, which is unfortunately non-standard. But having a line terminator is a great help in resolving the conflict between making ABC source- readable and having it generate readable staff notation. [warning, if you are not using a fixed-width font, what follows will be incomprehensible] Consider this, from the Aird volume 1 transcription on my website, laid out for optimal source readbility: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:| BGG GAG|BAG ABd|BAG GAG|ABG E3 | BAG GAG |BAG ABd|Bee e2d |BAG E3|] As it stands, four bars to a staff line is too little. What I'd like is to put the tune on two six-bar lines. BarFly unfortunately doesn't use ! the way ABC2Win does, so I have to write this: X:34 T:Thro' the Lang Muir. T:Wandering Willie M:6/8 L:1/8 K:EMin % dorian/minor/phrygian pentatonic Bee Te2d |ege dBG|Bee Te2d |BAG E3:|\ BGG GAG|BAG ABd| BAG GAG|ABG E3 |\ BAG GAG |BAG ABd|Bee e2d |BAG E3|] Um. I must be missing something. Isn't Bee Te2d |ege dBG|Bee Te2d |BAG E3:|BGG GAG|BAG ABd| BAG GAG|ABG E3 |BAG GAG |BAG ABd|Bee e2d |BAG E3|] the simplest??? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
In message [EMAIL PROTECTED] chemnitz.de, Joerg Anders [EMAIL PROTECTED] writes A short remark about this. Somtimes open source is equated with cost free. But even if I'd produce a Qt-only version, you had to pay a lot. Not to me but to the Qt developer Trolltech and to Microsoft. So what encourages the developer to develop code if there is no payment to the developer? I confess I don't understand the Linux setup *at all*. Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Kind of solved ([abcusers] Accented characters in lyrics (abc2ps))
Manuel Reiter writes: | sorry to answer my own post, but I've gotten a bit further after some | reading up of Postscript specs and a lot of guesswork. ;-) I noticed that post, but didn't manage to get around to it yesterday. I just grabbed the latest files and compiled them. After a bit of twiddling to include some recent changes (to make it read from stdin if there are no file names), I tried it and it worked fine. My HP LaserJet4L printer even printed them all very nicely. I'll have to study the code to see how it works. I notice that there is commented-out code for \~x chars. I can understand why this would have to be special, since \~ already has a meaning in w: lines. It would be really nice to make this work. I wonder what the best way to handle the conflict with \~ would be? This is already a bit of a kludge, as it is used to mean a literal tilde. We want to change it to add a tilde to the following char. Maybe a literal tilde would have to be \~~. That would mean a tilde added to itself, which could reasonably be considered a no-op. But I can hear the objection from mathematicians ... | By modifying 'subs.c' and 'syms.c' modified from the current (08-Apr-2003) | version of jcabc2ps found at | | http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps-src.tar.gz I put the modified version at: http://trillian.mit.edu/~jc/music/abc/src/jcabc2ps-20030703-src.tar.gz I've always included a link to a file with such a date. This time, as it's experimental, I'll leave the name jcabc2ps-src.tar.gz as the old version for now, and change it only if the new one looks like it doesn't have any problems. Anyone is welcome to try it and see if they can find old abc that it breaks. | A couple of issues I'm aware of: | ... | | - Placement of the accents works quite well for most characters but is | ugly for high lower-case characters like 'l' and 'b'. One kludge would be to list the tall lower-case letters and treat them as upper case. | I hope anybody besides me finds this helpful. :-) Maybe it will even make | its way into mainstream jcabc2ps when the above issues have been sorted | out. I'll try converting some of my Balkan songs to use this notation, and find out how well it works. One thing I can see missing right now is the cedille that Romanian and Polish use on some letters other than C. I suppose the obvious notation for this would be \,s and \,t. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
On Thursday, July 3, 2003, at 06:43 AM, Bernard Hill wrote: So what encourages the developer to develop code if there is no payment to the developer? Why are there amateur musicians who perform without being paid for it? * Playing music is fun, payment or not. * They want to compose their own music that they'll like better than existing compositions. * They want to perform with their friends. * Or, they want to perform *for* their friends. * Members of the appropriate sex like musicians. So, similarly with programming: * Programming is fun. * Existing programs may not do what I want, so I'll write my own. * Collaborating with other programmers is fun. * Since I've written the code, why not give it away in case someone else finds it useful? * Here the analogy suddenly breaks down. --amk To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Kind of solved ([abcusers] Accented characters in lyrics (abc2ps))
John == John Chambers [EMAIL PROTECTED] writes:
John One thing I can see missing right now is the cedille that
John Romanian and Polish use on some letters other than C. I
John suppose the obvious notation for this would be \,s and \,t.
It's called an ogonek (in Polish, anyway), and it's backwards from a
cedilla. That is, a cedilla is like a 5 without the top horizontal
line, and the ogonek is a mirror image of this.
The LaTeX for it is \k{o}, if it's on a lowercase o. You need to
activate T1 encoding for this to work.
--
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] A bit of history
John Chambers wrote: One suggestion: Maybe we should not refer to the U: lines as macros. Indeed. They are just string substitution. No, they aren't that either. The original usage of U: as implemented in BarFly is neither a macro nor a string substitution. It cannot be implemented by a preprocessor, but has to happen in the parser itself. The U: definition controls what the parser does when it encounters one of the symbols H..Z. Given the definition: U: K = emphasis when the program encounters the letter K it should draw an emphasis symbol () or play the note louder. All the U: field does is change the mapping between the 19 letters H..Z to musical symbols or events. The m: lines look a lot more like macros (of some sort). Well, I don't use Outlook, so I've no idea what is meant by macro in that context. Given the definition: m: foo = bar the preprocessor will search the tune for every instance of foo and replace it with bar. Isn't that what a C macro does? That's a static macro - if the target string (foo) contains the letter n then you have a transposing macro, which is specifically musical in it's meaning. Jack Campin wrote: I am not totally happy with macros as they are in BarFly at present; perhaps if somebody took Anselm's implementation and stuck it into another implementation, user input evolve something better. (The particular problem I have is that by far my commonest use for macros is to abbreviate chords in triadic keyboard bass parts, and the present setup means I have to write a new macro for every duration I use. The mechanism understands the pitch modifiers _=^', as part of the note, but not the duration modifiers like numerals and /). Yes, I've considered extending the macro system to deal with this. However, I was reluctant to complicate the system further for the time being, since I was having so much trouble convincing non- BarFly users how useful they are. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] codepages
John Chambers wrote: | And what about \'a style accent notation? Those are a slightly-abbreviated version of the TeX notation, supported by abc2mtex and abc2ps. What other abc tools implement these? This is the set that BarFly supports (the right hand column may not come out correct in your email program). \'a á \'e é \'i í \'o ó \'u ú \'A Á \'E É \'I Í \'O Ó \'U Ú \`a à \`e è \`i ì \`o ò \`u ù \`A À \`E È \`I Ì \`O Ò \`U Ù \^a â \^e ê \^i î \^o ô \^u û \^A Â \^E Ê \^I Î \^O Ô \^U Û \a ä \e ë \i ï \o ö \u ü \A Ä \E Ë \I Ï \O Ö \U Ü \~a ã \~o õ \~n ñ \~A Ã \~O Õ \~N Ñ \cc ç \cC Ç \AA Å \Aa å \AE Æ \Ae æ \aA Å \aa å \aE Æ \ae æ \O Ø \o ø \\ \ It doesn't include the Hacek (if that's what my Slovenian friends call a roof), as it seems to be missing from all the standard Mac fonts. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Thoughts on where ABC goes...
Dear ABCers,
Since I am not much of a musician or active developer of any music
software yet, I'd like to make a few comments and observations as an end
user of (some of) the ABC tools. Far be it from me to educate anyone in
this group. I'd only like to share with you my way of seeing things.
In my mind macros are commands formed of linguistic statements using
keywords understood by the program for which they have been written and
not some external pre- or post-processor. Therefore, one ought to speak
about macros if and only if there is also an engine interpreting them.
Just because there is a way to assign various meanings to an arbitrary
symbol, one ought not refer to them as macros. (The #include, #define,
etc. statements in C or C++ are rather compiler directives, than
macros). According to this, there is not much difference between the
disputed U: and m:. They both serve only one purpose: assign a meaning
to a key-word, -code, -string, you name it.
A real macro language would support at least some VARIABLES and
OPERATORS. I could see the use of an operator that would control the
printing and the play of various ornaments, for example. Suppose I
wanted to say (and I will mix Phil's macro definition and the U:
style assignment just to emphasise what I mean),
U: vibratenote =
{_note}note{^notenote_notenote^note}{symbol}
and then just apply it as
!vibrate!a
which would mean
{_a}a{^aa_aa^a}
and it would show up explicitly spelled out in the output.
Furthermore, suppose one is familiar with the kind of ornament, and the
person would like to increase the legibility of the output. Then, by the
introduction of a unary operator as a modifier, say,
!~vibrate!a
only a sign would be printed above the ornamented note, like in
symbola
where symbol could be selected or defined by the user.
In this manner, the U: or m: fields would serve a much broader purpose,
while complying with the current definitions, not to mention the fact
that, as many of you said it before, the primary concern should be the
readability of the source itself without the need for translation or
post processing of any kind, if you will.
Naturally, the playback tools could also make a good use of the modifier
operators, not just the macro commands.
Some were mentioning a 95 versus 5% needing other than ASCII characters.
Well, just in case anyone cares, besides the ascii vowels themselves,
the Hungarian alphabet contanins one accented version of a, e, i and
three of u and o. The same applies for the uppercase letters too. I
myself love TeX and LaTeX, but I never type a Hungarian text for them
directly. I wrote a tiny translator script that replaces every accented
character with its corresponding escape sequence. Although I consider
this procedure well automatized, it's a pretty poor solution. It's
really hard to decypher a text written with multi character escape
sequences if they occur frequently. So, once again, just in case anyone
cares about those 5%, please try to turn to solutions serving the
general public of (possibly) all nations, that is UTF. As a side note,
I'd like to announce that starting October I will make my Hungarian abc
*original* folk tune files available to the open public. There are only
a few for now, but I am working on adding more every day.
Portability is relevant and it constitutes the best brigde among users.
Having that in mind and adding an on-the-fly graphical interpretation
feature to the text editing procedure, has anyone considered Java and
its extensive graphical extension, Swing? By turning to such a platform,
besides solving the portability and licensing issues, the door for
network applications would open much wider as well. Java would be slower
most likely, but still fast enough for the purpose, wouldn't it?
My best regards to the whole group,
Tibor
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Kind of solved (Re: [abcusers] Accented characters in lyrics (abc2ps))
I. Oppenheim writes: | On Thu, 3 Jul 2003, Manuel Reiter wrote: | | sorry to answer my own post, but I've gotten a bit further after some | reading up of Postscript specs and a lot of guesswork. ;-) | | By modifying 'subs.c' and 'syms.c' modified from the | current (08-Apr-2003) version of jcabc2ps jcabc2ps | can handle macron (\=), dot (\.), breve (\u) and | hacek (\v) accents in what I hope is a fairly | portable manner not depending on any special | postscript hardware. | | Thank you for the good work. I hope it'll find its way | to abcm2ps as well. I've discussed with Jef the idea of merging the jcabc2ps extensions into abcm2ps. I'd like to use some of his extensions, too. Maybe we can work on this character-set issue a bit more, and then look into starting the merger. I've looked at abcm2ps, and both of us have made some rather significant changes to the way parts of the code work. No surprise there. Combining them might bit a bit of work. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
On Thu, 3 Jul 2003 [EMAIL PROTECTED] wrote: That's exactly what Abacus does. Version 1 is available from http://www.abacusmusic.co.uk/ but hang around, maybe just for a few days, and version 2 will be out. Seems to be a nice idea! Only too bad that when I made a typing mistake, your application crashed with an Error #5 and no option to save my work... The same happened when I tried to read the Readme through the Help menu. I take it that there is no support for multiple voices [v:] or lyrics [w:] ? Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
On Thu, 3 Jul 2003, Bernard Hill wrote: A short remark about this. Somtimes open source is equated with cost free. But even if I'd produce a Qt-only version, you had to pay a lot. Not to me but to the Qt developer Trolltech and to Microsoft. So what encourages the developer to develop code if there is no payment to the developer? That wasn't the message. The message was: Use Linux and the NoteEdit is cost free! I confess I don't understand the Linux setup *at all*. Perhaps interesting: Two Microsoft ingeneers, Vinod Valloppillil and Josh Cohen had the task to answer this question in an internal Microsoft paper, which was betrayed to the open software foundation. This paper made history as the so-called Halloween Document, see: http://www.opensource.org/halloween The ingeneers came to some very interesting conclusions: Linux's (...) virtues over Windows NT include: - Customization - ... - Availability/Reliability - ... - Scaleability/Performance - ... - Interoperability- ... -- J.Anders, Chemnitz, GERMANY ([EMAIL PROTECTED]) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
Bernard Hill writes: | In message [EMAIL PROTECTED] | chemnitz.de, Joerg Anders [EMAIL PROTECTED] writes | | A short remark about this. Somtimes open source is equated with | cost free. But even if I'd produce a Qt-only version, you had | to pay a lot. Not to me but to the Qt developer Trolltech and | to Microsoft. | | So what encourages the developer to develop code if there is no payment | to the developer? | | I confess I don't understand the Linux setup *at all*. It's basically simple: You get something that a lot of people consider valuable, an OS and lots of software that is very reliable. And since it's open, you can dig into it and quickly make it do what you want. If you find bugs, you can fix them yourself. The only catch is that you have to share your fixes with other users. But that's what makes it valuable to everyone. An anecdote from a few years back that illustrates the idea in a different form: I worked on a few projects where some of the teams were developing on Apollo workstations, and the rest were using Suns. The Apollo users were baffled by why anyone would choose Sun, when for the same performance, the Apollo workstations cost half as much. Invariably, all the teams had problems that they tracked down into the system. The Apollo users would ask Apollo, and be told We can't tell you; that's proprietary. The Sun users would ask on the public Sun and/or unix newsgroups, and would usually get an answer within hours. More often than not, the answer would come from a Sun engineer, and very often included big chunks of code. Here's exactly how it works. Because of this easy access to the innards of the system, the teams working on Suns quickly had working products, while the Apollo users were still trying to debug their code without much understanding what was happening on the inside. Even if the Sun-based systems were a bit more expensive, having a working product was a LOT better than not having one. It should be noted that Sun has since then made their systems a lot more proprietary. And now they're facing a real challenge from linux. The explanation is the same: Software developers on linux can get answers to questions very quickly. Meanwhile, someone developing on Solaris faces brick walls they can't get behind. So the linux developers get things to market much more quickly. Sun is now starting to officially support linux on their boxes. Notice that price isn't the main concern here. The important thing is whether, when you have a problem, you can get an answer. The open source idea is based on this. If the code is available, a programmer can (in principle) find the answer to any question without even asking anyone. In practice, it's even better to ask, because lots of people have the source available, and chances are someone will be able to find your answer very quickly. You don't have to depend on a vendor who is likely to say That's proprietary; I can't tell you. There has been a lot of discussion lately of the mystery of why the open source gang is able to produce software so much faster (and of higher quality) than the industrial model. It seems to violate everyone's mythology of how the market works. But the above anecdote illustrates why it's not a market phenomenon at all. Money doesn't speed up technical achievements; information does. You can't bribe a computer to do what you want; you have to hand it correct software. Proprietary systems hide information from the programmers. The linux, GNU, and other open source approach hides nothing, so everything happens faster. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
In message [EMAIL PROTECTED], A.M. Kuchling [EMAIL PROTECTED] writes On Thursday, July 3, 2003, at 06:43 AM, Bernard Hill wrote: So what encourages the developer to develop code if there is no payment to the developer? Why are there amateur musicians who perform without being paid for it? Because they have other jobs. Why are there no professional musicians who perform without being paid for it? * Playing music is fun, payment or not. It can be quite tedious at times, for professionals... * They want to compose their own music that they'll like better than existing compositions. * They want to perform with their friends. * Or, they want to perform *for* their friends. * Members of the appropriate sex like musicians. So, similarly with programming: * Programming is fun. Not when you do it for a living. * Existing programs may not do what I want, so I'll write my own. * Collaborating with other programmers is fun. * Since I've written the code, why not give it away in case someone else finds it useful? * Here the analogy suddenly breaks down. I'm not an amateur: I live 100% on my programming skills (and marketing and customer support and office cleaning and and and) Music Publisher would not exist if I did not get income from it. It is my *sole* source of income - I am not retired, I do not get a pension, or any allowance or have any other job at all. This is my life. If I give it away I stop developing it because I have to go back to work. Isn't this completely obvious? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
Joerg Anders writes: | On Thu, 3 Jul 2003, Bernard Hill wrote: | I confess I don't understand the Linux setup *at all*. | | Perhaps interesting: Two Microsoft ingeneers, Vinod Valloppillil and | Josh Cohen had the task to answer this question in an internal | Microsoft paper, which was betrayed to the open software foundation. | This paper made history as the so-called Halloween Document, | see: | | http://www.opensource.org/halloween | | The ingeneers came to some very interesting conclusions: | | Linux's (...) virtues over Windows NT include: | - Customization - ... | - Availability/Reliability - ... | - Scaleability/Performance - ... | - Interoperability- ... And in a related story that might mean a lot to the music biz, just yesterday there was the announcement of the Linux Forum that has been formed by most of the big consumer-electronics firms (Sony, Matsushita, Samsung, Sharp, Philips, etc.). The idea here is to develop a common platform with all of the above characteristics. The obvious competitor for all of them is Microsoft's Windows/CE system. But they have explained that in a market with competition, any company that has to include Microsoft royalties in their product is going to lose. And since the innards of Microsoft's system are not easily available to them, development on W/CE is slow and under Microsoft's control. Their target has a historic metaphor. We're all familiar with the old distinction between a does everything box, versus buying components and plugging them together. If you just want a single gadget and aren't too concerned with quality, you can buy a boom-box or similar all-in-one package, and be done with it. Or you can buy components, go through all the fuss of making them play nice together, and end up with much higher quality. We've long had a market for both. This Linux Forum idea sounds a lot like they're abandoning the boom-box approach to Microsoft and are aiming at a large market for components that speak common protocols. By sharing the low-level code and protocols, they may be able to make components that play together without the usual grief. Linux is the basis simply because they can get their hands on all the source, without restrictions or royalties. Their add-on software will be proprietary (and possibly pricey), but they've seen the advantage to making the lower layers shared across the industry. They can probably avoid charges of collusion and monopoly as long as the low-level stuff is kept open and available to everyone. One thing that has apparently been a shock to them: The new Apple iTunes store ($0.99 per track) is a fantastic success. But it uses a proprietary format that doesn't play on anything but a Mac. Apple is talking about a Windows version. This locks out ALL the vendors in this Linux Forum effort. They've gotta be thinking about the end of their business, with Microsoft owning the industry. Anyway, it'll be interesting to see how it works out. Will there be only one big boom-box for sale? Will there be a hundred vendors of quality audio and video systems? Wait and see ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
In message [EMAIL PROTECTED], Calum Galleitch [EMAIL PROTECTED] writes On Thursday 03 July 2003 10:43 am, Bernard Hill wrote: So what encourages the developer to develop code if there is no payment to the developer? AMK mostly summarised it. I found it difficult to really understand why it took off until I read what RMS (Richard Stallman) wrote about it (from memory): I cannot enjoy a piece of software without sharing it with my friends. He goes on to explain that this has to mean creating Free software, but that one sentence is as succinct as I think you can get. When you consider that a bunch of mostly unpaid developers created from scratch an operating system and a complete suite of software which I've been using as my only desktop for almost a year, that's quite something. That doesn't mean that all software should be made Free. Your software is unique, as far as I know, in coming as close to a freehand notation package as possible. I don't think there's anything else with your focus. In turn, that means there isn't all that many folk that need exactly what you provide (but the folks like Willie Donaldson who do, really do). So charge them for it. And when you're retired, and you're looking at spending your time in a rocking chair, whack a GPL on it and bask in the knowledge that people are benefitting from your generosity. In the meantime, earn your living. There is a kind of zone in between two kinds of software, the one-man project of very specialised interest (abc*ps would be at the upper end of this), and high-usage applications where many developers can collaborate to create a replacement for commercial software. This zone, where your application sits, is probably the least suited to Free software. I confess I don't understand the Linux setup *at all*. Neither do I, I'm just grateful. Cheers, Thanks for your time in explaining that. And I like the description of my software... I might even use it in my advertising with your permission - ? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Modularity and customisability
I think my notion of modularity has been somewhat mis-represented.
Perhaps the idea as other folk have it is a good one, maybe better than mine.
I'll leave that decision to others [1], but as I think my original notion has
been misunderstood, I'll try and explain it a bit better than I did the first
time.
ABC has too many uses as it stands. It was designed to notate a single stream
of monotonic, diatonic melody. Now it is being used for everything and their
grandmother's kitchen sink. It's a testament to the developers and standards
people that it's been able to grow from these beginnings, but it's starting
to creak at the seams. Those who attempt typesetting with abcm2ps soon learn
to give up any notion of readability, likewise any hope that their efforts
will be of any use to any other piece of software, at least in terms of all
the meta-work that went into it. I'm sure other package users have similar
problems.
What I'd like to suggest (and it is only a suggestion; I certainly don't have
the skills to implement anything of the sort) is a completely open system,
where notation itself is just one element. The user would be able to specify
(I'm trying not to say 'scripting language' here) the behaviour of the
application, from parsing setup, playback instructions, through to being able
to deal with actually drawing in a custom manner.
What this means:
A scripting language. I've been thinking about this, and wondering if it
really is neccesary, and I think it is. What I envisage is a system where
everything is done in terms of this scripting language, running on top of an
application (ie postscript, MIDI, whatever). The entire default source for
this is available for the user to view, and the user can insert custom
modifications into his own files. What I imagine is a kind of tree
structure, analogous to the Javascript document model, where you might have:
source.draw.line.stave {
goto clef_start_point
draw_clefsymbol
loop_of_some_sort(5) {
goto point_to_draw_from
draw line
}
}
Now suppose our user wants to draw a drum stave, for notating percussion. He
just inserts in his file:
source.draw.line.stave {
goto clef_start_point
draw_custom_drummer_symbol //kinda wingin it here
goto point_to_draw_from
draw line
}
Obviously, there's a few holes needing filled in (!), but I hope you get the
idea.
All this is obviously a bit much to expect from users; this is where the
modularity comes in. Included with MagicalABC [2] are dozens of files of
custom code, which you can include in your own files, for all sorts of unique
and clever purposes. Users with specific individual needs, like pipers or
microtonalists, can just read the help file for their particular module, and
the majority need never worry about it. Those who suddenly decide they want
to do something new and exciting can go about hacking away without having to
try and figure out how the entire application works and recompile it, even
assuming that's an option for them.
The idea is that the standard scripts would implement what is currently done
inside applications, doing the pre-processing, parsing, and outputting some
sort of standardised stream to the actual application engine. The default
should be some widely recognised ABC standard, whether 1.6, 1.7.?, or Guido's
ABC 2.0. It also makes sense, BTW, for the scripts (and engine?) to be GPL
or some similar license (perhaps BSD would be more reassuring to developers
whose food depends on their work), so developers don't all have to go
implementing their own, and ending up with something like the STL was back
when I could program.
This whole approach means basically starting again, creating a scripting
engine, reimplimenting the applications in the scripts themselves, and
creating a surface layer to do what the thing is supposed to do (write
postscript, etc). [3]
OTOH, I think in the long run, it could be less work. If the output from the
scripting engine is well defined and documented, and free from user inserted
daftness or clumsiness, then that should be easier for developers to work
from. Yes/No/Maybe? Also, it means that output is simplified; just output a
plain text description of your format along with the neccesary script to deal
with it.
As I said before, I'm strictly an ideas rat. I have enough knowledge of
programming to talk about it, but not enough to do it. Maybe I should work
at the BBC...seriously, I think this approach has merit, or it will have once
some folk who know what they're doing have had their way with it. At the end
of the day, none of us can see all the uses ABC or its descendants might be
put to, and to try to cater for them all is courting disaster.
I'd be interested to hear what developers in particular think of this notion,
not so much in terms of their particular application, but the idea itself.
Cheers,
Calum
[1] - My argument against modularity is that it sounds like
Re: [abcusers] bloody ! again
On Thu, 3 Jul 2003, Bernard Hill wrote: As a programmer I'm very concerned about ! as a line terminator. Now add two line terminators (presumably not illegal) abc abc|!trill! abc abc|! abc abc |! abc abc| According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator; the newline (\n) terminates the INPUT line. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
In message [EMAIL PROTECTED], John Chambers [EMAIL PROTECTED] writes Bernard Hill writes: | In message [EMAIL PROTECTED] | chemnitz.de, Joerg Anders [EMAIL PROTECTED] writes | | A short remark about this. Somtimes open source is equated with | cost free. But even if I'd produce a Qt-only version, you had | to pay a lot. Not to me but to the Qt developer Trolltech and | to Microsoft. | | So what encourages the developer to develop code if there is no payment | to the developer? | | I confess I don't understand the Linux setup *at all*. It's basically simple: You get something that a lot of people consider valuable, an OS and lots of software that is very reliable. And since it's open, you can dig into it and quickly make it do what you want. If you find bugs, you can fix them yourself. The only catch is that you have to share your fixes with other users. But that's what makes it valuable to everyone. An anecdote from a few years back that illustrates the idea in a different form: I worked on a few projects where some of the teams were developing on Apollo workstations, and the rest were using Suns. The Apollo users were baffled by why anyone would choose Sun, when for the same performance, the Apollo workstations cost half as much. Invariably, all the teams had problems that they tracked down into the system. The Apollo users would ask Apollo, and be told We can't tell you; that's proprietary. The Sun users would ask on the public Sun and/or unix newsgroups, and would usually get an answer within hours. More often than not, the answer would come from a Sun engineer, and very often included big chunks of code. Here's exactly how it works. Because of this easy access to the innards of the system, the teams working on Suns quickly had working products, while the Apollo users were still trying to debug their code without much understanding what was happening on the inside. Even if the Sun-based systems were a bit more expensive, having a working product was a LOT better than not having one. It should be noted that Sun has since then made their systems a lot more proprietary. And now they're facing a real challenge from linux. The explanation is the same: Software developers on linux can get answers to questions very quickly. Meanwhile, someone developing on Solaris faces brick walls they can't get behind. So the linux developers get things to market much more quickly. Sun is now starting to officially support linux on their boxes. Notice that price isn't the main concern here. The important thing is whether, when you have a problem, you can get an answer. The open source idea is based on this. If the code is available, a programmer can (in principle) find the answer to any question without even asking anyone. In practice, it's even better to ask, because lots of people have the source available, and chances are someone will be able to find your answer very quickly. You don't have to depend on a vendor who is likely to say That's proprietary; I can't tell you. There has been a lot of discussion lately of the mystery of why the open source gang is able to produce software so much faster (and of higher quality) than the industrial model. It seems to violate everyone's mythology of how the market works. But the above anecdote illustrates why it's not a market phenomenon at all. Money doesn't speed up technical achievements; information does. You can't bribe a computer to do what you want; you have to hand it correct software. Proprietary systems hide information from the programmers. The linux, GNU, and other open source approach hides nothing, so everything happens faster. ... none of that tells me why anyone creates software in the first place. I do not start projects which are not going to bring money in. I see clearly that as an end-user having the source code is beneficial - but what's in it for the programmer who created it? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
In message [EMAIL PROTECTED], I. Oppenheim [EMAIL PROTECTED] writes On Thu, 3 Jul 2003, Bernard Hill wrote: As a programmer I'm very concerned about ! as a line terminator. Now add two line terminators (presumably not illegal) abc abc|!trill! abc abc|! abc abc |! abc abc| According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator; the newline (\n) terminates the INPUT line. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. I don't understand what you are saying at all. According to a previous writer, abc abc|!bcd bcd| is equivalent to abc abc| bcd bcd| IOW the ! simulates a line break. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. The end itself forces a line break, no? Bernard Hill Braeburn Software Author of Music Publisher system Music Software written by musicians for musicians http://www.braeburn.co.uk Selkirk, Scotland To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
On Thu, 3 Jul 2003, Bernard Hill wrote: According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator; the newline (\n) terminates the INPUT line. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. I don't understand what you are saying at all. According to a previous writer, abc abc|!bcd bcd| is equivalent to abc abc| bcd bcd| IOW the ! simulates a line break. No, that is the idiosyncrasy of the ABC2WIN program or what it was called. It is obvious that that won't work together with the !...! notation. On the contrary, the way it is defined in the above BNF standard (have you actually read it?) works quite well. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. The end itself forces a line break, no? The newline only marks the end of the INPUT line; where the line breaks will be in the resulting OUTPUT is up to the software to decide. If the user wants to overrule the default layout algorithm, he can force a line break by ending the input line with a ! I hope it's now a bit more clear... Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Web graphics
Eric Luis, Thank you so much for your advice. It turned out that those gray lines where indeed caused by the antialias parameter of ghostscript. I found out that the Helvetica font probably gives the best readable results on low resolution. So here's what I managed to achieve: http://www.joods.nl/~chazzanut/in/compare.html The uppermost picture is the ideal output of the musicator program; the picture below is what I achieved with Abcm2ps. Do you have any hints to further improve the Abcm2ps output? In particular it seems that the notes are to bold. Groeten, Irwin Oppenheim [EMAIL PROTECTED] ~~~* Chazzanut Online: http://www.joods.nl/~chazzanut/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
[!...!] is peculiar to abcm2ps It's in the new standard 1.6 and will completely screw up ABC2WIN (which uses ! as a line terminator). Strikes me that it's abc2win which is up the gum tree for this one. And I find very strange stuff in abc2win: a) +..+ for chords b) the writing of grace notes as 1/16th notes rather than 1/8th as below c) doesn't allow change of metre/key in the middle The second has nothing to do with ABC, it's a display issue. The first is no longer an issue; ABC2WIN users stopped doing it years ago (it was in a very old ABC standard). The last is a limitation of the sort many implementations have; in this case it doesn't matter because (if it's still there) ABC2WIN can't process *any* ABC representation of the music, whatever syntax we were to choose to represent key/metre change. It isn't the syntax that's boggling the program, it's the music itself. But there are thousands of tunes out there using ! as a line terminator; like it or not, that is one feature of ABC2WIN's syntax that caught on. They matter more than any one application. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] A bit of history
I argued already in another e-mail why ABC software should NOT assume that a bare newline indicates the end of a music line. The software should do the line formatting itself, and if the user should wish to override the default behaviour, he could use the !-newline notation to force a linebreak. !-newline is exactly what I DON'T want. The point of ! is to get a break in the staff display WITHOUT having a newline in the source. : As a programmer I'm very concerned about ! as a line terminator. : Consider this abc fragment: : abc abc|!trill! abc abc|! abc abc |! abc abc| : how does a program distinguish between the !trill! command and a command : ! abc abc|! which may be a command for a feature which it knows nothing : about? By making the !...! syntax for commands illegal so that the program will never encounter it. You get one or the other. There is no reasonable alternative providing what ABC2WIN does for line termination; there are plenty of alternatives (and better ones) for user-definable stuff. + having a line terminator is a great help in resolving the conflict + between making ABC source-readable and having it generate readable + staff notation. [my suggestion] + Bee Te2d |ege dBG| Bee Te2d |BAG E3:|\ + BGG GAG|BAG ABd|!BAG GAG|ABG E3 |\ + BAG GAG |BAG ABd| Bee e2d |BAG E3|] + Um. I must be missing something. Isn't + Bee Te2d |ege dBG|Bee Te2d |BAG E3:|BGG GAG|BAG ABd| + BAG GAG|ABG E3 |BAG GAG |BAG ABd|Bee e2d |BAG E3|] + the simplest??? It obscures the visual parallelism between bars 3 and 4 and bars 11 and 12, and the identity between bars 8 and 10, so it simply doesn't meet the constraints I was setting. This tune is in four-bar phrases and my ABC represents that. *All* yours does is generate the final staff notation in the format needed - not a great deal of use if the software has pushed you into a way of working that made you get the source wrong in the first place. This sort of parallelism is VERY important if you are trying to transcribe accurately from printed sources. My error rate would go up by a factor of 100 if I couldn't lay source out like that, and I wouldn't even have contemplated the Aird project I'm currently working on if I only had staff notation as a check on my accuracy. I have copies of attempted transcriptions of the same tunes by other people, using free-format ABC aimed only at getting staff notation output. EVERY SINGLE TUNE I'VE LOOKED AT has multiple errors, and there are 1200 of them in the collection. I'm redoing it all from scratch. (Many of the errors are because the other people were working from xeroxes, but even there a parallelized layout can make you think hmm, that can't be right and go back to see if what you thought was a staccato mark might actually be a durational dot or a fly turd). I am trying to use ABC to make something people will want to buy. If there's any chance it has a significant error rate they won't buy it. I have no interest in using software that encourages sloppy scholarship. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator; the newline (\n) terminates the INPUT line. When a bang appears at the very END of such an input line, it forces a line break in the music OUTPUT. Apparently that's not true of the program (abc2win) in which this usage started, since you can find abc2win files on the net with exclamation marks in mid-line. How did this usage (exclamation mark at the end of line) get into the BNF definition anyway, since it has never been part of the abc standard? Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
I.Oppenheim wrote: On Thu, 3 Jul 2003 [EMAIL PROTECTED] wrote: That's exactly what Abacus does. Version 1 is available from http://www.abacusmusic.co.uk/ but hang around, maybe just for a few days, and version 2 will be out. Seems to be a nice idea! Only too bad that when I made a typing mistake, your application crashed with an Error #5 and no option to save my work... That's the problem with live editing. The parser has to be absolutely bullet-proof, as the user can hit it with absolutely any combination of symbols. There is really no way you can test it enough either. That's one reason why I kept BarFly free for several years while under development - I needed the whole community of users to use it and tell me about the bugs in order to get it to its current state. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
According to the BNF definition http://www.norbeck.nu/abc/abcbnfx.htm The bang is NOT a line terminator Which was a booboo on the part of whoever let that through. Supporting the existing corpus of tunes is *alone* more important than allowing an inessential idiosyncratic extension in one application. I don't understand what you are saying at all. According to a previous writer, abc abc|!bcd bcd| is equivalent to abc abc| bcd bcd| IOW the ! simulates a line break. It does in ABC2WIN, but as far as I know it doesn't yet in any other application. Which is a pain in the bum because it's a really good idea and far more useful in the long term than the !...! constructs. - Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 http://www.purr.demon.co.uk/jack * food intolerance data recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM Embro, Embro. -- off-list mail to j-c rather than abc at this site, please -- To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
Irwin Oppenheim said - On Thu, 3 Jul 2003 [EMAIL PROTECTED] wrote: That's exactly what Abacus does. Version 1 is available from http://www.abacusmusic.co.uk/ but hang around, maybe just for a few days, and version 2 will be out. Seems to be a nice idea! Only too bad that when I made a typing mistake, your application crashed with an Error #5 and no option to save my work... Could you send me details? If you can tell me exactly what that typing mistake was, I'll do my best to fix it. and - The same happened when I tried to read the Readme through the Help menu. Worrying. I've changed the way I do this in the next release so perhaps it will go away. (Plze!) and - I take it that there is no support for multiple voices [v:] or lyrics [w:] ? Not yet; w: because that comes under future developments and V: because, like many others, I'm waiting for a single coherent specification of how it should work. I have my preferences, but I'll settle for something else if I know it's going to be generally accepted. Bryan Creer To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
On Thu, Jul 03, 2003 at 11:41:26PM +0100, Phil Taylor wrote: I.Oppenheim wrote: On Thu, 3 Jul 2003 [EMAIL PROTECTED] wrote: That's exactly what Abacus does. Version 1 is available from http://www.abacusmusic.co.uk/ but hang around, maybe just for a few days, and version 2 will be out. Seems to be a nice idea! Only too bad that when I made a typing mistake, your application crashed with an Error #5 and no option to save my work... That's the problem with live editing. The parser has to be absolutely bullet-proof, as the user can hit it with absolutely any combination of symbols. There is really no way you can test it enough either. That's one reason why I kept BarFly free for several years while under development - I needed the whole community of users to use it and tell me about the bugs in order to get it to its current state. Which is another answer to the why write Free Software ? question - Eric Raymond's Many eyeballs make any bugs shallow. Which seems to lead to the conclusion that programs that need paying for don't work as well, which is distinctly perverse and I'm sure it ain't necessarily so ... runs away, fast -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
Bernard Hill writes: | | ... none of that tells me why anyone creates software in the first | place. I do not start projects which are not going to bring money in. I | see clearly that as an end-user having the source code is beneficial - | but what's in it for the programmer who created it? Fame? Of course, it could be just accidental. Consider my tune finder. I wrote it originally for very selfish reasons. I'd noticed that there were a lot of collections of tunes in abc format appearing on the web. But when I wanted to find a tune, I had to dig through all of them. And they were all laid out differently. But I'm a programmer. So I naturally thought This is a job for a computer, not a human. I happened to be somewhat familiar with the web, and knew perl pretty well. So I decided to write myself a little web search program. How hard can it be? It was a bit harder than I thought, but not much. Pretty soon I had some html files full of indexes and titles of the tunes and the URLs where I could find them. Then, being an especially lazy programmer, I wrote a little web page that let me enter a pattern to match, and a cgi script to run through the index file and show me the matches. Then I made the mistake of mentioning it to a few friends. There's no way that I can think of to make money from this yet. Yeah, google.com is profitable, but how can you get musicians to pay to look up things like this? Anyway, my web site is on a departmental machine at MIT. They are happy to see people developing interesting and innovative things on their machines, but they have a pretty strict rule that anything that makes money has gotta go. Not that they disapprove of making money; they just can't have it happening on the departmental machines. So the obvious thing is to GPL it all. In fact, all my code is sitting there in directories that you can read, so if you like, you can grab a copy and run your own tune search. So far, I don't know of anyone who has done this. I'm not surprised; it would be a learning experience. If someone does, I hope they honor the GPL and share any improvements with me and the rest of the world. It has got me a bit of notoriety. But mostly, it has given me a fairly convenient way of finding tunes any time I'm near a machine with web access, which is getting to be more and more of the world as time passes. If it helps other people too, well, as long as it's a small load on the machine (and it's a tiny load so far), they're welcome. The department likes the publicity, my name gets known among a select crowd (that's you folks). And I can use it whenever I like from anywhere. Does this need any more explaining? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] bloody ! again
Jack Campin writes: | | But there are thousands of tunes out there using ! as a line terminator; | like it or not, that is one feature of ABC2WIN's syntax that caught on. | They matter more than any one application. I've had to face this with my tune finder's scripts. What I did was to add some rather simple code to abc2ps to try to spot these abc2win bangs and ignore them, while accepting the !...! terms that look like musical annotations. The heuristic when a ! is encountered is to scan for another and count any special characters. If any bar-line chars ([|:]) are spotted, it's immediately taken as an abc2win ! and dropped. If no matching ! is found, it's also dropped. This is somewhat crude, but it seems to work. So if we look at an example like an earlier one: | abc abc |!fff!fff!def def | The first ! would be taken as the start of !fff!, which is a valid annotation. The third ! fails on both tests, so it's an abc2win !. This gives: | abc abc |!fff!fffdef def | This was probably not what was intended, but it's valid abc notation. Of course, abc2win output doesn't contain !...! annotations. We should note that abc2win's ! does not found only at the end of a line. I've seen them in the middle of lines. And I've seen lines with two of them (one near the beginning and one near or at the end of the line). When ! is inside a line, there is almost always a | somewhere to the right. Possibly we could just add a warning about this problem to the standard (perhaps in an Implementation Suggestions section), and suggest this approach for dealing with it. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Free notation program for Windows - let's write it...
From: Calum Galleitch [EMAIL PROTECTED] Date: Thu, 3 Jul 2003 20:03:01 + That doesn't mean that all software should be made Free. Your software is unique, as far as I know, in coming as close to a freehand notation package as possible. I don't think there's anything else with your focus. In turn, that means there isn't all that many folk that need exactly what you provide (but the folks like Willie Donaldson who do, really do). So charge them for it. And when you're retired, and you're looking at spending your time in a rocking chair, whack a GPL on it and bask in the knowledge that people are benefitting from your generosity. In the meantime, earn your living. Another angle is the business model that a former employer of mine (Cygnus Solutions) used. Cygnus sold commercial-grade support and development for free software. They got bought by Red Hat in 2000, but up to that point, they were best known for their support of gcc (the Gnu C Compiler). The way this worked was that customers would purchase Cygnus's support for gcc, which meant that they would get a version from our CVS tree, which we would be expected to support and provide bug fixes, on the time scale that companies expect for commercial software. Cygnus shipped the compiler with source code, which was freely modifiable and distributable (under the GPL). Customers could also hire Cygnus to add specific features or optimizations that they needed, again with development to be done on the time scale that companies expect for commercial software. Cygnus contributed all of its code back to the FSF on a more-or-less quarterly basis, so the open source community did eventually reap the benefits of the work that Cygnus did. Again, this is not to say that all software has to be free, only that there are companies that have succeeded in making money from free software. Jeff To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
