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
Steven Bennett wrote:
I was going to let this idea die quietly... sigh
If we were talking about creating a data interchange format, I'd agree 100%.
But we're talking about creating a general purpose front-end parser that can
be linked into assorted ABC programs so they don't have to write their
On Wednesday, July 28, 2004, at 03:43 pm, Bernard wrote:
[snip]
The maximum is ascii. You can even read it without a computer.
Flexibility is maximum in ascii. A new keyword is added and the old
software doesn't understand the keyword and will ignore it. The
problem of upgrading software is old
That's what I was thinking. Unfortunately, I probably won't have a moment of
free time until Sunday evening.
umm - perhaps the best approach, then, would be to write the abc parser
front end as part of the libmusicxml project. Then you can take
advantage of their work...
wil
Paul Rosen
I've been poking around the web a little bit and I came upon
http://libmusicxml.sourceforge.net/
This is an open source project that I think is really similar to what we're
thinking about, except that it is written for MusicXML.
If we use the same structure that they've used, then any package
In message [EMAIL PROTECTED], John Chambers
[EMAIL PROTECTED] writes
I hope you've found the FreeTTS project.
Yes. Although we haven't tested it yet for various reasons.
Stephen
--
Stephen Kellett
Object Media Limitedhttp://www.objmedia.demon.co.uk
RSI Information:
My concept of a parser is totally different. It's a standalone program
which takes one file and converts to another, more
generally usable. It would be called invisibly by any program needing it.
That program would then read the simpler file in
an obvious form and presumably delete it.
I call
On 30 Jul 2004, at 13:34, John Chambers wrote:
| In message [EMAIL PROTECTED], John Chambers
| [EMAIL PROTECTED] writes
| I hope you've found the FreeTTS project.
|
| Yes. Although we haven't tested it yet for various reasons.
And, to make it relevant to this group, you'll have to start a
easily, as is of course the parsing since this is very easy to write. (for
information it's www.visiv.co.uk and the author
provides documentation for the ascii file structure on the web site).
I looked at the web site and checked out the format. It is not exactly the
information we have to
To add my two cents to this discussion: While I have my doubts that any
single parser design could fit the needs of more than maybe half (being
generous) of the possible applications out there, it's still a worthwhile
project.
What projects are there? My imagination leads me to the
Paul Rosen wrote:
What projects are there? My imagination leads me to the following. I'd love
to know how else ABC could be used.
Standard Notation
Tablature
MIDI Player
Transposer
Indexer
Pattern Matcher
Conversion to another format
Instruction (probably needing fragments)
The
Bernard wrote (portions snipped):
I disagree entirely on the maximise portability. The maximum is ascii. You
can even read it without a computer.
...
Sorry, but it seems archaic to me (in a situation such as we are talking
about) not to write the file in ascii.
First off, we're talking
easily, as is of course the parsing since this is very easy to write. (for
information it's www.visiv.co.uk and the author
provides documentation for the ascii file structure on the web site).
I looked at the web site and checked out the format. It is not exactly the information
we have to
This is not a big deal. Actually there are two very different issues with the output
format.
1) What data belongs in it, and what is the relationship to other data? For instance,
a rhythm needs to be associated with a note, because if there are three notes playing
at the same time, they
On Thu, Jul 29, 2004 at 11:59:44AM -0400, Steven Bennett wrote:
Bernard wrote (portions snipped):
I disagree entirely on the maximise portability. The maximum is ascii. You
can even read it without a computer.
...
Sorry, but it seems archaic to me (in a situation such as we are talking
In message [EMAIL PROTECTED], Wil Macaulay
[EMAIL PROTECTED] writes
with in your target language. I can say quite honestly that C
datastructures in memory are of no use to
me as a Java developer
You can access them. Write a JNI wrapper, then you can read them and
store them any way you
More to the point if java is being chosen as a simple means for cross
platform deployment then jni suddenly makes this much more complicated.
You suddenly go from one distribution to n of them :(
Guy
Wil Macaulay wrote:
Yes, I know I _can_ access them. They are no advantage to me. My Java
not to overstate java's cross platform attributes - but at least I can
put all the platform specific stickiness in one module and compile it
all on the Mac...
wil
Guy Gascoigne - Piggford wrote:
More to the point if java is being chosen as a simple means for cross
platform deployment then jni
To add my two cents to this discussion: While I have my doubts that any
single parser design could fit the needs of more than maybe half (being
generous) of the possible applications out there, it's still a worthwhile
project.
I would avoid producing output in any format which needs further text
What language is Music Publisher 5 written in? What OS?
Delphi. Windows 32.
I ask because I'd like to make the output format convenient for everyone who wants
to read ABC.
Besides, I think we are talking about slightly different things. Here's my vision for
the parser:
Depending on the OS
[snip]
I've done this kind of thing on a number of projects (not ABC related), and it's
always paid off nicely. I'm not saying you have to do it this way, but if you do, you
will maximize your portability, and gain a lot of flexibility.
I disagree entirely on the maximise portability. The
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
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
I'm definitely confused. I'll just keep reading and maybe
I'll catch on to the goal.
ABC is a text format and it seems like most things
associated with ABC might fit better if text, but then again
I don't exactly know what is being proposed. If it is to
read ABC files and convert them to other
I've finally gotten a few free moments of time, and started thinking
about
Hey, if you'd like to volunteer to head up the project, it's still
looking for a project head to get it started.
Thanks, but, did you notice the word few ;-) I'm not sure how much time I
can devote to it. I'll see
This is a big job, and not for the faint of heart - I wish you luck!
Skink is written in Java, and uses a parser written in Javacc. (so a c++
set of datastructures would have done me little good...) I actually
started off with a C++ version using Flex++ and Bison, but found Java
and never
Yes, absolutely, the discussion should stay here. The real purpose of
sourceforge is simply to enable collaboration with CVS, and project
tracking and such.
Chuck Boody wrote:
You are not boring me. I haven't much to contribute right now, but am
following the discussion and may have comments
27 matches
Mail list logo
