Re: [abcusers] chords writing in abc/little V: comment
John Chambers wrote: Bryan Creer hath writ: | I can see that we're going to end up having to write smart software | which can figure out the right answer from anything which looks like abc. | | Or, alternatively, we can all work to the same standard and save ourselves a | lot of trouble. Fat chance. Even if we try that, experience so far has shown that there are serious incompatibilities possible between two programs that follow the standard. This is inevitable in any standard that's written in English, which is hopelessly ambiguous. Lawyers have been trying for centuries to develop a clear, unambiguous English subset, and their general failure is shown by the huge number of cases in which the courts have to decide what a law means. True. An additional problem is one which you yourself pointed out recently: users often write abc which is intended to be read only by human readers. In other words they are treating abc as a natural language. In this context any variation on abc syntax is OK as long as it's obvious what is meant. I've always been in two minds as to what programmers should do about this. Coping with all the possible variations of syntax whose meaning is obvious is an interesting programming challenge. On the other hand, to allow too many variations is to contribute to the deterioration of the language. Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc/little V: comment
Phil Taylor said - The standard is abc v1.6. There's also a proposed draft standard which is still under discussion. Neither of them even mentions multivoice abc. Does that mean that nobody is allowed to post tunes which use the V: field to this group, which is devoted to the discussion of the abc language? Read your own postings Phil. A couple of days ago you said - 1. Anything but the most simple extension needs some experimentation to find out what works. You've got to do it first, then try it out with a lot of music to see if it's a good idea. 2. If we had to wait for agreement nothing would ever get done. The draft standard doesn't consist of proposals it consists of extensions that someone has already implemented and they aren't being discussed. They, and other extensions such as middle= and the various versions of V:, are already in the public domain and are being used. Are you prepared to say that if a vote was taken that went against one of your favourite new developments you would be willing to withdraw it? Or that if a proposal such as, for example, the !symbol! notation was adopted into the standard you would be happy to incorperate it into BarFly? John Chambers said - Fat chance. Even if we try that, experience so far has shown that there are serious incompatibilities possible between two programs that follow the "standard". ...and a great deal more beside. So because we can't make it perfect we shouldn't try to make it better? The new, more formal standard will presumably fix a lot of this sort of problem, Er? From whence does this come? Did you read Laura Conrad's posting? Programmers will implement subsets for the sort of music that they know. That isn't a problem for anyone except themselves and the users of that particular software. The problem that concerns me is extensions beyond the standard which make tunes inaccessible to all but the software that was used to produce them, especially if, as in the case of V:, there are several incompatible versions. abc could be a top class act. All it takes is goodwill but, as Laura's gratifyingly honest description of the achievements of the standards committee shows, that seems to be somewhat lacking. Bryan Creer
[abcusers] C Compilers (was linux only ?)
My favourite would be DJGPP: http://www.delorie.com/ which is a port of GCC and comes with lots of useful tools. If you want something that with fit on a single disk, I would suggest trying Pacific C http://www.htsoft.com/products/pacific.html Both of these will run under Windows, but don't have any special support for it. If you want that, you might try MINGW, which is a port of DJGPP: http://www.mingw.org/ Cheers, James Allwright On Mon 09 Jul 2001 at 10:26AM +0100, flos wrote: Right, where do I get a C compiler for Windows 98 SE? Flos 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
[abcusers] barlines at the beginning of a staff
At the other end of the staff, I've received several messages from people complaining about some of my files that put a bar line at the start of the staff. They insist that this is illegal. It isn't, of course, and is in fact common practice in some musical circles (mostly those who also write partial measures at the end of a staff). The problem is not just that the barlines are at the start of a line. That would just be a stylistic preference, albeit an irritating one. What you do very often in your files is write two consecutive barlines with no music in between them; one at the end of a line and one at the beginning of the next line. I don't care whether it is legal, it's a timewasting pain in the arse that makes BarFly's (and probably Bryan Creer's) error checking utilities gag - if you say your tune is in 4/4, 0/4 is not a legitimate bar length. I have to edit this out before re-running the error checker to look for more significant problems. Support for error checkers is not mandated by the ABC standard, but making it impossible to use them is not going to do anything to help get ABC accepted or to improve the quality of the ABC corpus. Putting a barline at every point where *you* want the start of a line to be also makes it gratuitously difficult for your users to choose a different layout, either because they want a different note density than you or because they want to switch between portrait and landscape. There are *some* pieces where a specific layout is hard to avoid, but for the ordinary one-voice tunes that make up the bulk of the ABC on the web (and the bulk of what's on your site) there's no earthly need to hardwire this in. (I need to print some tunes for children in the next few months; the notation will have to be much less dense than the norm for ABC printing applications). I have sometimes seen ABC2WIN files where a linefeed occurs between the two strokes of a double bar. How is a buggy-ABC-fixer supposed to tell that isn't what you did? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] linux only ?
flos == flos [EMAIL PROTECTED] writes: flos Right, where do I get a C compiler for Windows 98 SE? Try http://www.cygwin.com -- Laura (mailto:[EMAIL PROTECTED] , http://www.laymusic.org/ ) (617) 661-8097 fax: (801) 365-6574 233 Broadway, Cambridge, MA 02139 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc sources compiling
Thanks to everyone who give some good advices for displaying multible voices on one staff. The command %%staves 1 (2 3) worked well with abcm2ps. I thought I could be good to propose new features in the abc format, for example, in the brackets for the chords [], we could have symbolised different levels with subdivisions of [] or (). But this would not preserve compatibility with older software. ex : V:2 [G2e2] [ce] [B2g2] [Af] | [A2e2][ce] [G3d3] :| V:3 CB,C G,2 D | A,B,C G,3 :| || || || \ / \/ V:2 [G2e2[CB,]] [ce[C]] [B2g2G,2] [AfD] | [A2e2[A,B,]][ceC] [G3d3G,3] :| So I guess the future improvements of ABC should be with commands such as %%staves 1 (2 3 4) etc., which begin with %% that are not annoying for older softwares. The problem with those commands is that there is still no official standard yet. It could be good to have an ABC draft with the most common ones (like !trill! or !fine!, but for the improvements in such programs like abc2ps or yaps). To be honest, I had not tryied in deep abcm2ps because I thought the rendering was not better than abc2ps, but if it has some nice features, I'll cast a second glance on it. Concerning the problem of (homemade) compiled c-sources, programmers should admit that it is not easy for people new in computers to make it self (it's not a criticism, I need the good work of programmers, because I know so little on programming). The advantage with unix (and unlike Window$) is that it stimulates the user to make him think and improve his knowledge. I've tryied linux, but still can't throw away windo$$$s (unfortunatly), and I use abc on windows right now. That's right, in order to use ABC correctly, one have to download ghostscrip, ghostview, and even a TeX package. I wanted to try Abcm2ps, so I downloaded cygwin, and it was quite easy (and rather fun :) ) to compile the source code, but I guess the average computer user can't do all that. Christophe Declercq spoke about uploding on a website a binary version of Abcm2ps, I can do that on my own website. I have the one I compiled, but since I used cygwin, one need cygwin1.dll in order to make it work. IS THERE a special command, during the compilation, in cygwin that could include this dll in the binary ? I've tryed to compile the source with Borland Bcc (free) compiler, but still don't have the necessary knowledge for that, so Christophe could send me his binary as well. I could add a batch file and explainations to help people using this without problem. Greetings. Eric. http://anamnese.online.fr/abc/ (updated 7/10/2001) ps : Til Frank Nordberg : By coincidence I visited your site earlier today and have to say your work is really admireable :-) Tusen takk, i like maate : Jeg har besökt hjemmesiden din ogsaa i fjor, og funnet mange gode laater aa laste ned der. ___ Do You Yahoo!? -- Pour faire vos courses sur le Net, Yahoo! Shopping : http://fr.shopping.yahoo.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] chords writing in abc/little V: comment
On Tue, 10 Jul 2001, John Chambers wrote: Modern GUIs are very well designed, for people with three hands. The real problem has been how slow customers have been to make necessary hardware upgrades to meet the requirements of the software. Quite ;-) -- Richard Robinson The whole plan hinged upon the natural curiosity of potatoes - S. Lem To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Three-handed job.
Richard Robinson wrote: On Tue, 10 Jul 2001, John Chambers wrote: Modern GUIs are very well designed, for people with three hands. The real problem has been how slow customers have been to make necessary hardware upgrades to meet the requirements of the software. Quite ;-) You might be interested in the following quote from Apple: We've done a cool $50 million of R D on the Apple Human Interface. We discovered, among other things, two pertinent facts: Test subjects consistently report that keyboarding is faster than mousing. The stopwatch consistently proves mousing is faster than keyboarding. This contradiction between user-experience and reality apparently forms the basis for many user/developers' belief that the keyboard is faster. People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement. It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist. While the keyboard users in this case feel as though they have gained two seconds over the mouse users, the opposite is really the case. Because while the keyboard users have been engaged in a process so fascinating that they have experienced amnesia, the mouse users have been so disengaged that they have been able to continue thinking about the task they are trying to accomplish. They have not had to set their task aside to think about or remember abstract symbols. Hence, users achieve a significant productivity increase with the mouse in spite of their subjective experience. -- (Not wanting to start a GUI vs CLI war or anything - just thought you might find it interesting.) Phil Taylor To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
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 on the
