> >>> I was thinking that the output would be a C struct, which should be >>> readable >>> by any language. I'd like some input about limitations in >>> your favorite >>> language. Linkage is an issue, too. I'm most familar >>> with C++ and Windows, so >>> I need to avoid my natural instinct here. > << > > I'd be against that. The output should be a structured ascii file with > keywords > and in this case it is simplicity itself to add features and > create readers which will still read future versions of the program > output. > > I've given examples in a previous contribution.
>>The trouble with ascii output is that it's slow to generate, takes up a lot of disk space or memory, << Well my current version of Music Publisher can save files in its own (proprietory) binary file; or as ascii. I can' tell the difference in speed either reading or writing and I typically run an older system working at 800MHz. As to size, it certainly is 4-10 times as large but the advantages are far outweighed by the compatibility issues which occur as the data fields inevitably expand. >>and slow to reas it has to be parsed again. << See above. >>(Also if you're going to use an ascii file you might as well use MusicXML, which can >>express everything in abc (apart from the Hp key sig)<< I'm not against MHML, just that it contains much more than we need. >>Using a C struct would be fine by me, since I use Pascal, and C structs are directly >>equivalent to Pascal records. Linking to C code is no problem either, as in the >>Metrowerks development system I use the C and Pascal compilers are just front ends >>to a common code generator, and as long as you keep them in different files you can >>mix and match the two languages. Linking to C++ is a bit more difficult (something >>to do with "name mangling" or somesuch) and you have to write some glue code in C, but that's not too difficult. Other problems you may encounter are to do with endianness and the availability of floating point formats on different processors. As long as you don't make any assumptions about the order of bytes within a number and avoid using real numbers (or at least stick to the common float types) it shouldn't cause too much trouble. << The format doesn't worry me. But the expandability does. A simpler structured ascii format is far better than abc or any fixed binary format. But what they heck, I don't care much anyway: Music Publisher 5 supports a subset of natural abc anyway and it's not really aimed at the abc user anyway so if the format is too much trouble I won't use it. It just seems crazy to me to use any binary format in these days of large and fast storage; fast processors and particularly in a multi-platform format. I was simply offering advice. Bernard Hill Braeburn Software To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
