Re: [abcusers] dynamics
On Fri, 26 Oct 2001 [EMAIL PROTECTED] wrote: Richard Robinson said - Consider the possibility that a separately-maintained ABC library, open-source bug-fixed by anybody that cares to take part, linked into your front-end code, might make your life easier too ? I'm sorry, as a non-VB programmer I don't know how VB links to a C library, but I imagine it must be possible by now. I expect that would be possible but would only give me a passive involvement without the opportunity to take part in bug fixing or adding my own innovations. Adding innovations would involve discussion, certainly. Is that a bad thing ? I thought you were in favour of having standards and against people innovating off their own bat ? I'd have thought an open-source function library would facilitate this rather than hinder it. As for bug-fixing - if you're using functions out of a library in your own code, you will be the first to discover any bugs. They'll bite you, in your development, before they bite any users of the finally-developed result. You have the source so you can see exactly what's going on, know just how that code is interacting with your own, be able to discuss the situation with the library maintainers and find the best solution. And so will anybody else making use of that library, so they'll get the benefit of having bugs fixed that you've spotted, and vice versa. What could be _less_ passive or opportunity-denying than that ? That's more like it! Open documentation would be of much more general use than open source. Open documentation _is_ useful, yes. Very. That's how ABC has got to where it is; people are free to read how it's supposed to work, so they can go off and write code to make it happen like that. Code's useful too. In theory, someone could just read the documentation, and then write their abc in pencil on the back of an envelope, but in practice most of us do use some software from time to time. Laura Conrad said - Several other people are non-voting members by virtue of being on the mailing list by invitation of the members. I would be willing to resign in favor of someone with more enthusiasm for the project than I have at the moment. What on earth gives you the right to turn abc into an exclusive club? We could all do with a standard. This is an attempt to reach one. Laura's trying to help that. It seems unfair and wrong and counterproductive to put people down for trying to do things for us. -- 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] Lynx and ABC
I am trying to figure out how to make MacLynx fire up BarFly for ABC files. The lynx.cfg file says how to set the image viewer, but not other kinds of helper applications. Ideas? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics
I'm probably going to have to provide an abcfix program that attempts to standardize non-compliant abc files. I'd like to see how that handles BarFly output. BarFly doesn't *have* output; it's a text editor, it doesn't enforce any ABC dialect any more than Emacs does. I've used it to write ABC that no version of the program itself could play or print. While I'd like to see a bit more interoperability, I'd be more interested in functionality - there are still lots of musical features that could be fitted into ABC without drastic upheaval but which no ABC implementation yet does right. There is no way ABC is going to take off in any genres beyond those it's got to already unless some extensions are made available; why should users with divergent specialist needs (rehearsal marks, editorial annotations, microtonality, lead sheets, text in two-byte character sets...) have to wait until *every* application implements them? One problem with using a common library: turnaround time for bugfixes. Some of the most-used ABC applications out there get updated no more than yearly, others get fixed within days of having a bug reported. If a bug is discovered in a library, this adds a new source of delay; the library maintainer will need to work fast to keep up with the quickest application developers. For some specialized library functions the open-source model might not help all that much as there might only be one developer in the group who understands what the code is supposed to do. On the other hand, a common specification (a real one, rather than the handwaving in the current documents or purely syntactic stuff like Henrik's BNF) would benefit everybody without introducing new problems like this. What formalisms would all the developers find readable? === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Software libraries
On Fri 26 Oct 2001 at 03:50PM +0100, Jack Campin wrote: One problem with using a common library: turnaround time for bugfixes. Some of the most-used ABC applications out there get updated no more than yearly, others get fixed within days of having a bug reported. If a bug is discovered in a library, this adds a new source of delay; the library maintainer will need to work fast to keep up with the quickest application developers. For some specialized library functions the open-source model might not help all that much as there might only be one developer in the group who understands what the code is supposed to do. I agree that there is not really much point in making your code open-source if no-one else can read it. Good software should be organized so that you can fix parts of it without understanding the whole lot. Once a library bug has been identified, I expect that rapid-updating developers will fix it themselves rather than wait for the official bugfix to filter through. James Allwright To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (again)
Jack Campin said - BarFly doesn't *have* output; it's a text editor, it doesn't enforce any ABC dialect any more than Emacs does. Don't text editors have output? I am not a Mac user so I have no direct experience of the nature of BarFly, but I do know that a number of people have posted tunes in abc generated by using BarFly. From where I'm standing these are BarFly output. They appear to have various characteristics which make them incompatible with the abc software available to me. Do these not arise from the use of BarFly, or is it just that all BarFly users are working to a different definition of the abc standard? On the other hand, a common specification (a real one, rather than the handwaving in the current documents or purely syntactic stuff like Henrik's BNF) would benefit everybody without introducing new problems like this. What formalisms would all the developers find readable? Excellent! Keep pushing at that idea. Bryan Creer
Re: [abcusers] dynamics (again)
[EMAIL PROTECTED] wrote: I am not a Mac user so I have no direct experience of the nature of BarFly, but I do know that a number of people have posted tunes in abc generated by using BarFly. From where I'm standing these are BarFly output. They appear to have various characteristics which make them incompatible with the abc software available to me. Do these not arise from the use of BarFly, or is it just that all BarFly users are working to a different definition of the abc standard? BarFly follows the standard (ABC 1.6) pretty well, but all abc applications differs when it comes to various extensions. abc2ps seems to be the dominating application here in the abcusers community (though not necessarily among abc-users in general!) so people tend to regard that program's use of extensions as the standard. Frank Nordberg http://www.musicaviva.com To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (again)
BarFly doesn't *have* output; it's a text editor, it doesn't enforce any ABC dialect any more than Emacs does. Don't text editors have output? I am not a Mac user so I have no direct experience of the nature o BarFly, but I do know that a number of people have posted tunes in abc generated by using BarFly. From where I'm standing these are BarFly output. They appear to have various characteristics which make them incompatible with the abc software available to me. Do these not arise from the use of BarFly, or is it just that all BarFly users are working to a different definition of the abc standard? Programs like abc2win only let you output ABC they can interpret. BarFly lets you write any text you want and never modifies it without you asking it to. There's a built-in incentive to write stuff that BarFly can print or play, but no more than that. Quite a bit of the stuff in the modes tutorial on my website gives horrible staff-notation output when BarFly typesets it; I regarded source legibility as more important. You could use it as a C++ programming editor if you wanted to. I've occasionally written email messages with it before copying them to my mail client. I have stacks of poems and bibliographic references originally copied with it. When I'm using a laptop with very limited memory it helps if I can work with only one text-editing application running and have it do the whole job. I don't expect it to make musical sense of a letter describing an 18th century riot. I don't confine myself to the subset of ABC it implements; if I need a feature in ABC to represent a piece of music in front of me I'll invent it and let the programmers catch up when they can. This is part of ABC's inheritance from similar paper notations - the user is in control - and it's something that shouldn't be lost. Given the basic idea of ABC - that it's tunes notated in text files which may contain other material - no more restrictive attitude makes sense. If the other material in a tune file can be any text, that text can be an arbitrarily close approximation to valid ABC. It's fine for an application to report that it can't figure such stuff out, or to say that it doesn't meet some agreed standard, but that doesn't mean it shouldn't be there. === http://www.purr.demon.co.uk/jack/ === To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] dynamics (again)
Funny how a thread subject can drift so far from the original and yet still remain appropriate. Frank Nordberg said - BarFly follows the standard (ABC 1.6) pretty well, but all abc applications differs when it comes to various extensions. Yes, I think it does. (If it's only a text editor why does it need to conform to an abc standard?). However, it is the extensions, which hold the future of abc, that are important. If each implemetation follows its own path then abc will fragment and be the poorer for it. You have been known to post separate versions of tunes for BarFly and the rest. abc2ps seems to be the dominating application here in the abcusers community (though not necessarily among abc-users in general!) so people tend to regard that program's use of extensions as the "standard". That is precisely what I am trying to argue against. This is the abcusers' list, not the abc2ps users' list. One software implementation should not be allowed to dominate the standard. Phil Taylor (BarFly), Laurie Griffiths (Muse) and my humble self (abc2nwc) are active participants in this list and one person (who used to be high profile but doesn't seem to have been heard of for a while) even argued that compatibility with abc2win was the main criterion for new extensions. Jim Vint (abc2win) doesn't participate in the debate but given the bad press he gets here, who can blame him. Bryan Creer
