[abcusers] Repeats
John Chambers wrote - There's no way any of you can stop me from using my own code. Wouldn't dream of it old chap. We seem to have completely different ideas of what a standard means. You seem to think it's to stop people doing things. I think it's to enable people to do things. More specifically, to enable different people to do the same things in the same way. If you don't like it, you don't have to use my code or my abc files. And if you do like it, you're welcome to both. I would like to use your abc files but excuse me if I'd rather not use your code. I'm sure it's excellent but it would not be very practical for me to include it in my Visual Basic programmes. What I do want to do is use your specification of the repeat endings since it would seem sensible to implement the idea in a compatible way. It would be nice to know that other developers were doing the same thing. As it happens, I can because you are very generous in sharing your ideas on the list and I thank you for it. I was on the list when you last discussed it so I know about it but it is evident from recent postings that some people do not. Would it be so terrible for the information to be held in some central location under a general abc umbrella independant of any particular software development? If you don't want to call it a standard then think of another name. No developer would have to obey it if they didn't want to; that would be between them and their users. Meanwhile, programmers build things that work, users start using them, Yep, just like Jim Vint did with abc2win which, for some reason, seems to irritate you enormously. Does it mean that I can include anything I like in the combined editor/printer/player I'm working on and if anyone doesn't like it Nyah, Nyah! So there! ;-) ? Bryan Creer (And, of course, if I put my MCP logo on the website, I can lay claim to the whole of abc on behalf of Microsoft-axis-of-evil.) To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Repeats
Bryan Creer writes: | John Chambers wrote - | There's no way any of you can stop me from using my own code. | | Wouldn't dream of it old chap. We seem to have completely different ideas of | what a standard means. You seem to think it's to stop people doing things. | I think it's to enable people to do things. More specifically, to enable | different people to do the same things in the same way. Well, in practice it tends to do both. Standards are good mostly if they can specify a practical minimum that turns out to be useful for a large set of people. The ANSI C and POSIX standards are two good examples. They can also be dead ends that block innovation. This is one of the reasons that the committee approach (design the spec first, then implement it) turns out to not work so often. It's easy to end up with a spec that can't be implemented correctly, and/or turns out to be not quite what people need. There's a set of good (i.e., bad) examples in the POSIX spec, in the form of functions such as gets() which turn out in retrospect to have been major errors. But you have to implement them if you want certification, and then try to teach programmers to not use them. Standards are classical examples of a double-edged sword. One thing that helps a lot is the general rule Anything not in the standard is optional. Programs can ignore such things, but they should not reject them. This was pretty much what Chris said with abc, and it's a good guideline. If we haven't decided on something, we just say that it's not specified. This encourages developers to try ideas, present them to users, and see what turns out to be most useful. | I would like to use your abc files but excuse me if I'd rather not use your | code. I'm sure it's excellent but it would not be very practical for me to | include it in my Visual Basic programmes. Yeah; you might have a few problems getting it to compile. | What I do want to do is use your | specification of the repeat endings since it would seem sensible to implement | the idea in a compatible way. It would be nice to know that other developers | were doing the same thing. As it happens, I can because you are very | generous in sharing your ideas on the list and I thank you for it. I was on | the list when you last discussed it so I know about it but it is evident from | recent postings that some people do not. Would it be so terrible for the | information to be held in some central location under a general abc umbrella | independant of any particular software development? I'd sorta hoped that some of my earlier proposals would end up in some sort of standard. They do seem to have just quietly disappeared, as have others' suggestions, though I suppose they're off in some archives. I probably also have some copies lying about, in the form of docs for what I've implemented. Maybe I should repost them. Of course, I have a few new ideas since then ... | If you don't want to | call it a standard then think of another name. No developer would have to | obey it if they didn't want to; that would be between them and their users. A term like proposed standard might work. I tend to use extension, since nothing I've done is standardized. | Meanwhile, programmers build things that work, users start using them, | | Yep, just like Jim Vint did with abc2win which, for some reason, seems to | irritate you enormously. Actually, I've commented several times that I thought that using end of line as end of staff wasn't a very good idea, and an explicit end-of-staff token would be a better idea. But that's not what was done, unfortunately. If it were a really big deal, I'd be arguing for changing everything to match abc2win. But it's really just a small deal, and it would be much better if we all implemented the (slightly inferior) standard. The only real problem with the standard way of indicating end-of-staff is the grief caused by the idiots who put line wrapping into email. This is an ongoing nightmare, not just for abc, but for programmers in any of the many languages that treat the end of a line as the end of a command. The right solution would be to start a campaign of assassination of those programmers. Publicise it so that other programmers wouldn't make the same mistake. (Perhaps we could hire Osame bin Laden to organize this task. Then he'd be socially useful.) | Does it mean that I can include anything I like in the combined | editor/printer/player I'm working on and if anyone doesn't like it Nyah, | Nyah! So there! ;-) ? Well, of course, you can. And if it's useful to a lot of people, we can get a campaign going to standardize it. If not, we'll campaign to make you an outcast. ;-) | (And, of course, if I put my MCP logo on the website, I can lay claim to the | whole of abc on behalf of Microsoft-axis-of-evil.) Careful there. If you do that, you had better stop talking to
Re: [abcusers] Repeats
John, As a software developer in the electronic design automation (EDA) industry, with way more experience with standards definition and application than I ever wanted to have, I appreciate all concerns that have been voiced on this list about standardization. At the same time, the great thing about abc is that its use has been standardized enough that it has become an incredibly valuable channel of communication for music of all sorts. So on balance, I think the value of standardization outweighs the value of flexibility and freedom to change the notation in arbitrary ways - just as standards in the EDA industry have fueled the massive productivity explosion of the last decade (bringing you all those digital electronic playtoys for creating and playing abc files on ...). In EDA, the tension between the the inflexibility of standards vs. the chaos of proprietary tools has led to significant interest in Open Source software development, where the code is freely available, many people contribute to its development, but integration of those contributions is often controlled carefully by a small governing body responsible for the product, to ensure consistency and integrity. As I listen to the (mostly friendly) debate among several authors of abc software on this list, I keep thinking that an Open Source abc composer/player/printer tool would be appropriate. You even mentioned Open Source twice in your last posting, but didn't comment on the possibility of Open Source abc software development. It seems to me that you all have a lot of great ideas, as well as a lot of strong individual preferences, and perhaps even some animosities I don't understand - but that together you could create an integrated, 'standard' Open Source abc processor that could be better than any of the existing abc tools. You might start with the source code of any of the existing tools, and work together to extend it to merge in features of other tools. You who are developers of existing tools would be the appropriate set of people to govern integration of newly contributed features. And as with most open source software, this 'standard' abc processor would most likely be ported rapidly to all platforms anyone would ever want to use abc on. (Eventually I'll expect to see a Java version of this tool running on my toaster, so I can program the tune it plays when the toast is done...) So please pardon my intrusion (I'll go back to lurking now), but I'd be very interested in hearing you all discuss the possibility of an Open Source abc development effort. Are there any reasons why you wouldn't consider this? Has it been tried before? Is there no way it could be successful? What would it take to get such an effort started? Regards, Erich on 4/18/02 3:05 PM, John Chambers at [EMAIL PROTECTED] wrote: ... Careful there. If you do that, you had better stop talking to the rest of us. There are a lot of people using non-Microsoft systems here. Some of us even use (gasp!) Open Source software. If you tell us anything about what your code does or how it works, you could be prosecuted. Go read your license. Or better, give it to an IP lawyer and have him explain it to you. (Note that that does't end with a ;-). It's not funny. There's a very real possibility that communication between Microsoft developers and other programmers will soon be illegal in the USA. Of course, some Open Source developers would tell that this might be a Good Thing. And some Sun, Palm and Sony developers ... To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] header.tex
Jean-Charles writes:
I've got some hard times with the header configuration, (displaying some
differents fields). Could someone send me an educational header.tex file,
or its own one ?
I'll send one off-list, but there are a couple of comments of
(slightly) more general interest to make, and it's a good excuse to
insinuate some pleas that someone think about cloning abc2mtex.
There is a limitation on header fields you can use---abc2mtex
keeps track of some, but not all, of them. As far as I can tell, it
records X, T, (and a couple of secondary titles, Ta and Tb) S, A, C, N, P,
and W. You can use any of these from header.tex (or other included file)
or even directly in the abc, by e.g. \Sstring. (See the header.tex file.)
But you can't use R or Z, for instance.
It might be a matter of just changing a couple of lines in the
program to make more fields available. But then...it might take more.
Does anybody know?
In a later email:
I don't know wether Daniel Taupin version of MusiXTeX is known as
Andreas Eaglers' in index.tex and then I don't know if I have to
uncomment the lines (thought it seems to be better not to uncomment : it
can't find musixsig.tex and I gess it should have been in my
/usr/share/texmf/tex/generic/musixtex directory).
I also wonder if musixtex installation is allright (tough it's from a
rpm package) because i've got many problems :
music isn't right justified, though it should be with musiXtex ;
Q:3/8=120 is printed8th note = 3 ;
Perhaps you mean header.tex instead of index.tex? There are two
versions of MusixTeX, one by Andreas Egler, and the other by Daniel
Taupin. You evidently have Taupin's version---so don't uncomment the
lines.
For right justification: did you tex it twice? You have to tex it
once, then run musixflx, then tex it again. It *should* come out
well-spaced and justified. (N.B. best remove the *.mx* files before doing
this---musixtex is likely to get confused between the old and new ones if
you don't, but not nearly as confused as you'll be when you try to make
sense of the resulting error messages...)
I think the 3/8=120 problem is a just bug in abc2mtex--again, probably
easy to fixfor someone to whom such things are easy...
(Which is not me---my shaky knowledge of C---or any other
programming language---doesn't extend to reading other people's code.
But if anybody would care to figure out what does what in abc2mtex, I'd be
very happy to help with the MuxiXTeX side of it.)
Here's an ugly workaround for it. In your abc file, delete the Q:
field entirely, and, right after the K: field: type a bar line (|), and,
alone on a new line, type \notes\Uptext{\metron{\qup}{120}}\enotes.
Then start the abc on the following line. (You'll have to experiment---I
found I had to type some abc first, or else the metronome marking would
show up below the staff (!) and the barline seemed fairly innocuous. As I
said, it's ugly. Of course, you can leave the Q: line in, search for
\metron in the music.tex file that abc2mtex generates, and just replace
replace \qu or \cu with \qup. This'll give you the output you
expect.)
Cheers,
John Walsh
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
