Re: [abcusers] Tuplets
At 05:18 PM 10/27/2000 -0700, you wrote: > A triplet in abc2mtex is written (3abc; in abc2ps, it's >((3abc)---the slur has to be put in explicitly. (Technically, I don't >think it's a slur--it's just a grouping symbol to catch the eye, and it's >often denoted with an angular slur, instead of the usual curvy one. > > Question: do people ever write triplets without that slur mark? >(Silly question--we're talking about music, so of course, *someone's* >bound to do it.) But is it common? I do. It's not at all uncommon in Cape Breton music to single- bow triplets, especially when they turn up as pick-up notes in clogs. So I transcribe them the way I play them. I will point out here that I'm referring to triplets where the three notes have *different* pitches, because that type of triplet isn't the same thing as a cut (2 16th notes and one 1/8 note of the same pitch). However in thumbing through O'Neill's, I see triplets that are comparable to CB cuts - three notes of the same pitch. As an example, (AAA turns up twice in the A part of Pigeon on the Gate. That sequence wouldn't make any sense with a slur mark. I often use abc2mtex, and have to >re-edit tunes each time I want to print them out in abc2ps. It would be >handy if ((3abc) and (3abc were considered to be equivalent. But you'd lose the option of notating triplets without them. > In fact, both notations have a practical drawback: they unbalance >the parentheses. The compromise notation (3abc) would have the advantage >of balancing the parentheses, allowing one to use the brace-matching >present on lots of text editors to check for runaway slurs. (I seem to >remember starting some slurs that ended ten tunes later...:-) They do sort of jump off the page at you when you print, don't they? :-) Wendy To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Good quote
> "jc" == jc <[EMAIL PROTECTED]> writes: jc> Laura Conrad wrote: jc> | In free software, the fact that something is possible doesn't jc> | guarantee that it will happen; it's the fact that it's possible and a jc> | lot of the people who could do it want it. jc> Hey, that's a nice, succinct statement. Mind if we quote you? I'd want to work on it before I saw it on very many bumper stickers. -- 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
[abcusers] Tuplets
A triplet in abc2mtex is written (3abc; in abc2ps, it's ((3abc)---the slur has to be put in explicitly. (Technically, I don't think it's a slur--it's just a grouping symbol to catch the eye, and it's often denoted with an angular slur, instead of the usual curvy one. Question: do people ever write triplets without that slur mark? (Silly question--we're talking about music, so of course, *someone's* bound to do it.) But is it common? I often use abc2mtex, and have to re-edit tunes each time I want to print them out in abc2ps. It would be handy if ((3abc) and (3abc were considered to be equivalent. In fact, both notations have a practical drawback: they unbalance the parentheses. The compromise notation (3abc) would have the advantage of balancing the parentheses, allowing one to use the brace-matching present on lots of text editors to check for runaway slurs. (I seem to remember starting some slurs that ended ten tunes later...:-) Cheers, John Walsh To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
> "Christophe" == Christophe Declercq <[EMAIL PROTECTED]> writes: Christophe> Changing symbols size is very easy with abc2ps. >> >> 6. Page design >> When it comes to adjusting the page design - the font, size and >> positioning of titles etc., the space between the staffs, all those text >> blocks you need... >> Well, there simply is no such thing in abc2ps. Christophe> False. There is. As I said, read the doc. >> Oh, I suppose there is some obscure %% command that can do some of the >> job, but it's not nearly enough - and far too complicated in any case. Christophe> Nothing complicated at all. Just read the doc (again) Christophe> and learn to use it. I think I've learned to use abc2ps pretty well, but I don't use it for mixing text and music , and I've never figured out how to put the date of printing on the page, and I don't know how to do an incipit in a smaller music font size. (If there were syntax for the clefs I needed in an incipit.) If you think these things are possible, can you post an example? -- 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] free Finale
> De : Frank Nordberg <[EMAIL PROTECTED]> > A : [EMAIL PROTECTED] > Objet : Re: [abcusers] free Finale > Date : vendredi 27 octobre 2000 22:24 > [...] > 5. Readability. >I've already mentioned some factors that affect readability, such as > the incorrect propotion between note head size and line spacing, and the > slightly cramped allotment, but the overall scaling is far too small > too. I'd hate to be force to sightread complex music printed from > abc2ps. This seems to be a part of the general "early 20th century > British trad. music" style. It seems the trend there was to try to get > as much music as possible onto a page. That was, of course, done to > reduce printing costs, and I'm pretty certain that it was the only way > to publish something like the two O'Neill books at a reasonable price. > It does, however make the notation ahrder to read, and also very > vulnerable to print-quality reducing processes like photcopying, > on-screen viewing and converting to web graphics. OK, abc2ps is not Finale and the abc2finale idea seems good if you want it (for my own usage, I would prefer an update of abc2mTeX). But, please be honest and read the doc (the userguide in the abctab2ps distribution is excellent) before speaking too loud. Changing symbols size is very easy with abc2ps. > > 6. Page design >When it comes to adjusting the page design - the font, size and > positioning of titles etc., the space between the staffs, all those text > blocks you need... > Well, there simply is no such thing in abc2ps. False. There is. As I said, read the doc. > Oh, I suppose there is some obscure %% command that can do some of the > job, but it's not nearly enough - and far too complicated in any case. Nothing complicated at all. Just read the doc (again) and learn to use it. BTW, I can understand that transcribing O'Neil's book doesn't let that much time to read the manuals ;) Christophe To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
Bob Archer wrote: > > Things like slurs are incredibly difficult to get right in all situations > and I was wondering if a program like Finale would do a better job with > them than some of the abc software. With Finale NotePad you can reshape, resize and reposition individual slurs to your heart's content. But just slurs, not ties. And you can't change the default, just modify them afterwards. You need one of the larger Finale versions for those functions. Frank To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
> "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes: Frank> My main arguments for an ABC-to-ETF converter is: Frank> c) whether we like it or not, ETF seems at the moment to be the only Frank> open and actually functioning music notation format on a complexity Frank> level above ABC. If it's a complexity level above ABC, then are you sure there can be a converter at all? Frank> d) I believe an ABC-to-ETF converter would be far easier to Frank>make than Frank> any of the other converters we have been talking Frank> about. Both are plain text formats, and most every function Frank> in ABC has it's direct equivalent in ETF. But mind you, I Frank> said "I believe". I have to admit I don't have nearly Frank> enough programming knowledge to claim anything like that Frank> for sure. If I had that, there wouldn't have been any such Frank> discussion. I would just have done that job myself. It doesn't take programming knowledge -- have you ever been able to write an etf file by hand, from just the information in an ABC file? If that can't be done, nobody can write a program to do it either. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org ) (Note the email and homepage address changes; please update your address book, bookmarks, and links.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
> "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes: Frank> well, the answer to that is both yes and no. It's obviously wrong to Frank> claim that all commercial software manufacturers think of Frank> is profit. The point isn't that commercial software is evil; it's that there is such a thing as a standard that it's safe to write to, and as far as I know etf isn't such a thing. My guess is that the definition of valid etf is "what works in finale". >> but as far as I know the etf format isn't guaranteed not to change. Frank> True - just like everything else. No, not like html 3.0. There will be an html 4.0, which will be different, but if I say this is html 3.0, an html 3.0 parser is going to know what to do with it. And I can write an html 3.0 parser from publicly available documents, without buying a particular commercial product, or booting a particular OS. >> And I don't know what the quality of the documentation is. Frank> Do you want me to send you a copy so you can see for yourself? Sure. But that's not going to get anyone an etf converter. I'm already working on abc2ly, and thinking about working on abc2mtex. Someone who has a copy of finale installed on an os they can stand booting is going to have to do the etf stuff. >> I don't know on what you base that prediction. Frank> Oh well, I can dream, can't I? And I can have nightmares about etf format "upgrades". -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org ) (Note the email and homepage address changes; please update your address book, bookmarks, and links.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
Bob Archer wrote: > > At 09:05 PM 26-10-00 +0200, Frank Nordberg wrote: > > >Philip Rowe wrote: > > >> Is the printed output better than anything the ABC community can > >> offer? > > > >Yes. > > That sounds like a challenge to me. In what way is the current output of > abc programs lacking? > > Bob First, to stop any possible complaints about confusing muscal data with formatting, we're talking the output from abc programs here, not ABC itself, so this time the formatting isn't only relevant, it's the main issue. It's also important to note that I'm talking about music notation in general. I find many of the abc-graphics programs to very suitable for certain music styles, the one each was originally made for, and a couple of others that just happens to fit in. Finally, the issue here is grpahics "tadpole" notation directly from ABC. Converting ABC to some high-level notation system like Lilypond is a completely different issue. I think I'll simplify it by concentrating on abc2ps and it's many clones. Seems to me they account for more than 90 % of the graphical output from ABC files nowadays. (The only other program that comes even close in volume is BarFly, and nobody has ever claimed that to have high quality professional graphics output.) I think I can list six main reasons why I as a professional music trancriber can't use abc2ps. 1. Lack of features in ABC This alone would be enough to exclude any ABC-to-graphics converter from professional high-level work. Apart from my own just-for-fun trad. music transcriptions, I can't think of a single notation job I've had that didn't at least require some dynamic markings. I could list other music notation symbols misiing in ABC too, but I wouldn't know where to stop, and you wouldn't like to get a 1MB+ e mail message. 2. Lack of fine control No matter how good algorhihms a program uses for positioning the various objects, some manual fine tuning is always needed. You might have to shorten the stem of a ingle note a millimeter or two, a rest may have to be positioned slightly higher or lower to avoid colliding with notes in another part on the same staff etc. Most important are the accentuation and slur problems. You'll almost always need some manual fine tuning of that. 3. Allotment The allotment (note spacing) table used by abc2ps is pretty fair. Not very good (it tenbds to position the notes a bit too close to each other), but not too bad either. But it's not nearly flexible enough. It simply isn't possible to create a algorhitm for this that works every time. Since we're comparing with Finale NoetPad, not the real Finale, I have to admit that this is one of the major weaknesses of that program too ;) 4. Notation style abc2ps uses a very idiosyncratic that shouts out "early 20th century British traditional music). I find it quite pretty to be honest, but I can't say it's very appropriate for many other music style. There is also some general flaws in the abc2ps note symbol design. Most important is that the note heads are too big - or the lines are too close together... In addition abc2ps isn't always very conesquent when it comes to style. The tr trill symbol for example, is in a very "modern classic" style and doesn't fit the general notation style at all. (We had a similar discussion at the smt maillist a while ago, btw. Some person - I don't remember his name - claimed that the even more idiosyncratic "jazz" notation developed by US studio musicians from the circuits around Basie's band in the 50s and 60s was *the only* correct notation style.) Again, I have to admit that Finale NotePad doesn't perform too well in this respect either. Unlike the real Finale you are stuck with one music font. But at least that font (Maestro) is a bit more neutral. 5. Readability. I've already mentioned some factors that affect readability, such as the incorrect propotion between note head size and line spacing, and the slightly cramped allotment, but the overall scaling is far too small too. I'd hate to be force to sightread complex music printed from abc2ps. This seems to be a part of the general "early 20th century British trad. music" style. It seems the trend there was to try to get as much music as possible onto a page. That was, of course, done to reduce printing costs, and I'm pretty certain that it was the only way to publish something like the two O'Neill books at a reasonable price. It does, however make the notation ahrder to read, and also very vulnerable to print-quality reducing processes like photcopying, on-screen viewing and converting to web graphics. 6. Page design When it comes to adjusting the page design - the font, size and positioning of titles etc., the space between the staffs, all those text blocks you need... Well, there simply is no such thing in abc2ps. Oh, I suppose there is some obscure %% command that can do some of the job, but it's not nearly enough - and far too complicated in any case. --- Af
Re: [abcusers] free Finale
Laura Conrad wrote: > > > "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes: > > Frank> I don't know what you mean with "stable", Laura. Finale has > Frank> been around for more than ten years now and has remained > Frank> more or less the industial standard for most of that > Frank> period. > > I may be tarring all commercial developers with the Microsoft brush, well, the answer to that is both yes and no. It's obviously wrong to claim that all commercial software manufacturers think of is profit. But most of them are certainly more concerned about money than what is healthy - although luckily very few are as extreme as MS. The Finale manufacturer, Coda, started off as an extremely idealistic company, run by and for musicians. After a while it suddenly became extremely commercial, porting the program to Windows with the sole purpose of widening the market, reducing user support and general following up to less than bare-bones and venturing into marketing campaigns with claims they couldn't possibly fullfill. Fortunately this didn't last very long, and I'd say that Coda today is about average - perhaps slightly better - for a commercial software house. But Open Source isn't the One Great Solution To All Software Problems either. All this talk abut free software is nice, of course. Unfortunately the TANSTAFL principle applies here as everywhere else. TCO is difficult - often impossible - to calculate, but that doesn't mean it's not important. One of the most common arguments I hear used against commercial software, is that the user has far to little influence over how the program is to be. I suppose that is true. In fact I believe that statement is equally true for commercial programs and for Open Source. > but as far as I know the etf format isn't guaranteed not to change. True - just like everything else. > And I don't know what the quality of the documentation is. Do you want me to send you a copy so you can see for yourself? > > Frank> I don't think any other notation software system can claim > Frank> anything like that. ETF files writeen ten years ago are > Frank> still fully readable by today's versions of Finale (and > Frank> soon Lilypond as well). > > I don't know on what you base that prediction. Oh well, I can dream, can't I? Frank Nordberg To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
At 01:38 PM 27-10-00 -0400, Laura Conrad wrote: >> "Bob" == Bob Archer <[EMAIL PROTECTED]> writes: > >Bob> At 09:05 PM 26-10-00 +0200, Frank Nordberg wrote: >>> Philip Rowe wrote: > >>>> Is the printed output better than anything the ABC community can >>>> offer? >>> >>> Yes. > >Bob> That sounds like a challenge to me. In what way is the >Bob> current output of abc programs lacking? > >To some extent that's an esthetic judgement. I have posted some of my >recent results with converting abc to lilypond; if you want to compare >them look at >http://www.laymusic.org/music/dowland/unquiet/allparts.pdf, which is >from abc2ps, and compare it with the first song in >http://www.laymusic.org/music/dowland/book/dowland.pdf, which is from >lilypond. Thanks Laura. I should have been a little more clear in what I said. I was thinking specifically of the quality of the output on features that are supported by abc rather than features that aren't available. I don't know if this is what Frank Nordberg was thinking of. Things like slurs are incredibly difficult to get right in all situations and I was wondering if a program like Finale would do a better job with them than some of the abc software. Bob To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
> "Bob" == Bob Archer <[EMAIL PROTECTED]> writes: Bob> At 09:05 PM 26-10-00 +0200, Frank Nordberg wrote: >> Philip Rowe wrote: >>> Is the printed output better than anything the ABC community can >>> offer? >> >> Yes. Bob> That sounds like a challenge to me. In what way is the Bob> current output of abc programs lacking? To some extent that's an esthetic judgement. I have posted some of my recent results with converting abc to lilypond; if you want to compare them look at http://www.laymusic.org/music/dowland/unquiet/allparts.pdf, which is from abc2ps, and compare it with the first song in http://www.laymusic.org/music/dowland/book/dowland.pdf, which is from lilypond. If there's demand, I can put up a comparison that's easier to download. Someone who uses finale could put up a comparison between a finale pdf and the same music from abc2ps or some other abc program. Some of it doesn't involve value judgements at all: if you want to typeset some kinds of music you need features that aren't present in the ABC standard, and for some things aren't in any ABC program I know about at all. For the 16th century polyphony I set, I would like: Notes with longer than whole note values. C, G, and F clefs on several possible lines An ability to switch to and from a smaller font, for things like incipits and cues. Editorial accidentals, that either display differently, or don't display at all on the printout but are used by a player program. Other people who do other kinds of music need features like: more complicated repeat structures More ornamentation and articulation symbols. Notation for non-standard scales. Ability to enter percussion parts and have them display the way percussionists expect to see them. All of these things are possible in a program that was designed to be a full-featured music printing program, and are not currently possible in standard ABC. Another thing I'm enjoying in lilypond that has nothing to do with what the printout looks like is the ability to easily include it in a TeX file (along with text and graphics) and have TeX take care of the page breaks for me. We would have something like this with abc2mtex, if that would catch up with the current _de facto_ standard. -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org ) (Note the email and homepage address changes; please update your address book, bookmarks, and links.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
At 09:05 PM 26-10-00 +0200, Frank Nordberg wrote: >Philip Rowe wrote: >> Is the printed output better than anything the ABC community can >> offer? > >Yes. That sounds like a challenge to me. In what way is the current output of abc programs lacking? Bob To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
John Atchley wrote: [SMTP:[EMAIL PROTECTED]] wrote: > But plain ascii text from 30 years > ago is readable just about anywhere, and will be readable a century > from now. Provided it's on an accessible physical medium. 30 years ago ... Now, you'd be hard pressed to find hardware to read your paper or mylar tapes and ibm cards outside of a museum and even equipment that can handle nine-track tapes is becoming rare outside of universities and government facilities. Finally, nothing stored on magnetic media is likely to be reliably readable a century from now even if you can find compatible hardware. ... Yup. This is a growing lament from historians. Much of the world's history is now in forms that will shortly be difficult or impossible to read. That which is readable will require very expensive equipment. I have a collection of backup tapes from various projects that I've worked on over a couple of decades; none of them is readable on any equipment that I have available. In fact, what seems to be happening is that most of the world's usable information is going permanently online. Attempts to estimate the size of the online disk drives are concluding that there are more bits online now than the information content of all the world's physical libraries and archives. The most reliable way to back up data is to copy it to another machine's disk. That way you have a good chance of being able to read the bits, and your remaining problem is whether you can decode the file format. I have a sizeable collection of ABC tumes online. They are backed up on three other machines. (Can you find them? ;-) If I get squished by a truck on the way home tonight, any one of you could download any or all of my tunes and they wouldn't be lost. This is, on the average, a lot more reliable than any tape or paper copy in my home, where one fire would destroy them for all eternity. One thing that is obvious from my work on indexing the online ABC is that most of the ABC tunes are backed up at one or more other sites. I've been doing the family-history thing and what I finally settled on as the most probable format for longevity is HTML. This is likely true. To illustrate it, I've taken the step of typing this message in HTML. I'd predict that if this message is still around in a century, it'll still be readable by anyone, no matter what computers have evolved into by then. And I'd also guess that few if any of the readers here are put off by the simple markup that I've used. One growing problem with HTML, though, is the large body of "junk HTML" being spewed out by a lot of software. HTML was designed to be simple and unobtrusive, with the idea that people could type and read it. Now we see lots of mailing lists installing filters that discard all HTML, because so much of it is unreadable garbage. As we move to the more capable XML, this will probably get worse. This will be true despite the fact that markup like the abovetag are simple and obvious (though syntactically incorrect ;-). Still, if you type it yourself, HTML markup is probably a very good way to get simple formatting without making the text unreadable. The main problem here is that it's tricky to embed ABC inside an HTML document without garbling the musical information. (I note that this list does still pass HTML. This message would not be readable on a lot of other mailing lists, though, since their filters would discard the whole thing. ;-) Reply-to: mailto:[EMAIL PROTECTED]:>John Chambers To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Egregious example of line wrapping
Actually, abc4mac _is_ AppleScriptable, although it doesn't support the full BarFly superset of abc. There are a couple of 'droplets' in the abc4mac distribution for building pdfs by invoking abc4mac and then GhostView, for example. wil Phil Taylor wrote: > Sure, the idea of BarFly popping up unexpectedly and opening windows > in front of an unsuspecting user is daft. But, there's no reason not > to do this while running in the background. You don't normally use the > program in the background except to play through a whole file of tunes > while you use the machine for something else, but there's nothing that > BarFly does (apart from interacting with the user) which requires it > to open windows or run in the foreground. > > It would also be possible to get around the problem of transmitting > high-level events from a different platform by means of a "watch folder". > I have an encryption program which does this; the user designates a > directory as his watch folder, and the program checks this for new > files every few seconds, and automatically encrypts anything it finds > there. > > It would be relatively easy to write a faceless background version of > BarFly which would turn any abc files dropped into the watch folder > into pictures or MIDI files without any user intervention. That would > work locally, or (given the necessary file permissions) over the net. > > Phil Taylor > > To subscribe/unsubscribe, point your browser to: >http://www.tullochgorm.com/lists.html -- Wil Macaulay email: [EMAIL PROTECTED] voice: +1-(905)-886-7818 xt2253FAX: +1-(905)-886-7824 Syndesis Ltd. 28 Fulton Way Richmond Hill, Ont Canada L4B 1J5 "... pay no attention to the man behind the curtain ..." To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Good quote
Laura Conrad wrote: | In free software, the fact that something is possible doesn't | guarantee that it will happen; it's the fact that it's possible and a | lot of the people who could do it want it. Hey, that's a nice, succinct statement. Mind if we quote you? To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
Frank Nordberg wrote: | [EMAIL PROTECTED] wrote: | > Formatting isn't important, and if we lose it, we don't lose much. | > The important thing is the information content. | | Yes, but in music notation it's usually impossible to draw a clear line | between information content and formatting. Your right there. This was why I mentioned the proposed "^text" sort of extension. But an even better example is the fact that, in standard staff notation, the note heads mostly all look the same. It's their position that tells you their relative pitch and start time. (Though curiously, the stop time is indicated differently.) This is a clear case of formatting information that carries musical information. This is also one of the several ways that ABC differs significantly from staff notation, since ABC uses letters rather than physical position to indicate a note's pitch (and a number rather than a flag to indicate duration). We wouldn't be able to eliminate all formatting information, for this sort of reason. And some simple formatting information is just too useful to discard. Thus, staff ends are useful, even if you don't play them. For that matter, you don't play bar lines, either; they are primarily to make the music more readable. Even these could be eliminated without loss of much musical information content. But the basic principle is still worth noting: In the long run, it's the musical information that is of most value. Formatting information is of secondary importance, and will be routinely ignored or changed by many users anyway. The most important topic is how we represent the musical information. A bit of formatting is ok, but we shouldn't pay it much attention. This is also similar to the text world. I've seen a number of remarks from writers to the effect that they hate word processors, and prefer simple text editors. Why? Well, one journalist I heard recently just pointed out that his "product" is words. Formatting is done by the folks in the print shop, and he is quite happy to let them handle that part of the job. Not that he won't discuss it with them or criticise them at times. But his emphasis is on writing, and all he wants is a simple way to produce a string of words that others can read. Word processors are complex and distracting, and produce text that can only be read by a few people with the same sort of software. Only a few experts can do much with the text. Plain text can be sent to anyone, and they can format it however they wish to make it look nice on whatever sort of surface they are reading it from. ABC's niche, if it has one in the long term, should be similar. We should let the folks building the fancy music processing software worry about things such as formatting. What we should concentrate on is the musical information, in a form that is as easy to type and read as we can make it. One goal should be to make it easy for other music software to read ABC, and to generate it. Then ABC will function as a medium of exchange between programs that can't read each others' file formats. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Egregious example of line wrapping
Sure, the idea of BarFly popping up unexpectedly and opening windows in front of an unsuspecting user is daft. But, there's no reason not to do this while running in the background. You don't normally use the program in the background except to play through a whole file of tunes while you use the machine for something else, but there's nothing that BarFly does (apart from interacting with the user) which requires it to open windows or run in the foreground. It would also be possible to get around the problem of transmitting high-level events from a different platform by means of a "watch folder". I have an encryption program which does this; the user designates a directory as his watch folder, and the program checks this for new files every few seconds, and automatically encrypts anything it finds there. It would be relatively easy to write a faceless background version of BarFly which would turn any abc files dropped into the watch folder into pictures or MIDI files without any user intervention. That would work locally, or (given the necessary file permissions) over the net. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Newbie questions
Dear Jorge, I am using abcm2ps 1.6.1 and abctab2ps 1.0.0. abcm2ps now has the ability to print up to 3 voices per line and it works very well on my system (Atari TOS, I had to compile it on my own, but no changes had to be made). If there are bugs, Jef Moine is very fast on replying and trying to fix them (nearly every week there is an update). abctab2ps bases an abc2ps 1.3.3 and can only handle 1 voice per line, but includes lute and guitar tabulature. It is still on the way, but it is working very confidental. On the homepage of abctab2ps there is a real good online-userguide: http://www.emsland-aktuell.com/lautengesellschaft/cdmm/userguide/userguide.html A example of an orchestral partitur written by abc is on Chris Walshaws' homepage of abc: http://www.gre.ac.uk/~c.walshaw/abc/ Sincerely, Markus On Fri, 27 Oct 2000 00:14:31 -0500, John Henckel wrote: JH> Jorge. JH> JH> I am using ABC to publish a hymnal and I have found it to be very JH> convenient and adequate. JH> JH> I actually started by using LilyPond. However, I gave up on it because it JH> was very difficult to customize, the source code is horrific. And LilyPond JH> runs like a pig on Windows (very very slow and requires too much memory and JH> disk space). JH> JH> For almost a year (maybe longer) there has been software that supports "V:" JH> for multiple voices in ABC. Why are the "keepers of the standard" so JH> sluggish about adopting V: ? It baffles me. That is the ONE bad thing JH> about ABC. JH> JH> You can try an online demo of abcm2ps (with some modifications (and bugs) JH> by me) at JH> JH> http://www.formulus.com/hymns/abc2gif.html JH> JH> Yes there is bass clef notation which automatically transposes two octaves JH> down, see http://www.formulus.com/hymns/abcm2ps.txt JH> JH> You can create orchestral scores with a separate voice for each instrument JH> and you can give names to the voices (like "violins" and "timpani") and you JH> can do ANY kind of tuplet and slurs and ties (see JH> http://www.lesession.demon.co.uk/abc/abc_notation.htm the "advanced bits") JH> JH> I am not sure about percussion music, with the funny note heads. I think JH> abcm2ps can do that, but I haven't tried it. JH> JH> I must warn you about abcm2ps, though. I like it because I can make it do JH> what I want by editing the source code (ANSI C) and recompiling it. If you JH> are not a programmer, and you have very exact output requirements, then JH> abcm2ps will probably be very frustrating. JH> JH> I hope my advice is helpful. JH> To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABC Newbie questions
Jorge Meletti a écrit : > I'm a Brazilian composer and I've studied ABC a couple of hours, but my thinking is >still based on the conventional music notation. > > Do ABC work, in practical terms, with more complex music, like "Bossa Nova", with a >lot of sincopations, tuplets and ties ? Do ABC work with orchestral scores ? I'm >asking it because the tunes I found in ABC are quite simple melodies, based in just >one voice. The softwares I'm using is Muse and ABC2win. > The release of abcm2ps comes with the transcription of Stan Getz's solo on Desafinado. You can also check John Chamber's Tune Finder: http://trillian.mit.edu/~jc/music/abc/FindTune.html There is not much bossas but the melody of Desafinado can be retrieved. You can have a look to a gif of the score and to the abc file as well. Maybe you will be able to assess the difficulty to write abc files for bossas. René -- QUINIOU Rene mailto:[EMAIL PROTECTED] INRIA / IRISA Phone : +33 2 99 84 73 19 Campus Universitaire de Beaulieu Fax : +33 2 99 84 71 71 35042 RENNES CEDEX - FRANCEhttp://www.irisa.fr/prive/quiniou/ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
On Thu, 26 Oct 2000 [EMAIL PROTECTED] wrote: > ABC has a real role as a minimal, bare-bones, just-the-music sort of > notation. Like plain ascii text, it will likely be around and useful > long after all the current proprietary music formats are unreadable. > But conversions to ABC will then be very useful. Laura made similar comments. I definitely agree that convertion programs *from* other formats to ABC are at least useful, if not essential. I'd be more than happy to write code that converts from Finale or else to abc. Sooner or later - sooner is more likely - I'll get more free time and I'll give it a try. Later, Guido =8-) -- Dr. Guido Gonzato - Linux System Administrator My public PGP key is at http://ibogeo.df.unibo.it/guido/PGP.asc "It is a good morning exercise for a research scientist to discard a pet hypothesis every day before breakfast. It keeps him young." -- Konrad Lorenz To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] M: none in jabcm2ps
On Thu, 26 Oct 2000, John Atchley wrote: > I can offer it as an option though. Next time I upload the code > &&FreeMetStyle 4 will cause it to output nothing. It'll be up to the user > to use that option intelligently, though ;-) thanks for your clarifications and for the new code, John. Meterless music is often found in chorals; the music starts and ends with no meter at all. This is a beautiful "Pater Noster" in Russian that shows the case: % otce-nash.abc % % Typeset this file with the following command: % abcm2ps otce-nash.abc -O otce-nash.ps % % This edition is formally not complete, as it needs more % decorations currently not supported by abcm2ps. % %%topspace 1.5cm %%titlefont Helvetica-Bold 18 %%subtitlefont Helvetica-Bold 14 %%composerfont Helvetica 12 %%composerspace 0.7cm %%musicspace 1.5cm % X: 1 T: Otce Nash T: (Pater Noster) C: Nikolaj Kedrov Sr. M: none Z: Edited by Guido Gonzato, 11 October 2000 L: 1/4 Q: "Adagio, " 1/4=40 % broken? in abcm2ps %%staves [ 1 2 3 4 ] V: 1 clef=treble name="Soprano" sname="S" V: 2 clef=treble name="Alto"sname="A" V: 3 clef=treble name="Tenor" sname="T" V: 4 clef=bass name="Bass"sname="B" K: C % V: 1 E2 E E4 | E E E E E E E E4| F F F F G2 G G G2 | w: ot- ce nash, ie scio ie ti na nie be sah, da sfia ti za i mia tva io V: 2 C2 C C4 | C C C C C C C C2 B,2 | B, B, B, B, D2 C C C2 | w: ot- ce nash, ie scio ie ti na nie be sah, * da sfia ti za i mia tva io V: 3 G2 G G4 | G G G G G G G G4 | G G G G G2 G G G2 | w: ot- ce nash, ie scio ie ti na nie be sah, da sfia ti za i mia tva io V: 4 c2 c c4 | c c c c c c c d4 | d d d d e2 e e e2 | w: ot- ce nash, ie scio ie ti na nie be sah, da sfia ti za i mia tva io % % V: 1 G G G G G2 F F E HF4 | F F2 F2 F2 E G D2 D2 | D D D E F2 | w: da pri i tiet zarst svi- et va- io da bu- diet vo lia tva-ia ia ka na nie be si V: 2 C C C C C2 C C C HC4 | C C2 C2 C2 C C B,2 B,2 | B B B C C2 | w: da pri i tiet zarst svi- et va- io da bu- diet vo lia tva-ia ia ka na nie be si V: 3 G G c _B B2 A A G HA4 | A A2 A2 A2 G G G2 G2 | G G G G A2 | w: da pri i tiet zarst svi- et va- io da bu- diet vo lia tva-ia ia ka na nie be si V: 4 e e e e f2 f f f Hf4 | f f2 e2 d2 e e g2 g2 | g g g e d2 | w: da pri i tiet zarst svi- et va- io da bu- diet vo lia tva-ia ia ka na nie be si % % V: 1 E D2 C2 D2 | E2 E E E E F2 F F2 F F G2 | G G G G G2 F2 F2| w: i na zsem li. Chliep nash na su shi dash nan nie i a sta vi nam dal- ghi na scia ia V: 2 C B,2 C2 B,2 | C2 C C C C C2 B, B,2 B, B, D2 | C C C C C2 C2 C2| w: i na zsem li. Chliep nash na su shi dash nan nie i a sta vi nam dal- ghi na scia is V: 3 G G2 A2 G2 | G2 G G G G G2 G G2 G G G2 | G G c _B B2 A2 A2 | w: i na zsem li. Chliep nash na su shi dash nan nie i a sta vi nam dal- ghi na scia ia V: 4 e g2 a2 g2 | c2 c c c c d2 d d2 d d e2 | e e e e f2 (f e) d2 | w: i na zsem li. Chliep nash na su shi dash nan nie i a sta vi nam dal ghi na scia- * ia % % V: 1 F E G D2 D E F2 | F F F (E2 C) (D2 C2) D | E E E | w: ka ie im ghi a sta vlia em dal ji da- am na - scim i nie ve V: 2 C C C B,2 B, C C2 | C C C (C2 A,) (B,2 A,2) B,2 | C C C | w: ka je im ghi a sta vlia em dal ji da- am na - scim i nie ve V: 3 G G G G2 G G A2 | A A A G3 (G E) G| G G G | w: ka je im ghi a sta vlia em dal ji dam na- * scim i nie ve V: 4 d e e g2 g e d2 |d d d e3 g2 g2 | c c c | w: ka je im ghi a sta vlia em dal ji dam na- scim i nie ve % % V: 1 (E2 G2) c c B A G2 F2 E2 | D D G2 D G | C D E4 E2 E4|] w: di- * nas vo is ku sce ni e no iz ba vi nas at lu ka va ga. V: 2 E4 E E E F (G C) (C B,) C | C C C2 C C | C C (C2 A,2) B,2 C4 |] w: di nas vo is ku sce- * ni- * e no iz ba vi nas at lu ka * va ga. V: 3 c4 c c c c (c G) G2 G2 | A A G2 A G2 | A A (G2 E2) G2 G4 |] w: di nas vo is ku sce- * ni- e no iz ba vi nas at lu ka- * va ga. V: 4 (c'2 b2) a a g f e2 d2 c2 | f f e2 f e2 | f f c4 g2 c4|] w: di- * nas vo is ku sce ni e no iz ba vi nas at lu ka va ga. % % End of file otce-nash.abc -- Dr. Guido Gonzato - Linux System Administrator My public PGP key is at http://ibogeo.df.unibo.it/guido/PGP.asc "It is a good morning exercise for a research scientist to discard a pet hypothesis every day before breakfast. It keeps him young." -- Konrad Lorenz To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
On Thu, 26 Oct 2000, Gianni Cunich wrote: > The trick is having the drivers, and let Windows save to file the printer > output. You end up with a file called *.prn, that you can rename (*.ps or > *.eps, according to what you selected in the printer properties), and then > easily handle with Gosthscript. I was aware of that, but I'm reluctant to use the Windows PostScript drivers; in my experience, they tend to produce very inefficient (read: huge) files. To be fair, I must say that when I once tried the HP LaserJet I got good results. In the Unix world, each application writes PostScript on its own, typically with excellent results. A Windows program that follows this approach is Melody Assistant. > If you wish to spend half an hour to configure it, try Free PDF: saves time > if what you actually look for are PDF files. Have a look at the web page > http://www.webxd.com/zipguy/freepdf.htm, and after that have a look at the I didn't know this - that's very good! Thank you for the tip! Ciao, Guido =8-) -- Dr. Guido Gonzato - Linux System Administrator My public PGP key is at http://ibogeo.df.unibo.it/guido/PGP.asc "It is a good morning exercise for a research scientist to discard a pet hypothesis every day before breakfast. It keeps him young." -- Konrad Lorenz To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
