[abcusers] [ABCp] Syntax
I've put on a page (http://abcp.sourceforge.net/abcpsyn.shtml) a very terse description of the syntax ABCp is able to recognize. As always I offer it to your criticism. Feel free to ask what is not clear (I put together the doc on the fly). What I'm really interested in is to understand if I touched all the aspects of ABC or I missed anything. Thansk, Remo. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] tuplet beaming
Bernard Hill wrote: But what's the apostrophe for? And what ascii character is it and how is it produced on keyboards anyway? It's a back quote (ASCII 96) according the 2.0 draft is to be ignored: A`B is equivalent to AB. On Dos/Win platform you can get it with Alt+96 (on the numeric keypad). No idea on Mac. R.D. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Yet another text based Music typesetting program
And if anyone needs it, I've built Windows binaries. Just drop me an email and I'll send them to whoever is interested. R.D. Martin Tarenskeen wrote: But I have built an RPM package on my Linux Redhat FC2 system. After installing it, pmw should be ready to use. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Gscore 0.0.7 released
Sébastien Tricaud wrote: Hi folks, Gscore is a musical score editor. Looks interesting! I'd like to try it, do you have a precompiled Win version? I promise I'll install Scons and GTK library to try compile it myself but I'm sure it won't be in a short time! R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Overlay operator
Ok, I'll try to implement both and ( ... ... ) . Hudson is right, the latter only appears in the abcm2ps docs but Tom gave a good example of how useful it could be. I noticed that Tom used instead of , should I consider and as synonyms? I'll take Phil's suggestion of emetting an error when durations don't match or, if it's not too difficult, I'll try to emit a warning and recover through the insertion of, possibly invisible, rests. Let's see how hard is it. R.D. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Overlay operator
I realized that the overlay operator is the only one that moves the time backward. I think the 2.0 standard is not very clear on this operator, I'll try to summarize how it will implemented in ABCp, of course everything is subject to discussions and comments from your side!! Reading both the standard and the abcm2ps docs I understood the syntax should work as follows: (a=b means a is vertically aligned with b) 1) splits a measure GA | bc de | Fg-- d = b, e = c 2) Duration counts! GA | bc e2 | Fg-- e2 = b 3) overaly may occur on multiple measures G(A | bc d | F)g -- d = A, F = b, g = c but some questions are left unanswered: 1) What is durations don't match? Should we add rests or give an error? GA | b de | Fg-- d =b, e=? 2) The example on the abc2.0 standard page seems to suggest that the operator splits the line and not the measure. I assume the example is from an old proposal and should be read as: (g4 f4 | e6 e2 \ (d8 | c6) c2 ) 3) The abc2.0 standard present it as voice overlay but they do not really defines a separate voice (as the V: field does), correct? 4) What's the meaning of ? I found it in a couple of examples around. 5) Anything else I missed on overlays? Let me know your thoughts. R.D. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [ABCp] Next steps!
Hi there! I think I've reached a critical point in the ABCp development and I'm here (once again) to ask for your comment. The low level interface is almost complete in the sense that further improvements should be determined on a real usage basis and I'm starting to think about the higher level interface. I've added a page on the abcp site (http://abcp.sourceforge.net/table.shtml) that shortly describes the structure that should contain the parsed ABC file to ease further transformation. It's the best visual representation that I've been able to draw, I need to clarify lots of things about it and the only way is to listen to your comments! R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Parts
Wil Macaulay wrote: Yes, I do have a suggestion: if you really want to implement a 'generic parser', start by choosing a standard to implement. If you want to suggest changes to the standard, do so as an independent process. Otherwise you'll end up with a parser that only parses non-standard abc... I've chosen the following approach: - first of all be compliant with 2.0 draft standard, - then include 1.6 standard as long as it does not harm the 2.0 compliancy - than include non standard (but commonly used and/or useful) syntax. For example, the 2.0 standard includes the -8 keyword to transpose an octave down, I've added the -15 and -22 keyword (that are avalaible in other notation packages) and also extended it to other clefs so that treble-8 is recognized (as the 2.0 standard requires) but so does baritone+15! There is one important thing to note here. ABCp is, at the present stage, a scanner, not a parser. This means that, in this case, ABCp reports to the host program that the user specified a clef with TWO octave transposition. It is entirely to the host program to decide if this is acceptable or not! ABCp is an enabler for programmers that want to write software that accept ABC files as input. Using ABCp they can concentrate on the functions of their software instead of losing time to accomodate this or that ABC extension. This concept is very crucial. Let me bore you a little bit with an example:. This is a 2.0 compliant Key: K:Bb mix ^^c_d mezzosoprano transpose=+5 stafflines=3 while this is the same key K:Bb Mix Db C##\ mezzo t5 s3 that makes use of some extensions. As far as the host program is concerned, the two keys above get reported exactly in the same way: [EMAIL PROTECTED] Sf [EMAIL PROTECTED] 053 @ (The string above is a serialized version of the binary representation of the parsed key field.) The host program will use a function like abcKeyTonic() to get Bb and abcKeySemitoneTranspose() to get 5 regardless the way those information are actually represented in the abc file. A function abcError() will report if something went wrong (for example if K:Lmin was encountered). If the host program wants to deal with the string itself, it may well do so using the abcString() function that returns the Key string as it appears in the file. I hope I've been clear enough. Please feel free to comment! BTW. I still have to figure out a clean interface! The functions above (abcKeySemitoneTranspose for example) are so ugly that I'm a little be ashamed to publicly release them! R:D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Parts
Neil Jennings wrote: I still think my suggestion is more general, as it allows the internal part name (one letter) to be totally independent of the displayed text (Part description). Remo's proposal would only allow one word (part name) to start with each letter. Therefore if there was a part Coda, there could not be any other part whose name started with C. (Using letters within a word would get confusing) Well, that's not what I meant. You can have Coda Chorus and Chaos, then you would define in the header P: (Chaos Chorus)2 Coda3 and in the body: P:Chorus P:Chaos P:Coda With my proposal you only miss the ability of having a piece named CHAOS (each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers) but there's no limit in the number of parts that begin with a given letter. It seems to me that if you can give meaningful names to your parts, you gain in clarity : P: (Chaos, Chorus)2 Coda3 gives the feeling of two universal forces (the order being represented by a chorus) that compete each other until the unifying End. Writing P:(AB)2C3 does not gives the same feelings to me! But I digress :) . Anyway, I'll implement also your proposal in my parser. If in the body a P: partname; label field is found, the label will be considered for printing too. Any other suggestion? Bye, R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] Is the list back again?
Oh, well, it seems it has already been fixed! BTW. Thanks for having restored the list Toby! R.D Toby Rider wrote: I'll communicate with the folks at mail-archive and let them know how to get a feed from the list again, now that I've tightened up security and squashed the spam problem (for now). Toby On Thu, 14 Oct 2004, Remo D. wrote: I'm happy to see that the list is back again. The only problem I see now is that the new messages are no longer archived at http://www.mail-archive.com/ Is there any other archive around? R.D. 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 To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Decoration J
Thanks. I'll take as a sinonym for +slide+ then! R.D. John Chambers wrote: Remo D. asks: | I still have to fix parts and continuations with the latest suggestion | but there's something else that I can do very quickly: can anyone tell | me what the decoration J is? In abc2ps, it produces the short diagonal line to the lower left of a note head that means a slide up to the note. It could be useful to have a way to get the other slide symbols. 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] [ABCp] Parts
Neil Jennings wrote: Because the P: text appears above the staff, people have mis-used it to add comments which have nothing to do with parts. In the tune header, it can have a formula such as (AB)2(AC)3 In the body, it must be just a single letter HARMONY can play tunes according to the formula, including nested repeats. Neil Does this mean that my proposal is ok for you? If you have (like the standard says): % Header P:(AB)2C ... % Body P:A P:B It would work. But also it would work if you write: %Header P:(Intro Riff)2 Coda ... % Body P:Intro P:Riff ... As a general rule, my parser tries to accomodate as many synonyms as it can. A simple example is with decorations: !f! is equal to +f+ which is equal to +forte+. R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [ABCp] Alpha version uploaded
I've made some changes and some testing. Everything is far from being stable or even usable but for those that are interested I've uploaded the source on sourceforge.net: http://sourceforge.net/projects/abcp. I've included in the zip file the executable for re2c (as long as the source files) to allow an easy recompilation. I've only tested the compilation on Windows with mingw+msys (gcc) and lcc, simply call config lcc or config mingw before doing make to select the proper compilation option, on Win I plan to test the usual compilers (VC, BCC, Watcom and Digital Mars). In the zip file (bin directory) you will also find abcp.exe that simply shows the events that would have been called together with a packed version of the parsed fields. If you just want to see how the pieces of an ABC get recognized simply call abcp file.abc. Any comment appreciated! R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Line continuation
Hudson Lacerda wrote: It seems that you coded a line continuation similar to those of bash or C That's what I did. Continuation gets reported (a T_CONTINUE event) and the scanner stays in the same state. [V:1] abcde \ [V:2] ABCDE \ [V:1] cdedc [V:2] CDEDC is equivalent to: [V:1] abcde cdedc [V:2] ABCDE CDEDC but not to: [V:1] abcde [V:2] ABCDE [V:1] etc. That's difficult! Neither the 1.6 nor the 2.0 draft mentioned it! :( Do you mean that continuations should be treated as continuation within a voice? I hope not, it really would be difficult to handle. I hope many others will provide their comments about this issue so to reach a consesus on this topic. I intended to solve the issue treating ABC | def |\ M:1/4 gab |] as if it was: ABC | def | [M:1/4] \ gab |] but your example would prevent me to do so! Another case (rare, though) is when the meter is changed very often. That one works good for me, every single element in your example get recognized properly. R:D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [ABCp] Parts
Most of the examples I've examined (thanks again folks!) use a single uppercase letter for denoting each part. P:A in a tune means this is the part 'A' and P:ABACAB at the beginning means, if I understood it correctly, play part A, then B, then C This is what the standards suggest but in one of the Barfly examples, parts are denoted with a more complex syntax: P:Coda for example. I'd like to support it but what should be the exact syntax? My proposal is the following: Each part name MUST begin with a upper case letter and may continue ONLY with lowercase letters and numbers P:AB- play part A then B P:OvertureCoda - play part Overture then part Coda P:OVERTURE CODA - play part O then V, then E, ... P:intro - ERROR Spaces and dots may separate part names. How Barfly behaves? Any other suggestion? R:D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [ABCp] Decoration J
I still have to fix parts and continuations with the latest suggestion but there's something else that I can do very quickly: can anyone tell me what the decoration J is? Tnx. R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Testsuite needed!
Hi! You wrote: I have some real-life files that often causes some software problems, since I tend to notate more chromatic music than most (what ever that means...). I could send you a few, if you'd like... Thanks, I'd appreciate! You could zip and send them to via email. If we you find any problem I'll try to find an FTP space somewhere. Thanks, Remo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] [ABCp] Testsuite needed!
Thanks everyone for the directions on the test files, I've started to collect them and I'll give them a serious look next weekend! Hudson suggestion P.S. Please take in account tuplets with many digits, like (11:8:11CDEFGABcde^f made me think about the needing for a T_ENDNPLET token. In other words from (3ABC four events would be triggered: T_NPLET, T_NOTE; T_NOTE, T_NOTE and T_NPLET. Is that something worth considering? It would ease the parser at the expense of an additional event triggering everytime the tuplet ends. R.D. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [ABCp] Testsuite needed!
Hi there! I'm quiely working on the generic parser for ABC, the lack of news is caused by my very short spare time! I accepted the suggestion about adding another level of parsing. After recognizing, say, a L: field, the a function parses the field and extract the numerator and denominator of the length. The information are stored in a binary packed format and functions (will) exist to access the parsed data more easily (for example: abcKeyTonic(x) or abcVoiceName(x)). This extra step is only performed if needed (i.e. only if one of the above mentioned funcionts are called). Adding the capability of recognizing a new field, a new decoration or a new extrafield should be very simple, most of the time is a matter of adding a string somewhere and recompile. As for speed I've used two techniques: scanners written using re2c (that is reported to be much faster than lex and almost as fast as an hand written scanner) and a perfect hash function that speeds up searching for a specific string (for example pizzicato or tenor). So far the parser can recognize - All the fields (both in the form Y:.. and [Y:...]) - All the extended fields listed by the 2.0 draft plus others like deco or postscript - Optional accidents (for example: (^)F) - Microtones a la abcm2ps: ^3/4F - slurs and ties direction (as abcm2ps again) - Text before or between tunes - extended clefs support: tenor, mezzo, Doh, bass4 and others are recognized - all decorations in the draft plus others like ped , 8va( and 8va), ... In general I've read CMN, Lylypond and MUP manuals to try to incorporate some of their features. Don't be fooled by the descriptions above! Much work is still to be carried out and I really need to throughly test everything before releasing it. I would appreciate if someone could share with me a set of abc file to be used as test suite. I remember someone mentioned the fact he was working on something similar. R.D. P.S. Please, can someone acknowledge this message? I fear the list is still not working properly! To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCp
You're also welcome to use the facilities of the abc.sf.net project. Just let me know and I give everyone involved the necessary permissions... Many thanks, that's a great option! It will give ABCp a high visibility. My next objective is to reach the status of beta from the current state of poc, then we can decide if hosting ABCp directly into abc.sourceforge.net site or having a separate site and an entry page on it. I think what use will we decide to do of the tools sourceforge offers (CVS, mailing list, bug tracker, ...). Thanks again, Remo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCp proof of concept
Any thoughts on using a tool like lex/yacc / flex/bison for parser
generation?
After some research around, I landed on re2c (http://re2c.sourceforge.net)
which is reported to create faster lexical scanners than lex. It uses a
different approach and creates a lexical scanner that has no library
dependencies (as the fl library for flex).
The scanner in the ABCp library (http://www.dentato.com/abcp) has very
simple rules like:
[z] (D | [/])* { RETURN(s,T_REST); }
that, as you might have guessed, matches a rest. The syntax for regular
expressions is a little bit different from similar regex implementation but
once you get used to it it's a breeze!
I found the logical model of re2c much much more simple than lex!
RD
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] I'm embarrassed
I had thought that this was what this list was for. Remo had suggested to me that we initiate a sourceforge list and move discussion of ABCp there so as not to burden this list. I did create the list, but then soon after realized that that would be the worst thing we could do. I soon realized the same and did not insist further more! :) R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABCP - Using from Delphi Pascal
Hi there! I've made no progress on the API. Thanks for the suggestion that a time iterator is needed for sure, but I'm still struggling to put togheter a meaningful API. Even understanding one of the many described on the net it's too much for me in this moment. I've found an interesting technical report with the definition of the music in terms of algebra! No time to study it! You may remember that someone challenged the idea of a general parser raising the objection that it would be useless for programmers not using C or C++ so I created a Windows application that makes use of the ABCp library compiled as a DLL. I found it easy enough to do, but I could be biased. It's made with Borland Delphi 6 (I've got the Personal Edition). If someone has another compiler/language and wants to try using abcp.dll he will be more than welcome!!! Waiting for comments. Remo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCP - Using from Delphi Pascal
Oops! I forgot the link: http://www.dentato.com/abcp To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] Call for an API
I have to admit that I have absolutely no idea on how to shape an API for the parser. I would rather define the API first and then the data structure instead of the other way around, the risk of over-engineering would be too high! Two major operation should be made easy: playing and printing. For playing it seems to me that a temporal iterator is needed. In other words, a way to traverse the structure obtaining all the musical events that happen at a certain time. What about printing? I'm not sure. Anyone with an idea? R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABCp - Proof of concept (2) and Incipit
Hi there! As you may have noticed, I have time to dedicate to this project only during weekends. I would never had enough time to answer to all the email on the list so I prefer to include all the suggestion in the proof of concept. I hope you will have the time of downloading it, see if it matches your expectations and give me your feedback. I've prepared a new version of the POC and added a new page (http://www.dentato.com/abcp/use.htm) describing how to use the parser to create an incipit extractor (guess who gave me the idea). As the rest of the POC it's only for demonstrative purpose but the source code to extract the incipit is oly 62 lines of C code and should serve the point of illustrating possible uses of ABCp. The abovementioned page contains the full list of tokens returned by the parser so far and the status it may be in. It also contain a discussion of ABCp interface as OO classes, a functional API or C handlers. If you look at the Makefile you will discover that now you no longer need Lua to compile abcp.exe. Of course this means that the only use of abcp is to see how abc files are split in small pieces by the parser. I do suggest to use it on known files to see how it behaves. abcpl.exe is the Lua interpreter statically linked with libabcp.lib As usual, waiting for your commets. R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCp proof of concept
Hi there! Thanks for your replays. I try to summarize the points so far (at least my conclusions), please correct me if I'm wrong. 1) To increase portability we should stick to plain ANSI C. I'm perfectly fine with it. The complications I was referring to, Paul, were those that you encounter when you try to access a C++ library from another language (including C). 2) My proposal of using Lua seems to be misleading. Let us put it in a corner for a while we could come back on it at a later stage of development. Tom Satter already offered to write python handlers, which is good for me. This implies that the parser will be a library in ANSI C and that there will exist bindings for different scripting languages. This is a very common situation but requires some planning ahead. 3) The library will keep the state internally. Steven Bennet gave an example about C. In the present stage the scanner will return T_NOTE or T_CHORD together with the C string depending on the context, we need to extend this behaviour to the whole parser. In cases like K:none or K: the parser will not give any error, the callback will be called with something like P_FIELD_K and an empty string. It will be up to the handler to decide if reject it or not. 4) The parser will endorse ONE syntax and will try to accomodate for as many extensions as we can. I can see it's not easy, we have to come up with a solution! Any suggestion? 5) Tom Satter rightly pointed out that we have to choices: having callback that gets called each time an element is found or creating the entire structure and offering an API for navigating into it. I do esitate to do the latter because I've heard of ABC files with thousands of songs in it! I would like to be able ot handle them without requiring megs and megs of memory. The idea in the proposal (please tell me if some point need clarification, consider that english is not my first language) tries to accomodate this situation. It will offer a call back mechanism and a set of default handlers that builds an internal rapresentation of the ABC file. It's not clear to me if you support this approach or not! 6) As Paul Rosen suggested I had a look at MusicXML. I found it very complicated for my taste but I'm not able to judge if all those details are necessary or not. For example, is it necessary to be able to traverse the score both by parts and by measures? I'm not sure I understand, my music background is too limited I think! Has anyone a suggestion on how the ABC file should be represented? 7) I also do agree with Paul not to use commercial parsers, that's why I used re2c for the lexer. My candidate for the parser is lemon, as always I'm open to suggestion. 8) Next proof of concept will feature the parser with callbacks. I'll try to include as much as ABC2.0 draft syntax I can. In the meantime, please comment and give me suggestions. As Christian said, I could fall short of enthusiasm! :) Bye, R.D To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
Re: [abcusers] ABCp proof of concept
Hi Christian. You're right, comments are what I'm looking for. I just want to add to what you said, that the scanner is 100% ANSI C (look at abcpscan.re not at abcpscan.c!). The next big decision to take is if the whole parser should be in C or if I should start using Lua right now. Consider the discussions on the list about T: and K:. If the parser was in C, we had to recompile it to make it accept one (or all) of the proposed semantic, would it be in Lua, one could simply change the script and run the parser again. On the other hand a parser in C would be easier to embed. But we could keep something in Lua and then rewrite in C when everyone agrees on that particual piece of syntax. But if it was in Lua, one could provide a script to transform a file that use a no-longer supported syntax into a file that follows the standards. But should it be an external tool or should be left up to the user? But, .. but... but. There are countless scenarios to consider and evaluate!!! .RD. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] ABCp proof of concept
Hi there. I've prepared a proof of concept. It's only a scanner for ABC files but already features Lua handlers (as well as C handlers). I've also tried to go into details: http://www.dentato.com/abcp/poc.htm but it's hard to be clear and precise without becoming boring! I compiled it on WinXP using both lcc and mingw (just go into the Makefile to uncomment the mingw related macros). As always, comments are welcome. Actually more than welcome! If none is interested I'll refrain to keep posting about it. Just let me know. Bye, .RD. To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] [parser] A proposal
Hi there! Thanks to the ones that answered my last question. In the end I opted for re2c to create the scanner. I've prepared a little bit more detailed description of my ideas for a generic parser. Following Christian Cepel advice the thing has been named ABCp. Please head to http://www.dentato.com/abcp and send me some comment! There is actually only that page (despite the menu on the left). As soon as I finish the proof of concept I'm working on, I'll publish on the same site. Bye. Remo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
[abcusers] On parsers again
A question fortheABC tools programmers around here. Did you hand-code your ABC parser or did you use some standard tool (Lex, re2c, ...)? Bye, Remo.
Re: [abcusers] ABC parser output data structure.
Christian wrote: The core of our abc subsystem (please, someone suggest a name for this thing) could be released as a library (a dll under Win32) that can be I question the idea of it being a .dll... the purpose of this is to be a universal parser for software written in any language, and on any platform. That's why I promote the use of a scripting language. Let me push Lua for a while. Lua is multiplatform. It has been compiled on any Unix flavour I've never heard of, on Palm, Windows, WinCE, Mac, PS2, XBOX, (don't know about Game Cube), this gives a boost about platform independence (both HW and SO). Lua has its native interface with C/C++ but other mechanisms are available: LuaJava, LuaAda, LuaCOM (for MS COM objects) and if someone needs a new interface it can count on the very active Lua community. Lua is widespread in the gaming industry (Grim Fandango, Impossible Creatures, MDK2, Homeworld 2, Escape from Monkey Island, ...) where speed, robustness and ease of use are a must. That's a guarantee for me! Anyway, I said that on Windows it COULD be distributed as a DLL but you are not forced to do so. Since we want to be able to embed ABCp (let's stick with this name for now) in other applications, we have no choice but structuring it as a library that could be linked statically or dinamically to the host application. If the linkage is dinamic, it means a .dll on Windows, a .so on Linux and whatever other mechanism is in place on the targeted platform. The command line tools will access the same libraries, again either statically or dinamically linked. The hard part, IMHO, is that of creating a language-independent interface (or worst, maintain a different interfacing mechanism for each language). Scripting languages as Lua (but also Python and Ruby, to be fair) already solved it . I think we are a bit off topic here with this technical issues, we risk to annoy someone! May I propose to move the technical discussion to the list on sourceforge (I'm going to subscribe right now) and coming back to this list for advice on how internally represent an ABC file, criticisms and other things more abc-ish? Bye, Remo To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
