Re: [Tex-music] The Future of MusiXTeX etc
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
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 find the official
documentation a little daunting, you may like to
Re: [Tex-music] The Future of MusiXTeX 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. 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
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 bernhard.l...@gmx.ch
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
Re: [Tex-music] The Future of MusiXTeX etc
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
[Tex-music] PMX? (was RE: The Future of MusiXTeX etc)
I’ve failed as an advertiser. PMX is a preprocessor for musixtex which you
should definitely avoid if you prefer
1. typing input files that are 3 times longer than they have to be
2. calculating and adjusting all the horizontal spacings of all notes based on
their durations and relationships to other notes, rather than having PMX do all
such analysis behind the scenes
See http://www.icking-music-archive.org/software/indexmt6.html#pmx
--Don Simons
From: tex-music-boun...@tug.org [mailto:tex-music-boun...@tug.org] On Behalf Of
Filipe de Moraes Paiva
Sent: Tuesday, November 16, 2010 7:20 AM
To: Werner Icking Music Archive
Subject: Re: [Tex-music] The Future of MusiXTeX etc
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 bernhard.l...@gmx.ch
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
