[Tex-music] The Future of MusiXTeX etc

[Dirk Laurie]

Recently something has happened to TeX that should change the way we 
are thinking.  This is the fact that LuaTeX has reached Version 0.50.

In theory, only people living on the bleeding edge use LuaTeX.  There
is a warning in the Reference Manual:
   Nothing is considered stable just yet. This manual therefore simply 
   reflects the current state of the executable. Absolutely nothing on 
   the following pages is set in stone. When the need arises, anything 
   can (and will) be changed without prior notice.

In practice, the bare necessities are not likely to change after 0.50.  
I refer to the TeX command \directlua and the Lua function tex.print.  
  \directlua takes one argument, a Lua script, which is executed 
immediately.
  tex.print takes one argument, a string, which is passed to TeX.
The net effect is that the command \directlua{...} acts much like a TeX
macro.  

Lua is a minimalist programming language: simple syntax, only eight 
types (of which the casual user needs six: nil, boolean, number, string, 
table, function), and 21 reserved words.   All arithmetic is in IEEE 
double precision.  It has a string library with powerful pattern-matching 
capability.   It is just the sort of language that can easily translate
PMX-style notes into MusiXTeX macros, computing note and line spacing
as it goes along.

LuaTeX gives access to all the power of Lua from inside a TeX document.

Currently an M-Tx user relies on:
- A preprocessor written in Pascal, compiled to be a stand-alone
   executable, which is different for every operating system
- PMX, which is written in Fortran, compiled etc, different etc
- musixflx, which is written in C, compiled etc, different etc

I have on two occasions asked on this list whether anybody wants to 
help me convert M-Tx to Python.  Christian Mondrup convinced me that 
we shouldn't, as outside the Unix world people don't already have Python 
anyway. 

The objection does not apply to LuaTeX.  All recent TeX distributions
have it, maybe at this stage only as an optional extra, but it is being 
billed as the "next generation TeX engine".

If we had LuaTex in 1992, musixflx could have been implemented in Lua
  and there would be only one TeX pass.
If we had LuaTeX in 1996, PMX could have been implemented in Lua and
  there would not have been pmxa and pmxb passes.
If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
  there would not have been a prepmx pass.

Now it is 2010 and we do have LuaTeX.   

We can go on as we used to: regard musixflx as cast in concrete, rely
on Don to keep maintaining PMX (nobody else except me, as far as I know,
has contributed even one line of Fortran code to it) and hope that someone
occasionally tweaks M-Tx to take account of some recent PMX feature (that
person is no longer me).

Or we can gradually convert more and more of the functionality of these
packages into LuaTeX, thus taking advantage of the fact that the next
generation of TeX package writers will be fluent in it and will be able 
to maintain the software.  A single package luamusix.sty will do everything.

I think the choice is obvious.  Don't you?

Dirk

PS  If you would like to try LuaTeX for yourself, and find the official
documentation a little daunting, you may like to read the story at
http://dip.sun.ac.za/~laurie/luatex



---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[David Allsopp]

Dirk Laurie wrote:
> Recently something has happened to TeX that should change the way we
> are thinking.  This is the fact that LuaTeX has reached Version 0.50.



> Currently an M-Tx user relies on:
> - A preprocessor written in Pascal, compiled to be a stand-alone
>executable, which is different for every operating system
> - PMX, which is written in Fortran, compiled etc, different etc
> - musixflx, which is written in C, compiled etc, different etc
> 
> I have on two occasions asked on this list whether anybody wants to
> help me convert M-Tx to Python.  Christian Mondrup convinced me that
> we shouldn't, as outside the Unix world people don't already have Python
> anyway.
> 
> The objection does not apply to LuaTeX.  All recent TeX distributions
> have it, maybe at this stage only as an optional extra, but it is being
> billed as the "next generation TeX engine".

+1 Although I haven't played with it yet, LuaTeX is now in MiKTeX (since 2.9), 
so Windows is covered, and TeXlive, so the rest of the world (!!) is covered.

> If we had LuaTex in 1992, musixflx could have been implemented in Lua
>   and there would be only one TeX pass.
> If we had LuaTeX in 1996, PMX could have been implemented in Lua and
>   there would not have been pmxa and pmxb passes.
> If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
>   there would not have been a prepmx pass.

Absolutely - this is the greatest potential strength of LuaTeX - a proper 
programming language rather than a slightly weird (and fun!) macro language.

Note that your utopia of one pass is not necessarily a given - admittedly 
MusixTeX can probably be structured to do musixflx "as it goes" but for other 
auxiliaries (such as makeindex or LaTeX cross-references) it would be very hard 
to do this. You need to be able to reset TeX (and ensure that in the first pass 
your \output routine isn't emitting any pages).

> Now it is 2010 and we do have LuaTeX.
> 
> We can go on as we used to: regard musixflx as cast in concrete, rely
> on Don to keep maintaining PMX (nobody else except me, as far as I know,
> has contributed even one line of Fortran code to it) and hope that someone
> occasionally tweaks M-Tx to take account of some recent PMX feature (that
> person is no longer me).

musixflx is not a big program - it really shouldn't be necessary to leave it 
cast in stone in C.

> Or we can gradually convert more and more of the functionality of these
> packages into LuaTeX, thus taking advantage of the fact that the next
> generation of TeX package writers will be fluent in it and will be able
> to maintain the software.  A single package luamusix.sty will do everything.
> 
> I think the choice is obvious.  Don't you?

Wholeheartedly agree! Frankly, I think that much of the internals of the more 
complex TeX packages will gradually be moved to Lua (as an infinitely more sane 
language!).


David
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Jill-Jênn VIE]

Le 16 nov. 2010 à 07:48, Dirk Laurie a écrit :

> I think the choice is obvious.  Don't you?

Wanna be part of it! Lately I've been fighting with the question: “Should I try 
Lilypond?” but your idea is much more interesting.
Don't know anything about Lua though.

> PS  If you would like to try LuaTeX for yourself, and find the official
>documentation a little daunting, you may like to read the story at
>http://dip.sun.ac.za/~laurie/luatex

Does it support Unicode as well as XeTeX (I mean, as WELL)?

-- 
Jill-Jênn
http://www.jill-jenn.net


---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Robin Fairbairns]

Jill-Jênn VIE  wrote:

> > I think the choice is obvious.  Don't you?
> 
> Wanna be part of it! Lately I've been fighting with the question:
> “Should I try Lilypond?” but your idea is much more interesting.
> Don't know anything about Lua though.

lua's pretty simple (it was chosen, at least in part, because it's easy
to embed in other programs).  if you've programmed in any other
scripting language you'll probably have little difficulty with it.

> > PS  If you would like to try LuaTeX for yourself, and find the official
> >documentation a little daunting, you may like to read the story at
> >http://dip.sun.ac.za/~laurie/luatex
> 
> Does it support Unicode as well as XeTeX (I mean, as WELL)?

sure: unicode is its default character set.

there remain _some_ wrinkles, but it's pretty good already.  (target
date for the 1.0 release is some time in 2012, iirc.)

btw --

>>http://dip.sun.ac.za/~laurie/luatex

doesn't let me download the .tex file of the primer.  it would be nice
to look at that.

robin

---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Bernhard Lang]

Thanks Dirk to draw our attention to this new development. Such a major 
change--and it would be a major change--would perhaps also give opportunity to 
think about how to overcome some limitations to MusixTeX and friends which are 
due to its design. Quite some inline TeX coding could probably moved into the 
"primary language".

Getting rid of a double pass system won't probably work because TeX itself 
relies on such mechanism. Typesetting is always recursive because some 
informations are not available before some important part of the typesetting 
has already been done. You can't for instance set page links before you have 
set all pages as to know what is going to be put on which page. But setting the 
links may also influence, at least on the scale of details, how a page or 
paragraph is set. The same is true for all the mutually aligned stuff in a 
score.

The main reason for me for staying with MusixTeX (besides never to change 
something which is already up and running) is its outstanding graphical 
clearness concerning representation of rhythm. I think we cannot thank enough 
Don for implenting and maintaining PMX, which, as far as I can judge, does most 
of that miracle.

Sometimes the limitation to 12 voices gets in the way and after being forced 
such way to use an alternative its always a pleasure to return what is 
graphically still the best being available. What is more, once used to the 
PMX/M-Tx language, setting a score in much faster than with any other system I 
know. There is as less overhead as possible though almost anything can be 
controlled.

Bernhard
 
On Nov 16, 2010, at 7:48 , Dirk Laurie wrote:

> 
> Recently something has happened to TeX that should change the way we 
> are thinking.  This is the fact that LuaTeX has reached Version 0.50.
> 
> In theory, only people living on the bleeding edge use LuaTeX.  There
> is a warning in the Reference Manual:
>   Nothing is considered stable just yet. This manual therefore simply 
>   reflects the current state of the executable. Absolutely nothing on 
>   the following pages is set in stone. When the need arises, anything 
>   can (and will) be changed without prior notice.
> 
> In practice, the bare necessities are not likely to change after 0.50.  
> I refer to the TeX command \directlua and the Lua function tex.print.  
>  \directlua takes one argument, a Lua script, which is executed 
>immediately.
>  tex.print takes one argument, a string, which is passed to TeX.
> The net effect is that the command \directlua{...} acts much like a TeX
> macro.  
> 
> Lua is a minimalist programming language: simple syntax, only eight 
> types (of which the casual user needs six: nil, boolean, number, string, 
> table, function), and 21 reserved words.   All arithmetic is in IEEE 
> double precision.  It has a string library with powerful pattern-matching 
> capability.   It is just the sort of language that can easily translate
> PMX-style notes into MusiXTeX macros, computing note and line spacing
> as it goes along.
> 
> LuaTeX gives access to all the power of Lua from inside a TeX document.
> 
> Currently an M-Tx user relies on:
> - A preprocessor written in Pascal, compiled to be a stand-alone
>   executable, which is different for every operating system
> - PMX, which is written in Fortran, compiled etc, different etc
> - musixflx, which is written in C, compiled etc, different etc
> 
> I have on two occasions asked on this list whether anybody wants to 
> help me convert M-Tx to Python.  Christian Mondrup convinced me that 
> we shouldn't, as outside the Unix world people don't already have Python 
> anyway. 
> 
> The objection does not apply to LuaTeX.  All recent TeX distributions
> have it, maybe at this stage only as an optional extra, but it is being 
> billed as the "next generation TeX engine".
> 
> If we had LuaTex in 1992, musixflx could have been implemented in Lua
>  and there would be only one TeX pass.
> If we had LuaTeX in 1996, PMX could have been implemented in Lua and
>  there would not have been pmxa and pmxb passes.
> If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
>  there would not have been a prepmx pass.
> 
> Now it is 2010 and we do have LuaTeX.   
> 
> We can go on as we used to: regard musixflx as cast in concrete, rely
> on Don to keep maintaining PMX (nobody else except me, as far as I know,
> has contributed even one line of Fortran code to it) and hope that someone
> occasionally tweaks M-Tx to take account of some recent PMX feature (that
> person is no longer me).
> 
> Or we can gradually convert more and more of the functionality of these
> packages into LuaTeX, thus taking advantage of the fact that the next
> generation of TeX package writers will be fluent in it and will be able 
> to maintain the software.  A single package luamusix.sty will do everything.
> 
> I think the choice is obvious.  Don't you?
> 
> Dirk
> 
> PS  If you would like to try LuaTeX for yourself, and fi

Re: [Tex-music] The Future of MusiXTeX etc

[Bob Tennent]

 >|I have on two occasions asked on this list whether anybody wants to
 >|help me convert M-Tx to Python.  Christian Mondrup convinced me that
 >|we shouldn't, as outside the Unix world people don't already have Python
 >|anyway.

That may have been the case when you asked but it isn't now: Python is
everywhere.

 >|The objection does not apply to LuaTeX.  All recent TeX distributions
 >|have it, maybe at this stage only as an optional extra, but it is being
 >|billed as the "next generation TeX engine".
 >|
 >|If we had LuaTex in 1992, musixflx could have been implemented in Lua
 >|  and there would be only one TeX pass.
 >|If we had LuaTeX in 1996, PMX could have been implemented in Lua and
 >|  there would not have been pmxa and pmxb passes.
 >|If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
 >|  there would not have been a prepmx pass.
 >|
 >|Now it is 2010 and we do have LuaTeX.
 >|
 >|We can go on as we used to: regard musixflx as cast in concrete, rely
 >|on Don to keep maintaining PMX (nobody else except me, as far as I know,
 >|has contributed even one line of Fortran code to it) and hope that someone
 >|occasionally tweaks M-Tx to take account of some recent PMX feature (that
 >|person is no longer me).
 >|
 >|Or we can gradually convert more and more of the functionality of these
 >|packages into LuaTeX, thus taking advantage of the fact that the next
 >|generation of TeX package writers will be fluent in it and will be able
 >|to maintain the software.  A single package luamusix.sty will do
 >|everything.
 >|
 >|I think the choice is obvious.  Don't you?

No. Is Don willing to re-write PMX in Lua or anything else? I doubt it
and as PMX is still being developed, his cooperation is essential. As
for choosing Lua, I have my doubts. It sounds like a simple scripting
language with bindings to TeX. Could not such bindings be written for
Python? The TeX community seems again to be doing something completely
idiosyncratic.

Bob T.
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Filipe de Moraes Paiva]

Hello friends.
Could anyone tell me what is going on? I use MusixTex but, I guess, in a
very simple way, actually, I use MusixTex inside Latex. I don't know nothing
about PMX or LuaTex etc; never heard about it. Could anyone tell me if
something good or bad is coming?
Regards,
Filipe

2010/11/16 Bernhard Lang 

> Thanks Dirk to draw our attention to this new development. Such a major
> change--and it would be a major change--would perhaps also give opportunity
> to think about how to overcome some limitations to MusixTeX and friends
> which are due to its design. Quite some inline TeX coding could probably
> moved into the "primary language".
>
> Getting rid of a double pass system won't probably work because TeX itself
> relies on such mechanism. Typesetting is always recursive because some
> informations are not available before some important part of the typesetting
> has already been done. You can't for instance set page links before you have
> set all pages as to know what is going to be put on which page. But setting
> the links may also influence, at least on the scale of details, how a page
> or paragraph is set. The same is true for all the mutually aligned stuff in
> a score.
>
> The main reason for me for staying with MusixTeX (besides never to change
> something which is already up and running) is its outstanding graphical
> clearness concerning representation of rhythm. I think we cannot thank
> enough Don for implenting and maintaining PMX, which, as far as I can judge,
> does most of that miracle.
>
> Sometimes the limitation to 12 voices gets in the way and after being
> forced such way to use an alternative its always a pleasure to return what
> is graphically still the best being available. What is more, once used to
> the PMX/M-Tx language, setting a score in much faster than with any other
> system I know. There is as less overhead as possible though almost anything
> can be controlled.
>
> Bernhard
>
> On Nov 16, 2010, at 7:48 , Dirk Laurie wrote:
>
> >
> > Recently something has happened to TeX that should change the way we
> > are thinking.  This is the fact that LuaTeX has reached Version 0.50.
> >
> > In theory, only people living on the bleeding edge use LuaTeX.  There
> > is a warning in the Reference Manual:
> >   Nothing is considered stable just yet. This manual therefore simply
> >   reflects the current state of the executable. Absolutely nothing on
> >   the following pages is set in stone. When the need arises, anything
> >   can (and will) be changed without prior notice.
> >
> > In practice, the bare necessities are not likely to change after 0.50.
> > I refer to the TeX command \directlua and the Lua function tex.print.
> >  \directlua takes one argument, a Lua script, which is executed
> >immediately.
> >  tex.print takes one argument, a string, which is passed to TeX.
> > The net effect is that the command \directlua{...} acts much like a TeX
> > macro.
> >
> > Lua is a minimalist programming language: simple syntax, only eight
> > types (of which the casual user needs six: nil, boolean, number, string,
> > table, function), and 21 reserved words.   All arithmetic is in IEEE
> > double precision.  It has a string library with powerful pattern-matching
> > capability.   It is just the sort of language that can easily translate
> > PMX-style notes into MusiXTeX macros, computing note and line spacing
> > as it goes along.
> >
> > LuaTeX gives access to all the power of Lua from inside a TeX document.
> >
> > Currently an M-Tx user relies on:
> > - A preprocessor written in Pascal, compiled to be a stand-alone
> >   executable, which is different for every operating system
> > - PMX, which is written in Fortran, compiled etc, different etc
> > - musixflx, which is written in C, compiled etc, different etc
> >
> > I have on two occasions asked on this list whether anybody wants to
> > help me convert M-Tx to Python.  Christian Mondrup convinced me that
> > we shouldn't, as outside the Unix world people don't already have Python
> > anyway.
> >
> > The objection does not apply to LuaTeX.  All recent TeX distributions
> > have it, maybe at this stage only as an optional extra, but it is being
> > billed as the "next generation TeX engine".
> >
> > If we had LuaTex in 1992, musixflx could have been implemented in Lua
> >  and there would be only one TeX pass.
> > If we had LuaTeX in 1996, PMX could have been implemented in Lua and
> >  there would not have been pmxa and pmxb passes.
> > If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
> >  there would not have been a prepmx pass.
> >
> > Now it is 2010 and we do have LuaTeX.
> >
> > We can go on as we used to: regard musixflx as cast in concrete, rely
> > on Don to keep maintaining PMX (nobody else except me, as far as I know,
> > has contributed even one line of Fortran code to it) and hope that
> someone
> > occasionally tweaks M-Tx to take account of some recent PMX feature (that
> > person is no 

Re: [Tex-music] The Future of MusiXTeX etc

[Robin Fairbairns]

Bob Tennent  wrote:

>  >|I have on two occasions asked on this list whether anybody wants to
>  >|help me convert M-Tx to Python.  Christian Mondrup convinced me that
>  >|we shouldn't, as outside the Unix world people don't already have Python
>  >|anyway.
> 
> That may have been the case when you asked but it isn't now: Python is
> everywhere.

i know of no widnoze-based python users, but i know lots who use perl.
while i can write perl moderately fluently, i wouldn't start any new
project using it.

>  >|The objection does not apply to LuaTeX.  All recent TeX distributions
>  >|have it, maybe at this stage only as an optional extra, but it is being
>  >|billed as the "next generation TeX engine".
>  >|
>  >|If we had LuaTex in 1992, musixflx could have been implemented in Lua
>  >|  and there would be only one TeX pass.
>  >|If we had LuaTeX in 1996, PMX could have been implemented in Lua and
>  >|  there would not have been pmxa and pmxb passes.
>  >|If we had LuaTeX in 1999, M-Tx could have been implemented in Lua and
>  >|  there would not have been a prepmx pass.
>  >|
>  >|Now it is 2010 and we do have LuaTeX.
>  >|
>  >|We can go on as we used to: regard musixflx as cast in concrete, rely
>  >|on Don to keep maintaining PMX (nobody else except me, as far as I know,
>  >|has contributed even one line of Fortran code to it) and hope that someone
>  >|occasionally tweaks M-Tx to take account of some recent PMX feature (that
>  >|person is no longer me).
>  >|
>  >|Or we can gradually convert more and more of the functionality of these
>  >|packages into LuaTeX, thus taking advantage of the fact that the next
>  >|generation of TeX package writers will be fluent in it and will be able
>  >|to maintain the software.  A single package luamusix.sty will do
>  >|everything.
>  >|
>  >|I think the choice is obvious.  Don't you?
> 
> No. Is Don willing to re-write PMX in Lua or anything else? I doubt it
> and as PMX is still being developed, his cooperation is essential.

indeed, co-operation is important here.

> As for choosing Lua, I have my doubts. It sounds like a simple
> scripting language with bindings to TeX.

it's a compact scripting language which has been embedded in a new
tex-like development.  i don't write it fluently (yet) but am willing to
accept people's assertions about its power.

> Could not such bindings be written for
> Python? The TeX community seems again to be doing something completely
> idiosyncratic.

there are perl- and python-based call-backs that some people use.
jonathan fine wrote such a thing, using python, that's even slightly
efficient.  i wouldn't be surprised if i were told that there are
others, such as ruby.

luatex is different: the lua interpreter is part of the luatex
executable, and there are luatex primitives that allow interaction with
the interpreter.  the interpreter can manage parts of the typesetting
data structures, as well.

this isn't a new technique (for example, the exim mailer that i use
offers a build-time perl, as does the apache web server), but it's an
obvious one.

the choice of lua isn't as eccentric as you seem to imagine.  there are
research groups in my department who are developing a lua culture, in
place of the perl culture that pervaded the group i worked in, in the
90s.  (that's happening entirely independently of tex developments -- i
just happened to stumble on something a research student was writing.)
what's in the labs now may well be widespread on the street soon: it's a
better thought-through language than perl, afaict (so far).

robin
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Don Simons]

Bernhard Lang wrote

>...
>Sometimes the limitation to 12 voices gets in the way
>

Not for long! Even now there are prototypes available on Hiroaki's site of
MusiXTeX 1.15 and PMX 2.60 which together allow up to 24 voices (and 1.15
will allow many more). Very soon these will be activated in WIMA.

http://homepage1.nifty.com/kuuku/pub/musixtex/t115beta-e.html

--Don Simons


---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Robin Fairbairns]

Filipe de Moraes Paiva  wrote:

> Could anyone tell me what is going on? I use MusixTex but, I guess, in a
> very simple way, actually, I use MusixTex inside Latex. I don't know
> nothing about PMX or LuaTex etc; never heard about it. Could anyone tell
> me if something good or bad is coming?

nothing is going on, at the musixtex level.  some people are speculating
about moving musixtex to a new platform, wrapping up (at least) pmx's
functionality at the same time.

there _is_ a lot of work being done on luatex, which is a putative
replacement for tex, but it's still 18 months or more from "final"
delivery.

i don't think you would miss much if you ignored all the heated debate
in this area.  otoh, if someone announces a new version that uses
luatex, then you might find it worth looking at.

robin
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Veronica Brandt]

The Gregorio project has been using luatex for years now.  That's for
typesetting gregorian chant using a gregorian abc sort of input
format.  I haven't been looking at the internals, but from the outside
it looks like a similar thing.

>From the gabc format (roughly corresponding to .mtx) there's a
separate program to turn that into a .tex file (very long sort of
markup, much like musixtex) then include that music fragment into your
main tex document.

Not sure why they have the separate program to turn .gabc to .tex, but
if that's necessary then looking more at just the MusixTex side might
be the way to go.  Make musixflx redundant first.


Veronica

-- 
Mrs. Veronica Brandt
0407 887 637
http://www.brandt.id.au
---
 Angels can fly because they take themselves so lightly. --GKC
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[David Allsopp]

Veronica Brandt wrote:
> The Gregorio project has been using luatex for years now.  That's for
> typesetting gregorian chant using a gregorian abc sort of input format.  I
> haven't been looking at the internals, but from the outside it looks like
> a similar thing.
> 
> >From the gabc format (roughly corresponding to .mtx) there's a
> separate program to turn that into a .tex file (very long sort of markup,
> much like musixtex) then include that music fragment into your main tex
> document.
> 
> Not sure why they have the separate program to turn .gabc to .tex, but if
> that's necessary then looking more at just the MusixTex side might be the
> way to go.  Make musixflx redundant first.

It takes an awful lot of C code (and in PMX, it's quite a lot of FORTRAN) to
translate those input files to TeX. I may well be wrong, but it looks to me
as though even LuaTeX doesn't look really suited to processing a file which
is fundamentally not a TeX file in its syntax. I expect you'd have a jump
through a lot of quite painful hoops to implement the pre-processors in
LuaTeX. That said, the similarities between Lua (which is not very familiar
to me yet) and JavaScript's "Good Parts"^{TM} (which are far too familiar to
me) suggest that if you can get to an un-TeX'd file input stream then you
perhaps you can get the pre-processors implemented directly in Lua. BUT...

musixflx.c - roughly 35KB of C sources and a (relatively) straightforward
piece of array manipulation (which is the only reason it was written in C in
the first place - TeX's handling of arrays is like programming a Turing
machine using blood instead of a pencil) serving one single purpose.

pmxab.for - roughly 750KB - a file pre-processor with a large number of
calculation algorithms for various different tasks. i.e. complex!
Additionally, there's probably only one person who can port it, unless there
are some other Fortan programmers floating around on this list.

Gregorio - similarly, roughly 750KB of sources. Similar argument. At least
it's written in C.

In other words, we're talking about porting a vast amount of code for the
pre-processors.

Eliminating the need for musixflx would be good - especially if the code can
be structured so that a Lua-scripted version of musixflx can still be used
on platforms with a normal Lua interpreter for systems without LuaTeX.


David

---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Arjen Bax]

2010/11/17 David Allsopp wrote:

> musixflx.c - roughly 35KB of C sources
> pmxab.for - roughly 750KB
> Gregorio - similarly, roughly 750KB of sources [...] written in C.
>
> In other words, we're talking about porting a vast amount of code for the
> pre-processors.

Add to this prepmx written in Pascal, and you'll have to prepare for a
maintenance nightmare.

With luatex (and texlua) at least a single programming language comes
available on all TeX-supporting platforms. I think that a port of the
different tools to this (or any) unified environment is crucial for
continued support. After all, who still knows Fortran nowadays? (Yes,
Don is the master of course! But it is a dying skill.) Even knowledge
of Pascal is declining. It would be very regrettable if the many hours
and great deal of knowledge that have been put in these programs would
be lost because it is locked up in a programming language that nobody
knows any more.

With a port to Lua (or Perl, Python, Ruby), I see as the main
advantages from the language itself: easier string handling, dynamic
array sizes, hash tables.

As Veronica already pointed out: it has to be staged, gaining
experience with every little step.

Kind regards,
Arjen Bax
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Bernhard Lang]

> It would be very regrettable if the many hours and great deal of knowledge 
> that have been put in these programs would be lost because it is locked up in 
> a programming language that nobody knows any more.
> 
> With a port to Lua (or Perl, Python, Ruby), I see as the main advantages from 
> the language itself: easier string handling, dynamic array sizes, hash tables.

If you master any of these languages, you'll understand Pascal and Fortran as 
easily. And what is not obvious can be looked up in the manual. What really 
takes time is understandig the sources of a program you don't have written and 
maintained over "time of growth" yourself. Would you want to maintain or port 
any program in the chain we are talking about, that would be the most time 
consuming part, not the lack of being familar with the used programming 
language. If there isn't a point like "you can't do this and that in the 
employed language", there's no need to port a (very well) running software to 
some "more modern" language. You're most probably just going to sweep different 
sort of dirt under different places of the rug. The rest ist queston of taste.

best regards
Bernhard
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Myscha Aiken (née Butt)]

As someone who uses MusiXTeX only for specialized applications such as 
the generation of examples in mensural notation, I have to ask if anyone 
on the list is really familiar with the advances that have been made in 
implementing ABC Plus? For most purposes (mine tend to be very simple 
requirements) ABC Plus is capable of producing some very acceptable 
results in contemporary notation and the syntax is much simpler. Purely 
for my own purposes I would favour something similar, if not based on 
the ABC Plus syntax.

--
Myscha 
---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music

Re: [Tex-music] The Future of MusiXTeX etc

[Hermann Hinsch]

Am Dienstag, 16. November 2010, 16:24:45 schrieb Don Simons:
> Bernhard Lang wrote
> 
> >...
> >Sometimes the limitation to 12 voices gets in the way
> 
> Not for long! Even now there are prototypes available on Hiroaki's site of
> MusiXTeX 1.15 and PMX 2.60 which together allow up to 24 voices (and 1.15
> will allow many more). Very soon these will be activated in WIMA.
> 
> http://homepage1.nifty.com/kuuku/pub/musixtex/t115beta-e.html
> 
> --Don Simons
> 
> 

Hi Don

would it be possible to use M-Tx with up to 24 voices? I tried an example with 
17 voices but 
I get the error message "too many groups"

Hermann

> ---
> TeX-music@tug.org mailing list
> If you want to unsubscribe or look at the archives, go to
> http://tug.org/mailman/listinfo/tex-music

---
TeX-music@tug.org mailing list
If you want to unsubscribe or look at the archives, go to 
http://tug.org/mailman/listinfo/tex-music