Re: [abcusers] mailing list abusers
- Original Message - From: "Frank Nordberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 03, 2001 11:39 AM Subject: Re: [abcusers] mailing list abusers > No, Jack, you would not be correct in assuming so. Or at least that is > not an issue in this particular sad case. > I know all the combattants well enough to assure you that they are all > earnest in their interest in and support of the ABC standard. > > But there are a few people here who definitely lack the social skills > needed to participate in a civil, constructive discussion. And I'm > talking about more than one person here. > Yes, Gianni *was* way out of line, but it's not as if he was very > lonesome there... > > Anyway, the harm is done now, and I don't think it's possible to repair > the damage. We just have to try to put it behind us and move on. I've been off line for a few days while on holidays, and I am just reading back to quite a few messages. Nice on your part admitting I was'nt very lomesone here! No, seriously, I wouldn't really be upsetted by people choosing to filter my messages - at least those that did seem inclined to are among those people whose message I usually in turn avoid reading ;-)! Also, I don't feel guilty for having being offensive, since I did it in replying to people that had been gratuitely offensive in their postings. Along the years I've usually avoided both what you call "attack anybody personally" and "answering an insult with an insult", yet you can't keep on smiling at those who are shooting at you your whole life... Anyway, I suppose as far as this list is concerned, is the first of your tips that should be kept in mind. Actually - and that really upsetted me -, I've been challenged on a number of grounds I'de never entered, of for statements I never made an ugly number of times. In fact I've tried to make one single point along the years, and it was a very simple one: an update of the standard was needed, in first place, for the sake of the future of the notation. I've never pressed for the inclusion of a particul feature, nor for any particular syntachtical choice... as far as new features were made part of the standard, I would have been satisfied. The obvious reason of interest toward the abc notation was for me - and for a large majority of the users who, like me, aren't developers - that it could be used an easy to handle human readable exchange format. Yet, as far as the standard is concerned, we are talking about potentialities, since really one line of music on one staff in the key of G and an almost total lack of decorations isn't really much useful. And I dare say a number of the developers in this list suffered from these limitations as well, since in fact the number of native softwares/clones that have been written, to start with abc2ps, have been adding more and more non standard extensions to offer new features. It's a pity none of them has been made part of the standard, and a number have in fact been implemented in different ways in the single packages, creating even more incompatibilities that those that had naturally arisen from the different interpretation of the ambiguities and inconcistensies of the standard itself. The reason that made an update of the standard impossible (even if there a draft that nobody seems to care about) is clear: the incapacity of the developers in this mailing list to cooperate toward a common goal and to agree virtually about anything. Now, it's plain to see that the developers in this list are not just a minority of the users, but a minority of the abc related software developers as well - as in fact the excellent list of software packages you mantain on your site easily demonstrates! Of course nobody with an ounce of common sense might discususs the right of the afore mentioned developers to choose the features they wish to implement in their packages, yet the update of the standard is a matter that should involve the whole community of the users, and in making such an update impossible those developers have damaged those who might have chosen to use other software packages - for instance some of the excellent notation shareware that "speak abc", which are in fact the standard I judge the abc native softwares against, and that has brough me to state that, with a couple of exceptions, they aren't worth in comparison the effort needed to download them (yes, I know this hurted a few people, yet...). Anyway, arguing over and over about matters of evidence with people who pretend they can't see them isn't a likely pastime for anybody. An exchange format, to be useful, must be flexible (i.e. offer the chance to code a wide number of informations), and at the same time must be, as far as possible, ambiguities free (i.e. you must be sure the informations you pack when coding aren't going to be misinterpreted). Without an update of the standard, the abc notation as an exchange format is useless for any serious purpose, an
Re: [abcusers] requesting goodies from developers
- Original Message - From: "Jack Campin" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 31, 2001 3:02 PM Subject: Re: [abcusers] requesting goodies from developers > Gianni Cunich wrote: > > [Gianni, please don't quote an entire message when replying; you quoted > a heck of a lot in your reply and then your software appended the whole > of my text as well.] Good God! After Laurie's, this is the second sensible reply I obtain in ages on this mailing list! Have you all got drunken? No, seriously, I'll try not to quote both the text of my email and the replaies I got in the future... yet, most of the times this is the only way I have to show I made some points, and who actually replied hasn't take the care to even superficially read what I had written. Sorry to stress it again, but this is a common problem about this mailing list (and worst, by far, than with any other I am/have been a subscriber so far). > >> What features do you need and why? Does anybody else need them? > > I'm not concerned about asking new or particular features. I've been > > asking for an update of the standard, introducing what has been agreed > > about in the drafts, plus a solutions to the main features the developers > > on this mailing least have not been able to reach any agreement at all > > so far - i.e. multistave and multivoice scores -. Do you think I'm alone > > in this requests? > > No, but that amounts to asking for a lot more new features to be added > to *all* the ABC applications out there; a different set for each one > and with the difficulty of implementation of an extension being very > variable depending on which platform you're adding it to. (John Chambers' > extended-variant-repeat construct is easy to add to a purely graphical > implementation and quite hard for a player program; my suggestion for > percussion staves is easy to add to a pure player program and a lot > harder for a staff-notation generator if the assumption that staves > have five lines was wired in too deep). Sorry to be quoting the whole lot, but here we are again: I am simply asking, to start with, to be able to notate a second treble voice on the melody line, and a bass line on a second staff. I suppose I could be able to do it with Barfly if I was a mac user, and I know I can do it with abcm2ps under both Windows and Linux. More than this, I think if I had a couple of months to devote to this task, I could probably learn enoguh Java to able to write something in the line of abc2mtex to process a multivoice/multistave score to create a MusixTex compatible .tex file. One step at a time, please: the lack of agreement among the abc native software developers subscribing to this list (who are, as you know very well, a minority among the the developers of the available abcrelated software), actually stopped any update of the standard, even - at least according to what Chris Walshaw (RIP) states in the 1.7.3 and 1.7.6 drafts - for the matters an agreement was (apparently?) reached. Actually, as some twenty years ago (more or less) I have been tried a a COCOL developer, although I have had no chance to get any firther than that, I think I could (if my four month daughters aloows it) start an abc related cobol project... would I be in line with the so-called open-source philosophy? > > In other words, what I am concerned with is a developement of the abc > > notation as an exchange format [snip] > With the multi-voice stuff, the differences are resolvable with fairly > simple editing; the main problem is the different pitch conventions > for non-treble staves between BarFly and the abc2ps variants, and BarFly > has transposition utilities to help with that (I presume something > analogous is possible on platforms that support abc2ps). I've used > Laura's ABC files without much trouble and she's done the same with > mine, though neither of us has made any concessions to the other's > usual platform. I've not quoted entirely what I wrote this time, you see! Yet: I am not concerned about what you do with somebody elese's files, nor about what somebody else does with yours. I actually wish to be sure that the files with an .abc extension I post or upload on the web are correctly interpreted by any abc standard compliant software available... > One of ABC's main strengths is that the user can easily tinker with it > (impossible for graphic file formats); need a version with different > note density, different chording or an unusual transposition? - just > make it yourself. It's a format for musicians, not for the sort of > passive listeners who are best served by MIDI files. Learning to play > a piece always takes a certain amount of time, so it's no
Re: [abcusers] dynamics (was)
- Original Message - From: "Richard Robinson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 30, 2001 6:33 PM Subject: Re: [abcusers] dynamics (was) > But "silly" is not the main point. I lost my temper, yes. For the second > time since this list was started. I am seeing Brian, and Gianni, making > remarks which I consider to be really offensive, about an undefined number > of other people on this list. And, to borrow Laurie's phrase, it gets my > goat. To quote Alessandro Manzoni, our "national novelist", which was in turn quoting an old popular Italian saying: "chi è è in difetto è in sospetto"! A complimentary translation for non Italian native speakers: "who knows to be guilty of something, reacts when when anybody talks about it". If, as a number of other subscribers to this list, you'll find hard to grasp the meaning of my posting(s), this is an idot proof English native speaker broad summary: "The one you blamed for being offensive were, actually, replying to messages that where offending them. Blame it on the other members of your gang, not on us!" In other words: if you think we are offensive just beacuse we don't change our minds when you, the self appointed Demigods of the abc, stated we should have... well,you can go to Hell (and possibly remain there!). And if you think that we - or to say better, "I" - should be "NICE" when someone keeps offending us - well: SEE ABOVE...AND, PLEASE, FOLLOW MY SUGGESTION... Otherwise, you might discover that the word "offensive" might show a number of hidden meanings you have never even dreamed about in you worst nightmares... yes, I'm TIRED TO BE INSULTED BY *** LIKE YOU... and the next time I will post to this mailing list I will feel entitled to avoid using asterisks! WOWW! Given this: I'm not Bryan (Creer) - I'm not necessarily sharing Bryan's opinions - I actually think he's wasting his time to try to discuss with *** like you! And I actually have taken the decision to replay, stroke for stoke, to the kind of messages you, and the likes, are posting. >ABC is not perfect. A number of people have tried, and put work into, a >number of approaches to improving things. A number of improvements have >been made, even if not the ones that some people hoped for. To abuse >people for doing the work they have done seems to me, as I said before, >unfair, counterproductive, and just plain wrong, even if it has not handed >everybody everything they would like. Particularly, the way that every >time a new poster appears here, they are informed that this is a no-good >bunch of people, an arrogant self-selected clique who are bound not to >listen to them ... it does no good. It makes agreement harder to reach >instead of easier, it drives people away instead of including them, and I >object to it. And I intend to continue doing so, from time to time ... I don't think it's true, either ;) Actuall, YOU ARE in fact "an arrogant self-selected clique who are bound not to listen to them". And so what? I won't let your offensive emails drive me away... Do you actually wish to ask Toby making this a censored list? No regards Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
- Original Message - From: "James Allwright" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 31, 2001 12:32 PM Subject: Re: [abcusers] dynamics (was) James allwright wrote: > I don't think you'll ever get the standards committee to speak as one> person with a unified voice. My opinion is similar to Phil's. I took> the approach of identifying all the new features in the new draft> standard and seeing which ones were universally approved and which> ones were not. This seemed like a good way to make progress, and I> got the impression that disagreement was restricted to relatively> minor features and obscure options of major features. However, the> thread petered out without any definite conclusions; people were> either not interested in this approach or distracted by other> projects.> > It is still possible for someone who cares about an abc standard> to help the process along; get hold of every abc program you can,> go through them carefully and then document the compatibilities> and incompatibilities carefully on the web. If you do this> carefully and comprehensively enough it be a valuable resource to> guide any new abc developer on interpreting the more subtle aspects > of abc.> > James Allwright Who are you trying to fool, James? The members of a committe that's appointed to express a definitive opinion about any matter, if not able to reach a commonly shared resolution, should resign and ask someone else to enter the buttons room! If the members of the actual, farcical self appointed committee, had had the balls to, once they had proved unable to agree about anythingh (as the developers who monopolize the debate on this mailing list had done in turn earlier), they shoul have asked CHRIS WALSHAW (R.I.P.) to select, in first person, a new committee. The incompatibilities among abc related softwares would be easy enough to document... the problem is to state which is the correct way to notate the new features such softwars have implemented in the standard. As far as I care, I wouldn't object to: this (as abc2ps does)/this (as abcm2ps does)/this (as jccabc2ps does), this... name your favourite abc package! But then, if nobody actually is entitled to update the standard, what could we do with such a list? You see, James, what you are suggesting is as useful as abc2midi... No regards Gianni
Re: [abcusers] Announing a proposal (I.E WAS The day...)
- Original Message - From: "Forgeot Eric" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, November 01, 2001 4:59 PM Subject: [abcusers] RE : The day the music died! & voting for abc standard > Yes, I think it's quite boring to read all those endless quarrels > about the standardization of a musical format I found already > rather perfect : if it becomes too complicated, then there is not > point using it instead of midi... Seems we live in a different world! I know you like MIDI, but what about NIFF instead of it ? No, seriously...did you drink too much scandinavian moonshine beverage when posting this mail or what? > Instead of arguing on loose points, abcusers could debate on > specific points, and "vote" for the resolution of them. Actually, this is exactly what a number of reprobates have been asking for ages on this list, of course implying that the results of the ballot had to be incorporated in the standard... we do have experienced a couple of problems so far: FIRST: for years the responsability of an update of the standard was in CHRIS WALSHAW's hands. Finally C. W. (R.I.P), who relying on the debate going on in this mailing list hasn't able to produce than drafts that the developers that virtually monopolize this list were anyway claiming not to be available to implement in their softwares, gave up . Then a self appointed committee declared it was in charge of updating the standard, and a number of recent email show that its memebers can't even actually agree about the basic question if they are not up to the task... Maybe we should make clear who is entitled to take any decision before we discuss about how decisions should be taken! SECOND: I agree abc users should debate and vote, yet a large percentage of them is actually not subscribing to this list, because the minority of abc native software developers that has a virtual monopoly on it (with the complicity of some fools LIKE YOU [yes, I'm being deliberatly offensive here... and you know why!]) have discouraged them from entering an inane debate in which their points of view are - as a rule - deliberately ignored or distorted, and if they insist in asking to discuss them with at least a bit of care and common sense got abused (or get silly replaies by someone like you... actually, I dare say I'm not being offensive, I'm just judging you by the total lack of sense of a number of you postings!). Given this, I think we really should reflect - and an awful lot - about the current state of affairs. I fear it's to late to involve a large majority of the abc users in the debate of this minority-monopolized mailing list. Yet, I think some concrete alternative solution might/could be found. I'll post my own proposal about the way the problem could be solved. I give for granted that I'll be rather ignored and/or flamed by those that are going to be hurted by the statements I'll made (Eric in first place... he seems unable to read through the messages he replaies to, but he's not alone in this mailing list), but I couldn't care less... What it's under everybody's eyes is that the abc notation potentialities are far from being fully exploited, and until a comprehensive update to the standard will be available they never won't. As I still hope it's not too late... Gianni /lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
- Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 28, 2001 5:19 PM Subject: Re: [abcusers] dynamics (was) > On Sat, 27 Oct 2001 [EMAIL PROTECTED] wrote: > > > There doesn't seem to be much point in being involved in an > > open-source project coded in a language you don't understand. > > Sorry, but that's absurd. Coding is not the only way to contribute to a > software project, and I would argue that it is not even the most important > way. Probably 75% of the people on my team at work have never even seen > our product's source code. And there are plenty of SourceForge members > who can't program in *any* language. > > I think an open-source project *could* be an appropriate venue for working > on the abc standard, as long as it's open to input from anyone. I don't > understand why you think a project contributor would have to know C or any > other programming language in order to provide input on the standard. > Coding would follow the standard, not the other way around. > > I'm not saying this is what libabc should be, or even could be, but I > don't understand why you are singling it out for criticism over any other > implementation. It seems like a huge leap to say that there is a danger > of it becoming synonymous with the future of abc, let alone in some way > that would exclude your input. > > All that aside, based on the present standardization efforts (or lack > thereof), abc *has* no forseeable future. I don't think that should stop > someone from writing a useful tool. And since it hasn't stopped *you*, I > assume you would agree. > > A newcomer to the "pretended" abcusers mailing list? Really, you nearly made me laugh to death! The rule in this quarters is that the developers are the only ones entitled to decide about the future of the standard, since they are the one that write the code. Users that are not developers are usually ignored, or eventually abused if they insist to state their different points of view (actually, even some of the developers are actually on such a fringe...). I suppose this is the reason why, after four years a number of users - and even a few developers (those on the fringe like Bryan) - have been stressing the need to update the abc standard, no agreement about any update was reached, and then now we can't but regret any update would be useless... in your words the abc notation has no forseeable future anymore. By the way, I've been told many times that the main abc native softwares, which are mainly quite poor clones of a rather poor first one, are a product of the so called free-source or open-source philosophy, and that the total incapacity of their developers to join their efforts working together toward a common goal is as well reflecting that philosophy... any comment? Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (was)
- Original Message - From: "Eric Mrozek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 28, 2001 3:41 AM Subject: Re: [abcusers] dynamics (was) > > [EMAIL PROTECTED] wrote: > > [ > > >>time for a new approach, preferably one involving as much of the abc > >>community as possible not just a self chosen clique > > ] > > > >Do you have a positive suggestion ? > > > > Certainly, but before I do, could I have your assurance that you will > > give my suggestions proper consideration, rather than opposing them on > > principle just because they come from me, and that you will restrict > > your reponses to what I actually say rather than your own wild > > speculations about things you think I might say (as you have done twice > > in this thread alone)? > > > > Bryan Creer > > > > Bryan, this is an open list - you won't get anyone to agree to your > personal terms. You'd be best off to just post your thoughts and don't > mind the critique, whether it's meant personally or not. > > Eric Actually (even if my English might be a bit rusty), as far as I've been able to understand the meaning of what Bryan wrote, he wasn't asking for somebody to agree about any kind of personal terms. He was rather, I guess, talking about prejudices, which are a rather different thing than what you call critique. Even if you aren't able to grasp the difference, it's quite a concrete one! Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] RE :There is a dumb man... & downloading software
*** REPLY SEPARATOR *** On 21/07/01 at 10.45 Frank Nordberg wrote: >Hi everybody, > >I see you've had a lot of fun while I've been away on vacation ;-) > >Forgeot Eric wrote (in reply to Gianni): >> >> I own one book from O'neill (1001 gems), and I don't think the abc >> transcriptions have lost anything from the original notation. > >Since I'm responsible for the ABC version of O'Neill 1001, I think I >have to answer this: >There is one rather important detail that might miss from the >transcriptions (depending on what ABC software you use): the mordents. >I used the letter M for mordents, believing that was a part of the ABC >standard. Gianni has pointed out to me offlist that it isn't. So some >applications will not display the mordents at all. > > >Frank Nordberg Hi Frank Well, I avoided to replay to Eric, but... as you actually felt involved somehow... ... what we've been actually discussing offlist was in fact your transcription of the O'Neill 1001, or - to call it with its original title - The Dance Music of Ireland (1907). What I did mention on the posting Eric was replaying were the abc transcriptions of the original O'Neill's' larger book, The Music of Ireland (1903), listing 1850 titles - including 625 songs/airs, 75 O'Carolan's compositions, and 55 marches and miscellaneous tunes -, that has been made available through the collective effort of a number of transcribers. Different abc transcriptions, then, and (what really matters) different source publications. The Dance Music of Ireland, that O'Neill put in print by popular demand, isn't just a reprint of The Music of Ireland ridden of the non-dance stuff. Some of the dance tunes, which in fact were duplicated in the latter book, were omitted in the former, while some tunes that O'Neill had transcribed after sending it to print were added, and some editing was made along the way. I carefully avoided to mention The Dance Music of Ireland because I know there are different editions available. I choose to mention, to make my point, The Music of Ireland, that had been the first O'Neill's major printed effort, since it is currently available in the 1979 RockChapel Press facsimile edition. The transcriptions in the book are really simple to reproduce - one line of music, G clef, limited extension -, yet O'Neill made an intensive use use of turns, mordents, fermatas and assorted expression marks an symbol, and he did it especially in the song airs and the non-dance stuff that got dropped from the original book. In fact the statement I made about the abc transcriptions was that, in a number of cases, the transcriptions had to be either non faithful to the source or non abc standard compliant (an in some cases in fact they're both). A different statement, and a rather more articulated one for the matter, that Eric intended. And, as shown by the fact that nobody else actually has been so naive to argue about that issue, I wasn't expressing an opinion. I was jut talking about a matter of fact. Anybody who will take the care to have look at the real source book will be able to verify it! ;-). It's my turn to go on holidays. Gianni There is a dumb man that tells to a deaf man: "Hey, there's a blind man looking at you!". Popular Italian joke. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] herbal remedy
*** REPLY SEPARATOR *** On 15/07/01 at 13.10 [EMAIL PROTECTED] wrote: >Richard Robinson wrote: >>On Sat, 14 Jul 2001, Gianni Cunich wrote: >> >>> The key word is COMOPETENCE... >> >>Uh huh. >> > >It's what happens when you BOTH take viagra... > >Phil Taylor Hey, Phil! The typing error/viagra connection is a new one to me. You see, I've never need to use viagra, and I seem either able yo mistype "the natural way" too! ;-) Also, since you immediately spotted such an intriguing connection, I must assume you actually know what you are talking about relying on a first hand experience. And if this is the case, let me tell I sincerely sympathize with you for your...uh huu.. problem...:-( Have you tried any alternative herbal remedy? They are not know to produce computer related side effects, and are therefore warmly suggested to software developers! :-)) Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] There is a dumb man...(used to be linux only ?)
*** REPLY SEPARATOR *** On 15/07/01 at 2.29 Richard Robinson wrote: >On Sat, 14 Jul 2001, Gianni Cunich wrote: > >> The key word is COMOPETENCE... > >Uh huh. > > > >> In other words, this is the attitude that will bring to the abc notation >> demise.Take your own responsabilities about it, please! > >So, to cut a long story short, you don't like ABC ? Beyobd my obviuos typing error, I could say I "appreciate" the abc notation... what I don't like is what some of those who have taken over this mailing list are doing with it. >So far as I'm concerned, ABC has enabled me to publish a couple of >thousand tunes, far more easily than any other software I've found. And >it'll survive, in use at this site, until I find something that works >better. Please stop ranting - if you want to invent something better, by >all means go ahead... There is no reason to invent anything...as far ax text music exchange formats are concerned, I could already choose among plenty of far better alternatives. but I don't forget that there are some 20.000 tunes available on the web in abc format. Of course, given the limitations that the standard impose, a quantity of Western traditional music has been made available through it on the web in a way which is, at least, rather simplified, or either not compliant to the standard (the abc transcription of O'Neill's The Music of Ireland I took as an example of this shows the point, and you can't deny it!), yet this a a real wealth of music I really care about. That the abc1 standard badly needed an update, at least to be taken into serious consideration outside the English native speakers folk music circles, was clear four years ago. It's something under anybody's eye, and if the archives of this mailing list are still available they will show this is something we all were aware. Yet, we're still stuck to the old, unsatisfactory standard... why? Because the discussion was left to the subscribers of this mailing list. What actually happened is that an handful of developers - which aren't even the majority of the abc related software developers, by the way -, while on one side pretending they were the only ones entitled to decide about the future of the notation, were unable to agree about a number of the relevant changes needed to update the standard. Each one got on implementing his own way the features he supposed were relevant in his own software, to an extent an update of the standard is actually virtually impossible! Another basic truth under everybody's eye. IMHO, the abc notation is something that belongs to the whole community of the users, while not being the property on any of them. Currently we aren't anymore below what some called the Chris Walshaw's "benevolent dictatorship", and the self appointed ghost committee that should have been working to the long awaited abc standard update seems to have vanished, so maybe we're left a last chance to avoid the dispersion of that wealth of tune of which above. I'm definitely NOT RANTING, Richard, I am CLAIMING MY RIGHT TO DISCUSS as about the future of the notation, and I definitely won't leave the field without fighting. Given this, I pretend that those who are replying to my posting have read what I actually wrote! I don't pretend they agree, and if they think my statements are irrelevant, or they are not interesting in the matters I'm concerned with, I am ready to be ignored... ignoring those who aren't members of the "club" it's an another established method employed by the members of the self appointed abc establishment to discourage the common abc user from subscribing to the list itself! Yet, if somebody argues with me, he must do it about something I told, not about what he assumes I did. And if you think what I did replaying to someone who did the latter was "badmouthing" (whatever you mean with a term I have look for in vain on my humble Oxford Learner's English Dictionary), well, I think is a bland reaction to what, using words you'll surely find on any English dictionary, by my point of view are arrogance and superficiality. Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] There is a dumb man...(used to be linux only ?)
On 13/07/01 at 3.02 Anselm Lingnau wrote: >Gianni Cunich <[EMAIL PROTECTED]> writes: > >> Given this, If I really wish to use a flexible, user friendly notation >> package, like Melody Assistant (another software I am satisfied I have >> registered) or the NoteWorthy Composer, that's the rule...one tune = one >> file. To store a whole tune book you have to use a typesetting >> package... yet, none of those currently avalable really supports the abc >> notation except for the all too limited original standard > >Too bad. I use abc2ps (which does support multivoice music, for example) >to create EPS files which I can include in my LaTeX documents just fine. >In fact, I'm typesetting Scottish country dance books which look every >bit as nice, if not nicer (if I say so myself) than most of what is on >the market. See > http://www.tm.informatik.uni-frankfurt.de/~lingnau/pmbook/ Sorry, I do not wish to be deliberatley offensive, but actually to me this makes no sense at all. Among my requirements (and on top of them, although I could add a few more!) as far as a comprehensive music notation format is concerned, I would put as a matter of principles the following ones: 1) a basic repertoire of symbols: up/down mordents, up/down fermatas, segno, capo...; 2) multistave scores - i..e. a number of voices, each one one a different staff; 3) multivoices scores - i.e. a number of voices, with more that one voice (at least two different ones) one tte same staff; 4) multistave bars.- i.e. an easy way to notate two voices on the same staff for one single bar. Actually, abc2ps hardly fits only the second of my requirements. In turn, abcm2ps can probaly match my first three requirements, but not the fourth one. None of the available abc native softwares can match all of them, at least under Windows (I have heard Barfly is an excellent program by many a Mac user, but as it only runs on Macs there's no point in me looking into it any further, as Jack Campin would say!) , and anyway all of them are beyond the the current abc standard (and, except the first one, of the last updated abc draft, for the matter). Therefore: if you are satisfied with the scores you can produce with abc2ps - and if the average is what I have displayed following the link in your email, no wonder... even if I could obtain better results results even with abc2mtex! -, the best for you. Yet, we are talking about totally different matters: i.e. I am concernd about a comprehensive text music notation format, you are interested in a simplified, folk oriented one. A number of the real abcusers actually would prefer having at hand the former, but they must cope with the fact they are just offered the latter, and this is true for a number of the abcusers list most representative subscribers too. A respected one among them - I'm not making names, but I suppose everybody will be able to understand who I am talking about.. - actually uses Finale to upload his own scores on the web. I admit I cant' avoid a "little shade" of envy! I'm nor a professional musician, nor a professional engraver, and honestly can't afford such an excellent musical notation commercial software package. I would be happy to register it, if only my musical interest were able to compensate for its wheigth on the family budget! Another one has choosen a freeware music typesetting package called Lipypond. The best for her, too, and I'm sure I don't have to make her name as welll... and of course PLENTY of luck to those who hope to profit from any_score_in_any_notation_format she will concieve to upload on the web too!! As far as MY requirements are concerned, so far I have choosen to stick to MusixTex, which is by the way the music Tex/Latex related typesetting package Chris Walshaw wrote the afore mentioned abc2mtex (i.e. the original abc native software) for. I can't tell it is the best music typesetting package available. To be honest, I admit I'm actually considering the chance to register another excellent sharware music typesetting package that - by the time you'll read this posting, or at least in a few days... - should appear on the only really comprehensive abc related software list currently available on the web (that mantained on the musicaviva web site by Frank Nordberg, in case anybody had doubt about it, surely not the one on the abc home page!). The reason I haven't registered it so far is that on the developers' web site it's only offered a comparison with Lilypond, and not with MusixTex... that's unfair! They could have uploaded a score of Scott joplin's THE EASY WINNER, and! it would have been the same! Comparing any decent software with Lilypond, we'd say over here, it's just like shooting at the Red cross! Yet, probably the sharewar
Re: [abcusers] linux only ?
*** REPLY SEPARATOR *** On 11/07/01 at 10.27 Phil Taylor wrote: >Gianni Cunich wrote: > >>It's plain to see that the total lack of cooperation among the >>developers subscribing to this list has a lot to do with this, >>although I don't think there's anything we could do about it at this >>stage. If anybody still believes the abc notation could be taken in >>serious consideration outside the folk circles, the best for him. >>IMO, the endless debate on the sex of angels that has being going on >>this list for the past four years, and that has made any update of >>the standard impossible so far, was what actually gave it the kiss >>of death. How long those who are responsible for the notation demise >>will need to face this basic thruth is of course their own >>problem... not mine! > >I don't think the facts bear out what you are saying here Gianni. >Over the last four years the popularity of abc has increased enormously. >A few days ago I dug out all of John Chambers reports on his web crawler's >results and plotted the estimated number of tunes on the web against >time. You can see the results at: > >http://rbu01.ed-rbu.mrc.ac.uk/abcstats.gif > >(Bear in mind John's own reservations about the accuracy of this data>) >The number of tunes on the web has grown in a consistent logarithmic >fashion for the last four years. Add to that the fact that the abc >home page gets the top rating of any music notation site on Google >and you conclude that despite all evidence to the contrary we must >have been doing something right. Considering we are at it, maybe we could compare as well the logarithmic growth of the abc tunes availble on the web with the exponential growth of the erotic web sites! Also, considering the abc home page is an unreliable, rarely (and never comprehensively) updated source of informations, I am not really sure about if its inclusion among the top rating music notation site in Google is anything positive. For instance, when I first browsed thru it about four years ago, I read that to use abc2mtex or even abc2ps I had to own a C compiler and know how to use it! Actually, I needed a few weeks to realize that abc2mtex and abc2ps portings were available for all the major platforms... yet, the statment is still there! And what about the software list? I could name at least four programs - one of them is at least an half decent one, and another one a pretty excellent product -, yet the only update I have seen recently is...ABC Improvisor!? And, of course, you'll find no mention of ! the fact that there is an almost virtual, self appointed committee in charge of updating the standard... Who are you trying to fool, Phil? Be serious, please ! I do not wish to be deliberately offensive, but a friend of mine was known to comment your sort of statements with a clear: "Millions of flyes feed themselves with...(you know what!).How can they be wrong?" - I fear he had plenty of reasons to! >>What makes me feel sick (those who have read my last postings kown >>its my pavlovian reaction when I start discussing about the abc >>notation) is that, while we have been throwing away the baby with >>the bath water, someone else has built in concrete on Chris >>Walshaw's original intuition to create some excellent software. >> >>If you wish a nice example of what I mean, have a look at this web site: >> >>http://www.zelsoftware.com/ >> >>Zel, in fact, it's described as a language to create midi files from >>a text file, eventually to load them in a sequencer for further >>editing.. Everybody, having a look at the quick tutor on the site >>(the page is called Learn Zel in 10 minutes), will be able to see >>how much it has in common with the abc notation. >> > >Zel is a commercial product controlled by one person, who can change the >format in any way he wants. It is _very_ midi orientated, making no >concessions whatsoever to music notation. So, as far as I can see, >it has no way of representing beams, slurs or repeats. It is much more >sophisticated than abc when it comes to generating midi (but then that's >a relatively minor part of what abc is about). Zel (the program) is >only available for one platform (windows). Zel files can hold only >one tune, and since Zel tunes have no defined start or end markers >you cannot embed them in ordinary text as you can for abc. While there >are around 100 K abc tunes on the web, there are about a dozen in Zel >format. > >These are conclusions reached after about fifteen minutes reading the >Zel site, and my not be entirely accurate, but even so it's no contest. Yes, Zel is a commercial
Re: [abcusers] linux only ?
On 06/07/01 at 13.02 James Allwright wrote: >. Perhaps we need someone to write a noddy >front-end that invokes an abc2ps clone, ghostscript and then an image >viewer to bring free abc typesetting to the masses. Seymour Shlien has been doing that for quite a few years, and that currently Runabc is an excellent GUI for abc2ps, abc2mps, yaps, abc2midi and abc2abc, offering at the same time an excellent abc aware editor packed with a number of intersting features? And obviuosly calls GosthScript (from which you can converte the PostScript in Pdf format), and a couple of midi players to listen to the midi files generated thru abc2midi. In fact the addition of abc2mps is fairly recent - months I guess -, and made available for the first time in three or four years the progrma in a compiled version fo Windows users. As someone underlined: >One of the basic ideas behind ABC is that it's for everyone, and - as >hard as it is for us to believe - there is, even today, a small minority >of computer users that feel slightly uneasy when asked to compile the >software themselves... And this has nothing to do with blaming the developers because they don't supply binaries for a number of platforms. The first real problem to bring the abc notation "to the masses" is the abc notation in itself - in other words the lack of un updated standard able to turn a limited number of conventions which works well for a quick transcription of simple (simplified?) melodies into an all purpose typsetting system. The second real problem, beyond the unavailability of precomplied softwares, is the quality of the available ones (or rather their lack of it). The last Windows version of abc2ps is pretty old, and doesn't support a number of draft useful features that abcm2ps has implemented so far; yaps is simply a real mess; abc2midi insists on playing broken rythms with as 2:1 rather than a 3:1 ratio... The evidence is under anybody's eye. Just a look at Frank's Nordberg comprehensive abc related software list at the musicaviva web site will show more than 60 different programs. Yet, once you have selected those which: a) aren't clones of other entries listed (not compatible of course with the prototype); b) aren't abandoned full of bugs betas; c) are cross platform projects which are really meant to be useful for the whole abc users community; d) do something everybody needs (i.e. not just something their developers need, or eventually other programs don't); e) are user friendly (i.e. they don't need a GUI to be useful to your average non computer addict folk musician); ..well you probably are lucky if you'll end up with an handful of them.. and a few, reliable but unfortunately not cross platform, notation packages that 'speak' abc! It's plain to see that the total lack of cooperation among the developers subscribing to this list has a lot to do with this, although I don't think there's anything we could do about it at this stage. If anybody still believes the abc notation could be taken in serious consideration outside the folk circles, the best for him. IMO, the endless debate on the sex of angels that has being going on this list for the past four years, and that has made any update of the standard impossible so far, was what actually gave it the kiss of death. How long those who are responsible for the notation demise will need to face this basic thruth is of course their own problem... not mine! And I don't see the point in asking why the standard committee keeps silent... the best for it! Yet, I can't help regretting. As I can't help dreaming about what might have become the notation if only a number of developers rather than producing clones of one single program (or of other of its clones), introducing new fwtures that in turn the non standard abc written for it uncompatible with the original and the other clones, had been able to work together toward the goal of producing an all purpose tool for the whole community of the users. What makes me feel sick (those who have read my last postings kown its my pavlovian reaction when I start discussing about the abc notation) is that, while we have been throwing away the baby with the bath water, someone else has built in concrete on Chris Walshaw's original intuition to create some excellent software. If you wish a nice example of what I mean, have a look at this web site: http://www.zelsoftware.com/ Zel, in fact, it's described as a language to create midi files from a text file, eventually to load them in a sequencer for further editing.. Everybody, having a look at the quick tutor on the site (the page is called Learn Zel in 10 minutes), will be able to see how much it has in common with the abc notation. Window users are warmly suggested to download the Zel Free edition - it's limited to 1500 notes, which is probably not that much for classical or even pop music, but should be enough for most of the tunes available
Re: [abcusers] MIDI cat ?
On 25/06/01 at 18.24 Ronan KERYELL wrote: >> On Mon, 18 Jun 2001 16:57:17 +0200, Bert Van Vreckem ><[EMAIL PROTECTED]> said: > >Bert> You're abusing the X: field for something it isn't designed >Bert> for. > >Sure. :-) > >Bert> In an abc file, an X: field marks the start of a new tune >Bert> that is independent of the other tunes. To split up a tune in >Bert> several parts, you should use the P: field. > >I do also inside of each X: tune. > >Bert> What is your rationale to use X: instead of P: to split a single >Bert> tune in different parts? > >You cannot specify a different title, source, author,... to the P: part. > >But what we play for example in Breton suites are a link of different >tunes from various origins. abc2ps is OK with that but not abc2midi. > >I could also add an option to abc2midi to skip the tune separation... Hey, what about using T: fields in the tune body to specify different titles? As far as the abc standard is concerned, thet's legal! And you could use the A., C:, S:.. fileds in the header to pack the infos related to the different tunes in the suite...something like this: X:1 T:Suite T:1 T:2 T:3 C:1:composer, 2 Composer, 3 composer M: L*** K*** T:1 body T:2 body T:3 body Not sure about what you could obtain from abc2midi, I've never tried anything like this! Yet, as far as it follows the standard, it should be able to give you one single midi file for a whole suite (set, medley... call like you like it) of tunes. By the way, I actually share the belief you are abusing the P: field, Ronan. To say better, I think you are abusing the P: field the wrong way! ; -) The correct way to abuse the P: field, I dare say, is to use it in the body of a tune followed by blanks... no need to use ! or ;, or anythung else to force a line break, that's the natural line break character as far as abc native software are concerned! Why the hell a P: field in the body should cause a line break I don't know - it isn't stated in the standard, and makes no sense at all, but i works! And it works even with ABC2WIN 2.1.k (although not with the 2.1.i version. which should be the last stable one)... considering abc2ps and all its clone offer an option to ignore line ends, if only ABC2WIN could stop printing PART:... whenever a P: field appears in the body, we would actually have solved most of our problems! :-)) Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] What's happening?
Fine! it's June the 16th. 20.47. My email client states I have posted a message to this mailing list on June the 15th, 23.05... ..my provider implicitely states that the message reached its destination, since I got no errror message... ... I haven't downloaded it yet! What's the problem: the contents of the message? Has the Big Brother's syndrome affected the whole abc Establishment? Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
On 13/06/01 at 0.20 John Chambers wrote: >>Gianni Cunich writes: >> >>| Sorry, but I actually got bored about the discussion about the abc2midi >>behaviour...so bored I actually felt sick! >>... >>| The "real" problem, IMO, is a totally different one: is there anybody >who actually cares about the respect of the standard anymore? >> > I assume the answer is: no... except fot those who actually think to be >in charge of its update! Pity the rest of us parias is still waiting for >"news from the front"... > > >Well, I can certainly sympathise. As the one who foisted the abc tune >finder on the web, I see an impressive variety of what passes for >abc. A number of email exchanges have verified that some people have >little if any interest in following any supposed standard. ... >>I sure do wish we could get abc2win in line with the standard. And >>that we could get people to stop embedding abc in html. Those two >>things would solve most of the existing problems with online abc. But >>I already know the answer to both of those. ... Sorry John, but as have already stated in some private emails - and this, as you know, does not diminish the high esteem I bear to your contribution to the widespread of the abc notation making you tune finder available to the community of the users - I think this is, on your part, pure hypocrisy. In his short history of abc Chris Walshaw was honest enough to admit that: "The real explosion in interest came when Jim Vint released his package abc2win in September 1995. The tool was taken up by a large number of the members of IRTRAD-L and abc's of tunes started appearing regularly. " As we both know - as anybody else on this list, for the matter! - ABC2WIN is "de facto" the standard as far as the abc notation is employed on the web, both as far as the mailing list and a number of the abc collections of tunes available for download are concerned. Yet, in your chronology of the abc related software (well.. as far as I can remember, since the link in the abc home page, as I have realized checking it today, now points to your abc notation tutor) actually ABC2WIN wasn't deliberately even mentioned, in pure "Big Brother fashion". What are you charging Jim Vint for? Yes, he has derogating the standard ignoring the rule that "a line of text means a line of music unless (what a brilliant intuition!) it's too long", and introducing the "!" character to force a line break. And so what? That's what any musical typesetting package developer would find sensible, and if abc2mtex (and therefore the original abc standard) would have been written with MusixTex in Chris Walshaw's mind, rather than with MusicTex, that rule wouldn't obviously been part of the standard. And in case someone pretends he doesn't understand the point, what I'm actually stating is that, If we had adopted a line break symbol rather than the inane "line of text equal line of music" rule, we'd have no reason now to discuss about the problems caused by the unexpected line wrappings produced by some of the email clients... pity the refusal to adopt Jim's sensible choice - that obviously was made as a matter of principle - has led to a number of problems for all the abc notation users! You know, it was like throwing away the baby with the bath water! Anyway, the abc2ps clones introduce a number of other non compliant features, that could be dangerous if there were enough "real" abc users to employ them, like the ghost rests and the ghost bar lines...I even experienced recently that abcm2ps creates a dotted bar line when it finds a "!" character... the problem is that really few people are aware of such obvious pitfalls with the abc native softwares, and the reason is that the diffusion of abc2ps and all its clones put together, compared to the diffusion of ABC2WIn, is in fact irrelevant! Who are you trying to fool, John? Even if we could try to upgrade the abs standard now, it would be too late to persuade the developers that monopolize this list - who actually are those that, not being able to agree about the way to implement quite a number of basic abs extensions that were a vital needing in order to really develop the notation and ensure its growth, are responsible of the actual state of confusion - to make sense of the different options the available software packages offer to solve a number of common problems. Anything that the self appointed, farcical committee actually in charge of update of the standard will be able to do (and considering that they have been working for a few moths, they could easily give up and nobody would even realize they have!) , as far as the "real" community of the users is concer
Re: [abcusers] New abc2midi command
On 14/06/01 at 8.25 Laura Conrad wrote: >> "James" == James Allwright <[EMAIL PROTECTED]> writes: > >James> For all those plagued by the 2:1 ratio, help is at hand ! > >James> I have just uploaded a new version of abc2midi with a >James> %%MIDI ratio command which controls how > and < are played. > >So someone who wants the implementation of < which is described in the >standard has to put: > >%%MIDI ratio 3 1 > >into every file? It would be a better implementation of the standard >to make that the default, and it would be more convenient for those of >us with a lot of existing ABC files if there were a command line >option. If Laura got what James wrote right, I whole hearthly agree with her (It would be the first time since I subscribed to this list, really... yet, as we use to say here in Italy, even a broken watch tells the correct time twice a day!). Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] abc compliant software (was:midi2abc [was: Wanted: ABC transcription...])
Sorry, but I actually got bored about the discussion about the abc2midi behaviour...so bored I actually felt sick! The problem about the way abc2midi handles the broken rythms shortcut is that it actually playes (and "save as" midi) any beat using the ">" symbol as a triplet, even if in the R: field you state the tune is a schottische (and English schottisches, at least the oldest ones, are usually played dotted, unlike the recent ones of the hornpipes), or a polka, or anything else... In other terms, the basic thuth is that ac2midi is not an "abc compliant" software, or, to say better, is unreliable...and that's all we can (and should) say about it! The "real" problem, IMO, is a totally different one: is there anybody who actually cares about the respect of the standard anymore? I assume the answer is: no... except fot those who actually think to be in charge of its update! Pity the rest of us parias is still waiting for "news from the front"... Gianni P.S: No. I won't enter a debate about what anybody as a little common sense left is able to see and (hopefully) understand. So, please, don't reply to this mine... thank you! If you really feel prompted to, make concrete suggestions in order to save the abc notation (assuming we're still in time to...), or even better the wealth of tunes that has been availbale on the web using it. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Making PDF (Was: ABC standards committee webpage)
On 16/03/01 at 6.40 Laura Conrad wrote: >> "Frank" == Frank Nordberg <[EMAIL PROTECTED]> writes: > >Frank> That's why most people today seem to use GhostScript, a >Frank> free postscript reader available for all major >Frank> platforms. > >Which is also what I did; ps2pdf is part of the ghostscript package. > >Frank> The problem for most Windows and MAcintosh users is to get >Frank> postscript files in the first place (I understand >Frank> postscript is more or less standard in the Linux/Unix >Frank> environment). > >I don't know much about Macintosh, and only a little bit more about >windows, but what you do in general is install the driver for a >postscript printer (such as the applewriter), and then use a "print to >file" option from your application. I believe Windows will name the >file something other than .ps, but it is in fact a postscript file, >which the ghostscript program will know what to do with. > I posted the following text to this mailing list about six month ago (26/10/00): Maybe we should mention that - at least under Windows - you do not need a poscript printer to produce PostScript output (and that's true for EPS as well). 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. Encore users already know this - that's the way Encore used to export to EPS -, but this can be done with any Windows program, even abc2win (especially it, I guess!). 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 forum too - there is some debate about the best poscript printer drivers (I vote for the Adobe Poscript Printers with the Distiller PPD files, that handles colour images and let you define the dimensions of the sheet you are going to print). I should probably add that: First: Free PDF is still the easiest free way to obtain PDF files, but the PostScript ones got deleted in the process, so anybody interested in storing both the .PS and the .PDF files is suggested to simply install the Adobe postscript drivers and use therefore Ghostscript. Second: Free PDF is actually 'complex', rather than 'difficult', to install. Any Windows novice should get the hang of it in half an hour or so, if he only follows carefully the instructions supplied on the web site. Anybody who has been able to make use under Windows of the main abc native softwares will actually find installing Free PDF quite relaxing! Third: there are other software to produce PDF files, which are cheaper than the Adobe Acrobat, but aren't freeware. You'll find a couple of links in the Free PDF web site. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Hi
On 02/03/01 at 19.56 Laura Conrad wrote: >> "Toni" == Toni Schilling <[EMAIL PROTECTED]> writes: > >Toni> Could you give me a hint where to find the new abc standard >you're >Toni> discussing. (saves me from clicking) > >Look at the directory >http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/src/standard/?cvsroot=abc > >The file abc.txt is the actual official 1.6 standard. > >The file abc-draft.txt is the draft standard as Chris Walshaw left it. > >abc2abcdraft.txt is one possible format for specifying changes, as >applied to the changes between abc.txt and abc-draft.txt. > >The other files are experiments on the part of the ABC standards >committee to produce a process that is both friendly and unambiguous >for specifying changes to the standard. The ones that are essentially >other formats for abc.txt are called standard.*, and include pdf, >html, and txt versions of the information in abc.txt. The ones called >standard-propose.* are the equivalent for abc-draft.txt. I suppose that this ought to be officially announced on the abc home page. In case you have forgotten it, that's where real abcusers usually look from time to time for infos, in hope it had been updated a bit more frequently than on a quarterly base... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] developers/users
Hi, RJP You have been able to sum up a confuse and misleading debate in a few words, and make some sensible considerations, but you are wrong on one pont. > > Developers are *not* the only people who get a say in what ABC ought > > to be, or what it should be used for. You wrote: > O yes they are! all the Linux software for abc is FREE, > so I think nobody has the right to ask the `developers' to do ANYTHING. > - without paying them that is! > > If someone makes a deal with me to do a programming job, then I do it > the way they want it for pay - but not otherwise. > > If I program for myself - then I do EXACTLY what I want - and i would > be surprised of most developers do not do just the same. What in fact we are arguing about is the right of the developers on this list - which, please remeber it, are in fact a minority of the developers of the ac related softewares available to the community of the users - to be the only ones entitled to decide about the future develpments of the notation. The use of the guitar chords syntax to put text on the score is a topic example of how a need expressed by the users has been incorporated in the draft in a way which fits some of the available packages, but won't work with a number of sharewares that 'speak abc'. I agree with you that: > There are quite a lot of composition packages around already - some > of them shareware. Would it not be better to keep abc simple > and concentrate on providing means of importing / exporting abc > to some of these packages? - by providing parsing routines for > selected shareware authors for ex. In fact there is a number of excellent and often unexpensive notation programs which already import/export the notation. Unfortunately, to work with them we need an upadated standard to stuck to - not sure you have noticed it, but the current standard is still one line of music, in the Key of G, with four octaves of extension! If I had to complain with the developers of the abc speaking package I have registered about the poor support they are offering for the abc notation, the obvious replay would be that to make it work correctly they will wait until the current one will be updated. This is why, in fact, I suggested we could discuss the opportunity to take the draft as it is now - i.e. without any agreement about the V: lines - as the new standard, and eventually update it again when the riotous developers on this list will have found some agreement about that. Any further delay is working against the widespread and the promotion of the abc notation, and this is in fact the developers' (on this list) responsability. > That way, abc can still be used to `sketch' the music & express > the salient points, whilst adding the `bells and whistles' using > something else that CAN ALREADY do it... > > This could of course, result in loss of detail when abc is re-exported, > which one would have to accept, since any conceivable abc notation > will still probably be insufficient for a lot of the advanced music > typograpy.. > > The `simplistic' users can continue to use abc for free, and those > who actually want all the extra programming effort can pay - > seems fair to me! This is what I had in mind when I suggested that we should keep separate the notation and what concers its future developments from the packages we use to manipulate it (to print scores, generate Midis, an so on...). Not a popular idea (to contrary belief?). > The only other course open to someone determined not to pay > for software but still wanting special funstions is to do > what the rest of us do - get out gcc / emacs / TeX and > get started! Maybe an abc2mtx converter would help! How much would you charge for a working one? Windows version...of course! BYE! Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Developers responsibilities
Laura wrote: > There are some points in your letter that I know I don't understand. Well, I wasn't thinking about you when I wrote that one of the vices of some of the subscribers to this mailing list is that they don't read what other write, assume they have understood it anyway, and feel usually prompted to express authoritavie opinions on matters they don't know anything about...which in fact is a basic thruth! Anyway, Laura... yes, ther's a lot you haven't understood. In particular... > If I understand you, you're saying that it is wrong to use the guitar > chord feature to do text annotations, and that a way to do text > annotations doesn't belong in the ABC standard. If this is what > you're saying, I think it contradicts some of the points you make > elsewhere about how developers should listen to the users. The reason > the guitar chord notation got co-opted for text annotations is that > many, many users needed a text annotation of some kind. Yes...no you didn't understand. What I said is simply that, if you agree that one of the abc notation stenghts is its human readability, using double commas for text annotation is self defeating. If you had have a look at the M-Tx user guide, as I suggested, you'd know what I meant when I invited to look outside the little abc world to get some fresh inspiration (And don't tell us you have, otherwise we will be discussing about what we coul learn from a different approach to write for a typesetting music package, rather than that you aren' able to understand in what I wrote). The need of some of the users for some text annotation is something I am aware of, although the number of requests for new features you can read on this mailing list are surely not representative of the need of the majority of the users, because they do not subscribe or actually don't express their opinions nor their request because they think they will be ignored (do you remembre how this discussion started with?). What I think (and that's what I said) in first place is that extending the guitar chords notation to cover more than a few expression marks is simply a way to make life easier for the developers of a limited numebers of softwares to the detriment of the human readability of the notation, and anyway, as a number of established softwares which 'speak abc' have implemented different features in response, if we really care about the widespreading and the promotion of the abc notation we should reflect about an untroubsive way to handle it - the compatibility of the future develompments of the notation with established non native software packages is important if we wish to take it out of the folk fringe. Given that, if the developers of this list think their self referent hacking pastimes are an expression of the free source philosophy, they can feed their illusions on their own. And, PLEASE!, don't talk about Anarchism without knowing what historically this means - please read some serious paper about it - i.e. the Kropotkin's self biography -, and you will realize that real anarchists reacted against 'imposed authority', not against the authority that the recognised leaders actually gained for their intellectual and moral stature. Lack of the latters in this quarters? Anyway, as we are arguing about definitions, when I minority (the developers which monipolize this list) of a minority (the developers of abc related software) pretend they are entitled to impose their points of view to a whole community (the abc users which this list is supposed to represent), being polite I couldn't think of any better term than dictatorship... As it usually happens, what was relevant in what I wrote got ignored, like the suggestion to look outside the short breath world of the abc native softwares for inspiration (is it so boring reading through those well concieved user manuals so helpful to the newcomers?), the idea we really ought to make a distinction between the notation and the packeges we use to manipulate it (a strong point if we believe the statement that abc is not a proprietary format is not an inane sequence of words), or the proposal to adopt as a compromise the current draft as a temporary new official standard which could allow the developers of non native abc software to update their packages as far as abc as an import/input format is concerned, rather than wait for ages for a comprehensive one that the minority of abc related software on this list seem not able at the moment to agree about (and it's a moment that has been lasting for some three years so far...the developers responsabilitis...). What a waste of time...really! Regards Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Developers responsibilities
Bryan Creer wrote: >... ...well, read carefully his email - one of the vices of some of the subscribers of this list is to assume they have understood what other people have written without actually really reading (and then express authoritative opinions about something they don't know anything about)... Anyway, I found a lot that makes sense in what he wrote. In the end I agree with him about a number of things. For instance I firmly believe that what makes the abc notation great is that it is a perfect exchange format. Or, by the way, that it ideally belongs to the whole community of the users, while being a property of none. My suggestion that we should look back to Chris Walshaw original intuition, and use a converter to MusixTex - or for the matter to any other typesetting package/full featured score editor (like the excellent noteWorthy Composer, why not?) -, was in fact a way to underline the risk we are facing identifying the development of the format with the implementation of the software packages we use to print scores, obtain midi files, or otherwise manipulate the notation to fulfill our own purposes. Fine, at the moment I find MusixTex the best available solution to some of my needs, which in fact won't probably be satisfied by the long-to-come updated abc standard altogether. And, by the way, I am not asking for the moon! The current unrevised standard is enough for most of my needs, and perfect to notate most of the melodies I play, but when I wish to transcribe a performance of a polyphonic instrument there are at least to features which I can't handle in standard abc - two voices one staff, at least for some bars here and there, and the possibility to define grace notes lengths -. Could you please stop and reflect about it for a while? As far as folk music is concerned, almost any stringed instrument, or any free reed instrument, is polyphonic! Even so - and even if I am talking of features that even the cheapest notation sharewares on the market have implemented -, I haven't been beating the drum about my own needs/requirements (anyway, not being a developer, I probably would have been ignored like simple users usually are...). But when I see the notation cluttered with the current throw-anything-you-can-think-of among the guitar chords double quotes approach I wonder if there's any ounce of common sense left in there quarters. Fine, we can live with the expression marks (actually, I have never seen a transcription of an Irish reel or of an English polka with indicatitions like ppp or fff...), but what about text to be printed above the notes? Shifted on the left or on the right, rather than centered? Who's fooling who? This has nothing to do with the musical notation, and is something typesetting packages/notation programs are handling differently (MusixTex is an exception, I fear!), so we should better leave them to the software peculiar implementations, and drop them from the standard (are we still in time? If it's draft...). Maybe tomorrow I will choose some other software (the NoteWorthy Composer? Why not!), even if an mtx file is pretty easy to edit given the similarities with abc: and so what? This is part of the freedom the abc notation has guaranteed to its users so far. I fear for a number of them, including me, this freedom of choice will be precluded if the notation becomes too heavily package dependent (not to tell about the fact that the packages aren't exactly the flexible ones among those available to the community of the users!). I am sorry, the way 'voluntocracy' is pronounced in this quarters, were I live is called dictatorship... One last consideration: to write converters - whatever the software -, we need a standard, and we need to stuck to it. If we really believe in the potentiality of the abc notation, and are concerned with widespreading and promoting it - something which WE SHOULD BE DISCUSSING in terms of positive and concrete action in this mailing list, if it WAS the abc USERS forum, and WE ARE NOT! - the delay in updating the current one is, in concrete terms, self defeating. Maybe we should decide that the actual draft, without any agreement about the voices, is the current standard, and wait for a further update when an agreement about the V; lines will be reached. I suppose this would make a lot of us non-developers happier! Regards Gianni P.S. And please, talking about the abc native software, I think we should avoid terms like "open souce development". The sense of concrete cooperation which such a definiton implies has noting to do with the fact that the code of a program is available without restrictions (so that anybody can hack it to his own pleasure, rather than implementing new feature in it). Let's not joke about it, please! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2ps?
A few replies to a few emails... Hi Chris You wrote > Thanks; I will give it a try and see. I haven't had a lot of luck with > TeX, though; I tried to build and install on my system, and it failed > miserably. :) (I'll try a Linux machine next and see what happens). Under Windows I have had no problems with MikTek, the Gnu Tex/Latex distribution. In case, get in touch with me outside the list. Meanwhile, have a look at the MusixTex user guide, page 28 and page 29 - that should be the solution to your problems. Ciao Andrea Come sopra: contattami direttamente. Hi, Laura You wrote >There are people (including the principal maintainer of MusiXTeX) >doing a lot of good work in PMX, which is an ABC-like preprocessor, >which nevertheless allows a lot of control over the look of the >output. There are also people extending LINUX-based sequencers to >export it, and recent versions will export MIDI. So I think it's >starting to be the answer to a lot of things. >The big reason I can't tell you more from personal experience is that >most of the music I'm interested in is vocal music, and you need a >preprocessor to the preprocessor for that, which I've never managed to >install correctly. I assume that the preprocessor to the preprocessor you have mentioned is Musixlyr,which is in fact not really user friendly. I assume you have never tried M-Tx, the one Christophe Declercq suggested, which uses the Musixlyr package, but offers an input language that's even easier than the one adopted by PMX, has been designed to insert lyrics in a PMX file, and under Windows is easy to install (you have to copy the binaries in the folder you prefer!). Well, in fact this is not the first time I talk of M-Tx on this list. I even posted a couple of weeks ago a tune in both abc and mtx notation for comparison - as usual, it got ignored (I guess, as far as the abc notation is concerned, that the Dead Sea Scrolls are a more relevant matter fot the subcribers!). In fact the mtx notation might seem a bit confusing for those that are used to the abc, but once you got the hang of it - i.e. you learn to think in relative rather that absolute note pitches - (and here, I firmly disagree with Christophe), in terms of human readability it's not second to it, at least for easy scores. For complex scores in turn, with multivoices and extra lyric lines, let me tell that I find mtx better than any suggestion I have read about the V: lines inclusion in the future abc standard. I agree with Christophe when he states that the database structure of an abc file is excellent to "store, search...tunes". I would ask him to read again what I wrote, though - I wasn't suggesting that WE should convert from abc to mtx, but only that A CONVERTER to a full featured typesetting package would be helpful. And I mean helpful for those that have the need (occasionally or extensively) to print complex scores with features that, even if quite common in printed Western music scores, the abc notation standard doesn't cover, and therefore the native amatorish abc software haven't implemented yet (although, since the future developments of the standard seem to be in the hands of the minority of developers that monipolize this mailing list, we could easily tell the opposite is true as well - only the new features that will be experimentally implemented in those softewares are likely to enter the standard!). Given this, we could store, swap, upload on the web our tunes... in abc format, and resort to the converter when we need a printed score. By the way, I haven't noticed the PDF files produced by Tex are ugly to read with the Acrobat Reader: I usually prefer to use Ghostscript, both to view and print PostScript files. Anyway, they probably look perfect once printed (as the PDF files produced converting the PostScript files obtained with Acrobat Distiller drivers with GosthScript), which I suppose is what people usually do with music scores). That they are heavier files, I couldn't care less: when abc2ps and its clones will offer me the same feature musixTex currently does, this will be something I will consider. So far, in comparison we are to a scarce third: no match at all! Anyway, Laura, have a look at the M-Tx user guide, and I am sure we will find matters for further discussion. Regards Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] abc2ps?
Hi, Chris You wrote: > This is more a printing/notation question than anything else; it may not be > applicable to the ABC spec, but -- > > I'm interested in noting and printing fife & drum music, especially from the > 19th century, and although the fife parts are fairly easy, the percussion > part is painful. Nothing seems to really produce anything that is readable, > or at least in a notation that modern players can understand. A small GIF is > attached to show what I'm up against... > > One piece, the lead-in rolls, are essentially a string of grace notes that > cross a bar. This I can fake with abc2ps if I'm allowed to specify a zero- > length note. This results essentially in an invisible place-holder (the object > of the grace notes) which can be tied to a real note at the beginning of the > next measure. Some abc2ps versions seem to complain but accept it, others > choke up. > > The other, more commonly used notation, is putting three diagonal slashes > through the staff of or below the note to signify a roll. *Nobody* prints > anything close to this. > > Any suggestions? (I have run into a program called mup, Music Publisher, > which seems to print nicely, but the input syntax is closer to lilypond > than anything else). > > - Chris Drake Bryan Creer stated: >Presumably Chris Drake will be told that >if he thinks Fife & Drum notation is so important he should go off and write >his own software to do it (with midi generation). I think Bryan is inclined to be a bit too optimistic: in fact you have just been ignored (as it usual when someone asks about something the developers on this list don't need themselves). Anyway, if you do not wish to spend some money on a full featured notation software and wish to stuck to the typesetting music line, I would suggest to try MusixTex. It can handle fancy things like beaming across bar lines and symbols like the one you call roll, although I assume they might be a bit tricky to handle, and of course offers a chance to define grace note lengths, force stems up or down, write two voices on the same staff... - i.e. all what any barely decent typesetting package to type music is supposed to be able to do! And don't be fooled by those that tell that the MusixTex notation is cryptic - deserves some works on the tricky bits, where you have to hack the tex file, but nearly all the rest of the work can be done with pre-processors that are fairly easy to handle. Even the old good abc2mtex, in case, even if the way it handles multistave scores is...how to say... self defeating? And even if you are a Windows user, it is fairly easy to install MusixTex and the related packages too (as far as you ignore the confusing suggestions on the abc homepage and the related links). Actually, I wonder what might have happened of the abc notation if, following the original idea of Chris Walshaw to write a pre-processor to MusixTex, rather than in developing an endless series of home made clones of an homemade software like abc2ps the efforts of the developers which monopolize this mailing list had been addressed in cooperation to update abc2mtex to offer the whole community of the users (i.e. the musicians who don't happen to be C developers, to quote Bryan) a tool they all could use, each one to fulfill his own purpose... Regards Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: Why XML is a bad idea[longish] (was Re: [abcusers] draft for V:)
On Juanury 4th John Henckel suggested to make the abc notation XML
compatible, but then said he had changed his mind since that would have
meant would sacrifying too much of the clarity and
usability of ABC.
Richard Robinsons replyed:
Have you ever looked at raw musixtex, as, eg, hint hint, output from
abc2mtex ? It's *far* nastier than that :)
Well, the first four bars of Jacob (or Enrico - English hornpipe appearing
in the Hardy family manuscript, for those which aren't familiar with it, and
in quite a few abc versions on the web), looks more or less like this:
\pnotes{2.83}\qu{'a}\en%
\xbar
\pnotes{2.83}\ql{'d}\en%
\pnotes{2.00}\ibl1{'f}{-2}\qb1f\tbl1\qb1e\ibl1c0\qb1d\qb1c\qb1d%
\tbl1\qb1b\en%
\xbar
\pnotes{2.00}\ibu1{'a}0\qb1a\qb1b\qb1a\tbu1\qb1{`g}\en%
\pnotes{2.83}\qu f\qu{'a}\en%
\xbar
\pnotes{2.83}\ql{'d}\en%
\pnotes{2.00}\ibl1{'e}2\qb1e\tbl1\qb1f\ibl1g0\qb1g\qb1f\qb1g\tbl1\qb1f%
\en%
\xbar
\pnotes{2.83}\ql{'e}\ql{'a}\ql a\qu{`a}\en%
Yes, those are just four bars of music, stipped of any comment lines, not to
tell of some 25/30 lines of header!
Yet, have a look at this please:
Title: Jacob or Enrico
Composer: traditional
Meter: 4/4
Sharps: 3
Style: SOLO
a4 | d f8 e d c d b | a b a g f4 a | d e8 f g f g f | e4 a a a- |
d f8 e d c d b | a b a g f4 a | d g8 f e d e c | d4 d d :| f8 g |
a4 a8 g f g f e | d e d c b4 b | g8+ a g f e f e d | c d c b a4 a4x3 b c |
d4 d c8 e c a | d4 d c8 e c a | d4 f e8 d e c | d4 d d :|
Now, have a look at its abc counterpart:
X:1
T: Jacob or Enrico
C: traditional
L: 1/8
M:4/4
K:D
A2 | d2fe dcdB | ABAG F2A2 | d2ef gfgf | e2a2 a2A2 |
d2fe dcdB | ABAG F2A2 | B2gf edec | d2d2 d2 :|
fg | a2ag fgfe | dedc B2B2 | gagf efed | cdcB A2(3ABc |
d2d2 cecA | d2d2 cecA | d2f2 edec | d2d2 d2 :|
Do you really think that the abc notation comes out as a clear winner in
terms of human readability? And if I had chosen a complex score (multistave,
multivoice, many lyric lines, guitar chords, marks...)...
Maybe having a look around to see what can be done with other typesetting
packages could be of some help in discussing the V: lines sintax.
Regards
Gianni
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] The mailing list and the abc Users Community
Fine, this used to be Blank Music Sheets, but as someone suggested I changed the header! I (provocatively!) wrote: >a VERY HAPPY NEW YEAR to all the abc users > | > | P.S. And I mean THE REAL abc users - i.e. those which "make a mess of the > | notation" on other mailing lists, and yet are able to use it "against all > | odds" as > | an exchange medium to swap tunes on the web! John Chambers replied: > Well, REAL abc users don't need any of those fancy-shmancy formatters > or players or GUI tools. They just read the abc directly, and write > it using a dumb editors. Unix users just use cat. And they write perl > or python scripts to munge the abc in useful ways. > > ;-) > Sorry John, makes no sense to me. The strong point about the abc notation is that it can be read and written without using a computer, but at the same time it can be stored in text files and be veihiculated through the web in an easier way than, say, scores in some image format, or midi files. Yet, it remains notation - i.e., at least as far as traditional music is concerned, a way to fix on paper the bare bones of a dance or song tunes. It's an instument, not a scope in itself, and can be relevant as far as people find it useful. Some other subscribers to this list have made clear that no available native abc software satisfies their requirements, and this is something we should reflect upon (I guess the idea to update abc2mtex wasn't that bad, though I would rather prefer a convertor to PMX, or even better M-Tx), but I don't think this is what should upset us in first place. The real point is that most of the REAL abc users need fancy-shmancy formatters, or players, or GUI tools. And, what's more, a large majority of the potential future abc users will need them. I am talking of most of the ones that actually play by ear, or can hardly read an easy score - reading music isn't a required skill in traditional music circles, remember? -, and/or as far as computers are concerned are barely able to turn the machine on and off. They need user friendly tools to benefit from the whealth of stuff that has been made availbale in abc format, print scores, generate midi files, learn to use the computer as an aid for practicing... Be serious, John, the REAL abc users aren't likely to learn perl, python or whatever you might use, or to hack the last abc2ps clone (the number of the acronims so far might rise the envy of any Japanise cartoonist!). An so what? Are you suggesting they/we do not deserve attention? That they/we are second-class abc users? Are we likely to read again silly statements from some developers like the following ones which appeared on this list a few months ago? >Been there, done that. No point in going round in further circles. >The rules of abc are decided by democratic vote among the developers. Or this: >What does justify that statement is that only the developers >are in a position to judge how much work is involved in implementing any >given suggestion, and what effect that change is likely to have on the >future of abc. If WE like it gets done; if not, it wont, because WE >are the ones that will have to do the work. Now if you don't like that >Bryan, you know what you can do. I didn't even care to take notice about who said that - just copied it in the clipboard a few months ago for further reflection! But... sorry, again this makes no sense! The abc notation belongs to all the users, without being the property of none! You see, John, what actually makes me share your smile ( (;-)!) is that us pariahs can actually do without any abc native software written by the handful of developers which virtually monopolize this mailing list, and profit from a number of programmes that are hardly mentioned, if not with snobbery - Melody Assistant, Music Ease, Tabledit not to tell about the recurrent mourning about tunes downoaded from the web which aren't standard abc, and are likely to be the fruit of the often vituperated abc2win. Whithout whom, according to what Chris Walshaw states in his short history of abc (linked to the abc home page), the notation probably wouldn't have even taken off. Who are we trying to fool? In a few years, if we aren't able to build a REAL COMMUNITY of users, this will actually make irrelevant any future development of the notation itself. If we are lucky enough the abc will be considered just like a compact format to upload, download and transmit folk tunes on the web, will be generated with non native abc softwares, and converted to be used with other non native abc softwares...Sorry, there is nothing you can't do about it, and nor the self commiserating attitude (see what they're doing to our pet!), nor the bellicous one (burn the plantation, the Federals are coming!) can help. Let me stress again the concept: If we really care about the future of the abc notation, me must think in terms of a REAL COMMUNITY OF THE USERS, and think in terms of COHOPERATION and POSITIVE ACTION.
Re: [abcusers] Blank music sheets
Following a few other emails, John Chambers wrote: >Yup; this was more or less what I was thinking when I hacked jaabc2ps >to do blank staves in response to > M:none > K:C clef=none > >I did look at the postscript example, but with my meagre >understanding of PS so far, I couldn't quite discern why it produced >the number and size staves that it did. So I couldn't figure out how >to tweak it to get the size and spacing that I wanted. On the other >hand, I've used abc2ps a bit, and I'm familiar with its %% >directives, including the ones that control things like spacing and >scaling. So I could fairly quickly and easily write some abc "tunes" >to get manuscript paper. >You might check out some of my samples: >There is a certain amount of silliness to all this, of course, since >it's easy enough to make music manuscript paper with a ruler and pen, >and this might be faster than trying to get a computer to do it. But >that wouldn't be going with the times, y'know. Who would spend 5 >minutes doing a job by hand, when they could spend half an hour or >more wrestling with a computer to do the same job? Sorry, John, I think you're missing the point. The real question actually is: would you spend a cople of minutes to download a programme that will enable you to obtain any blank music paper sheet you weant/need (that, by the way, can be saved for future use) for the rest of your life in a handful of seconds, or rather spend five minutes any time you need a customised blank music paper sheet? I know, for other OS addicts (which - read Unix/Linux - as far as music/audio support are stone age), this might sound as blasphemy, but I guess some some of the newcomers to the abcusers mailing list which are still using Windows (aka Windoze), might profit from Guido and Tab2paper (and a number of freeware other Windows/Windoze programs). In fact, I fear abc newcomers which are Windows/Windoze users and happen to subscribe to the list generally speaking are prompted to unsubscribe fairly quickly, but this is a problem others should be upsetted by... Back to the point, Frank Nordberg in turn wrote: >The sheets at Musica Viva was made with Finale, but, really, any decent >graphics programs should be able to do this work. Just make sure the >lines in each staff is equally spaced (about 2 mm should be fine) and >that there are enough space between the staffs. Nice enough, Frank. I tried the sheets at Musica Viva, butagain, given we might wish to print 'customised' blank music paper, would you consider uploading Guido and Tab2paper, and allow anybody a chance to download them? They are freeware, so I think this would fit with the Musica Viva philopsophy. What more? I wish a VERY HAPPY NEW YEAR to all the abc users. Gianni P.S. And I mean THE REAL abc users - i.e. those which "make a mess of the notation" on other mailing lists, and yet are able to use it "against all odds" as an exchange medium to swap tunes on the web! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Blank music sheets
I wrote: > > Maybe, Windows users might appreciate Guido, a freeware written by Daniel > > Herlitz a few years ago that makes the task very easy. It offers > different > > paper formats. Christophe Declercq replied: > Maybe a few lines of PostScript code is enough. > > Philip Rowe posted it to the abcusers list on 14/05/99 and since that date > I haven't bought a lot of blank music sheets. > > Regards. > > Christophe > > --begin PS code (save it as e.g. blanksheet.ps) > %! Adobe Postscript 1.0 > /stave. (you can look at the email Christophe posted for the rest) Pretty nice, if using an A4 output you are satisified with a 10 staves sheet with: top margin 3 cm, bottom margin 3.5 cm, left margin 1.5 cm. right margin 2 cm! Yes, of course it means as well: top margin 3.5 cm, bottom margin 3 cm, left margin 2 cm, right margin 1.5 cm. Depends on the point of view! Seriously, I talked about CU-STO-MI-ZING! What about 10 staves with top margin=bottom margin= 3 cm. and left margin=right margin= 1.5 cm? Or an 11rather than a 9 stave sheet? Or about grouping the lines by twos, threes, fours...not to tell about the lines thickness... How many other PostScript lines? No. seriously: "some PostScript lines" aren't enough! Not if you really wish to CU-STO-MI-ZE the output, at least! Regards Gianni P.S. I am not going to learn how to write PostScript files, but if anybody cares I will be glad to post any blank music sheet PS file on request...custom made with Guido, of course! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Blank music sheets
John Chambers wrote (about jabbc2ps): One extension I've already made: By making M:none default to no text at all for the meter, and adding a clef=none clause, I can print out pages of manuscript paper with nothing at all on the lines. This is a good fix for a problem that I've seen for some years: Most of the music manuscript paper for sale in stores has lines that are a sort of gray that doesn't copy well. Dunno why manufacturers would do this to us, but it's not a problem any more. I just print out my own. And I can control the staff size, spacing, count, and so on. That's one more commercial product killed off by computer technology. And John Atchley replied: Precisely so that you can't easily copy the blank paper and cut into their sales. Of course, it's none of their concern that it also makes it difficult to copy your work for distribution to the orchestra or what have you. Seems the need of a software to produce blank music paper is a recurring theme! Maybe, Windows users might appreciate Guido, a freeware written by Daniel Herlitz a few years ago that makes the task very easy. It offers different paper formats (A3, A4, A5 and 10cm x 10cm), and the chance to customize almost anything - from the staff height to the number of staves per sheet, margins and lines thickness. You can ever decide to have barlines, although this is an option I haven't find much use for, or to group the staves, which is in fact pretty useful if you are going to write for parts. I don't know if the author has a web site, but I have found a link for the download on an Italian web site: http://members.xoom.it/tablature/links.htm Anybody interested in tablatures for stringed instruments might find use of Tab2paper too! Regards To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] free Finale
Guido Gonzato wrote > One thing for all: > FinaleNotePad does not do PostScript unless you have a PostScript printer. Maybe we should mention that - at least under Windows - you do not need a poscript printer to produce PostScript output (and that's true for EPS as well). 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. Encore users already know this - that's the way Encore used to export to EPS -, but this can be done with any Windows program, even abc2win (especially it, I guess!). 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 forum too - there is some debate about the best poscript printer drivers (I vote for the Adobe Poscript Printers with the Distiller PPD files, that handles colour images and let you define the dimensions of the sheet you are going to print). Regards Gianni To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
