I'd have to opt for the second option. Where myTune is a C struct and
it gets passed through to all the relevant apis. This sort of interface
can be made to be very OO and is trivially easy to wrap in an OO wrapper
for say C++ or Python etc. That seems to provide for maximim flexability.
Someone stated that using ANSI C would be best but that we would
definitely want to use the object oriented extensions to make it object
oriented C (not C++)... Perhaps that is ANSI C today... I dunno... I
haven't programed in C for 5 years and perhaps ANSI has certified an
updated C spec to
Chuck Boody writes:
I find that I frequently could use an index of an abc file (or set of
files) that contains title followed by the first few bars (say 2-4).
This would be invaluable for those situations where everyone remembers
the title but not how it starts and for other such situations.
On 25 Aug 2004, at 22:47, Chuck Boody wrote:
Greetings,
I find that I frequently could use an index of an abc file (or set of
files) that contains title followed by the first few bars (say 2-4).
This would be invaluable for those situations where everyone remembers
the title but not how it
Displaying the first n bars would be my preference. It is a feature I
would certainly use (and would save me having to generate such things by
hand). Um, how hard would it then be to export this index of incipits to
abcm2ps?
Tom
On Thu, 26 Aug 2004, Phil Taylor wrote:
An index of incipits. It
First n bars would be the way to go. The layout of the title and
incipit should be horozontal though, and not title above incipit.
I also wonder if you might be able to set up an interface to abc2mtex
similar to the abcm2ps. John Walsh suggested abc2mtex has the indexing
feature and maybe
I recently read about the ability to index tunes in one or
more abc files using ABCMUS. Unfortunately, I have been
unable to do so. Would some kind individual reply (maybe by
private e-mail) with some simple directions about how to
index the tunes contained in a single abc file. If I can
get
