> My parser will be using the non-graphic parts of Cocoa & GNUStep, so it > should be highly portable.
> The printing code I'm writing, on the other hand, will necessarily use > graphics, but I'm hoping it will work on most (and maybe all) systems. On > the Mac, at least, it will output PDF natively - I'm not sure on the other > platforms what the output will be yet. Why not XML instead of direct printing, and reduce the graphics problem to one of generating PDF from XML? - such tools are bound to be created anyway. Some of the suggestions here seem to assume that ABC will only be used as the input to a series of filters. That doesn't fit some patterns of usage. For a start, it doesn't fit with what a structure editor does. And presently, just about any ABC user can store all the ABC ever typed in by anyone on their own machine, and disk sizes are expanding much faster than the ABC corpus, so it's likely to remain the case that anyone can hold a copy of all the ABC every made publicly available. It's time to stop thinking in units of individual tunes, tune files, or even tune sites: the only reasonable unit is the entire corpus. The corpus is already a small, ad hoc distributed/replicated/federated database - there are multiple near-complete archives around - and any new parser has to help that work more effectively. (Some numbers. There are no more than 50,000 Scottish-traditional-idiom tunes in existence. Making some deliberate overestimates, assume 50 different versions of each have been coded and that Scottish music is 1% of what's been put into ABC. At 1K per tune that's still only a third of a CD; on a fast broadband link you wouldn't have time to go for a pee before the download finished). So operations on large-scale ABC databases are likely to become more important - things like: - storing the tunes in a database, parsing and indexing them at entry time - distributed versioning, so that an ABC creator could get forwarding pointers or editing commands inserted into superseded copies of tunes - plagiarism search (assume the entire Harry Fox Agency database) - mending corrupt tunes by finding better versions of garbled parts - collating information from all copies of a tune, so you could unify the discography from one copy with the detailed formatting code from another - indexing the corpus of tunes by harmonic progression, as calculated by something like ABCMus's auto-harmonizer, and allowing fuzzy search All of that would be easier if persistent parse trees were available. It's a pity the Tune Finder doesn't yet have options to download everything it knows about or synchronize your own mirror with it. In the long run this might be *less* resource-intensive than what it's presently doing, as complete downloads could be offloaded onto mirror sites and intelligent synchronization of updates doesn't need to be any more expensive than search. ----------------------------------------------------------------------------- Jack Campin: 11 Third Street, Newtongrange, Midlothian EH22 4PU; 0131 6604760 <http://www.purr.demon.co.uk/jack> * food intolerance data & recipes, Mac logic fonts, Scots traditional music files, and my CD-ROM "Embro, Embro". ------> off-list mail to "j-c" rather than "abc" at this site, please <------ To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
