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 languag
Remo D. wrote:
That's exactly why I suggested using an embeddable scripting language. The
interpreter cames as a dll and your program just call the appropriate
functions.
The core of our "abc subsystem" (please, someone suggest a name for this
"thing") could be released as a library (a dll under Wi
Neil wrote:
> This is OK for those with access to the scripts.
> I am working in VB, on Windows, and may not be able to make
> use of software which is not compatible. This was because the
> program was ported from QBasic.
> There is no way in which I could ever rewrite 100k lines of
> code now.
This is OK for those with access to the scripts.
I am working in VB, on Windows, and may not be able to make use of
software which is not compatible. This was because the program was
ported from QBasic.
There is no way in which I could ever rewrite 100k lines of code now.
Remo D. wrote:
M
Maybe useful to better understand my previous post!
Remo<>
Neil Jennings wrote:
The point about using XML is that although it is a text format,
parsers already exist on all platforms which can parse the XML, and
hold the data in an object structure. You can then extract whatever
information your application needs.
The existing MusicXML provides MOST of
I have been reading this thread for a while and that's my two cents.
If I've understood well, we are talking of creating a piece of software that
could be embedded in other applications. It will be able to read an abc file
and create an in-memory structure suitable for further transformations
(cre
The point about using XML is that although it is a text format, parsers
already exist on all platforms which can parse the XML, and hold the
data in an object structure. You can then extract whatever information
your application needs.
The existing MusicXML provides MOST of the features necessa
Steven Bennett wrote:
I was going to let this idea die quietly...
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 own
par
I was going to let this idea die quietly...
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 own
parser. Having the out
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 Ro
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 wrote:
I've been poking around the web a little bit and I came upon
http://libmusicxml.sourceforge.net/
This is an op
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 tha
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
| 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
sub-project to control the length and pitc
>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
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:http://www.objmed
Stephen Kellett writes:
| Yes. I'm involved with a Java project. The language was chosen by the
| person that pays the bills. He chose Java for cross-platform. Laudable.
| Except that in 1996/97 we wanted a speech synth and could only get one
| on Windows and we had to write a JNI wrapper for it. O
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 :(
Yes. I'm involved with a Java project. The language was chosen by the
person that pays the bills. He
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 s
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
obj
Yes, I know I _can_ access them. They are no advantage to me. My Java
objects are lightweight, and
the same jar file can run on any platform without requiring separate
compilation of JNI wrappers. I'm
not trying to diminish the theoretical value of cross-language support,
I'm simply suggesting
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 de
>>
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
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 a
>>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 c
>>
> 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
Steven Bennett wrote:
[various things snipped]
Mind you, I agree that C structures are somewhat archaic, but they do the
job. Ideally the output should be a set of objects, but then you'd lose
cross-language portability.
cross-language portability is IMHO a bit of a red herring. Make the
datastr
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 talkin
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)
> 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 follow
> 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 con
[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".
>>
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
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
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 f
> 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 stor
>
>>> 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 h
> >>> 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.
> > <<
On 27 Jul 2004, at 10:53, Bernard wrote:
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
>>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
voice problem.
Neil
Paul Rosen wrote:
-
Original Message -
From:
Neil Jennings
To:
[EMAIL PROTECTED]
Sent:
Monday, July 26, 2004 2:30 PM
Subject:
Re: [abcusers] ABC parser output data structure.
A few points:
I too use a
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
You are not boring me. I haven't much to contribute right now, but am
following the discussion and may have comments later. I would hope the
discussion stays here.
Chuck Boody
On Monday, July 26, 2004, at 08:52 PM, Paul Rosen wrote:
I've finally gotten a few free moments of time, and
> 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 neve
> >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
- Original Message -
From:
Neil Jennings
To: [EMAIL PROTECTED]
Sent: Monday, July 26, 2004 2:30 PM
Subject: Re: [abcusers] ABC parser output
data structure.
A few points:I too use a bidirectional linked list, mine is of
note objects within each voice. (Note
Btw.. if anyone has trouble finding it,
http://sourceforge.net/projects/alphabetsoup/
Login and join up :)
--
||
Christian Marcus Cepel | And the wrens have returned &
[EMAIL PROTECTED] icq:12384980 | are nesting; In the hollow of
371 Crown Point, Columbia, MO| that oak where his he
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 looke
Paul Rosen wrote:
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.
Just go to sourceforge.org and search for the Alphabet Soup project and
register to be
>>I would leave out consideration of
a file structure for some time, since that will tie you down badly if
you want to make changes later.
<<
No. If you use an ascii based format with keywords it works fine.
For instance (and this is only a simplistic example!)
Bar 1 =
(Chord 1
Chord 2
Chord 3)
A few points:
I too use a bidirectional linked list, mine is of note objects within
each voice. (Note objects include bar lines and other musical items)
My program (HARMONY) is written in VB - I would hope to be able to use
the parser from that.
MusicXML uses the standard XML parser, I am e
First of all, thanks for some great insights! I knew that I should post my
ideas here first before doing any coding.
> > 3. This is the data structure between the ABC parser and the
> > application.
> > There are two main applications: a sheet music formatter, and music
> > player.
> > I think oth
On 26 Jul 2004, at 04:23, Paul Rosen wrote:
I've finally gotten a few free moments of time, and started thinking
about
the "universal parser" that we talked about a few months back. I
started to
write down the requirements for the output, which I've included below.
I've
included everything I cou
I've finally gotten a few free moments of time, and started thinking about
the "universal parser" that we talked about a few months back. I started to
write down the requirements for the output, which I've included below. I've
included everything I could think of for formatting and playing music.
56 matches
Mail list logo
