Re: [TeX-music] MTx V0.60 in C
Neil Killeen skryf: Christian On Mon, 30 May 2005, Christian Mondrup wrote: Neil Killeen wrote: Hi I'd like to install the new MTx v0.60. However I can't find the C-sources, mtxC060.zip, in the software archive. I can only find the Pascal, mtxP060.zip (which I can't do anything with) You can by downloading and installing the FreePascal compiler from http://www.freepascal.org/. The M-Tx pascal source files are specifically written for that compiler available for quite a few operating systems. -- yes i am aware of that possibility but was hoping to avoid it ! The README for MTx refers to the possibility of building MTx from C-sources (see below) which presumably someone (Dirk?) creates from the Pascal source via p2c or the like. Some time ago I wanted to retire as maintainer of M-Tx. I was persuaded to carry on, but on the condition that I supply only Free Pascal source -- other people build binaries for Windows, Mac etc. My main reason for so doing is that p2c is no longer maintained, but Free Pascal is. It is a major effort to keep M-Tx source compatible with the quirks (read: bugs) of fpc and it requires someone who wants C source more fervently than I do. If you are putting up your hand to do this and keep doing it, I will advise, but IMHO you would be flogging a dead horse. Dirk ___ TeX-music mailing list TeX-music@icking-music-archive.org http://icking-music-archive.org/mailman/listinfo/tex-music
Re: [TeX-music] MTx V0.60 in C
Dirk Neil Killeen skryf: Christian On Mon, 30 May 2005, Christian Mondrup wrote: Neil Killeen wrote: Hi I'd like to install the new MTx v0.60. However I can't find the C-sources, mtxC060.zip, in the software archive. I can only find the Pascal, mtxP060.zip (which I can't do anything with) You can by downloading and installing the FreePascal compiler from http://www.freepascal.org/. The M-Tx pascal source files are specifically written for that compiler available for quite a few operating systems. -- yes i am aware of that possibility but was hoping to avoid it ! The README for MTx refers to the possibility of building MTx from C-sources (see below) which presumably someone (Dirk?) creates from the Pascal source via p2c or the like. Some time ago I wanted to retire as maintainer of M-Tx. I was persuaded to carry on, but on the condition that I supply only Free Pascal source -- other people build binaries for Windows, Mac etc. My main reason for so doing is that p2c is no longer maintained, but Free Pascal is. It is a major effort to keep M-Tx source compatible with the quirks (read: bugs) of fpc and it requires someone who wants C source more fervently than I do. If you are putting up your hand to do this and keep doing it, I will advise, but IMHO you would be flogging a dead horse. Dirk ok Dirk - obviously there has been discussion on the list in the past that I was not reading in my music-tex comatose state... I was misled then by the README file which still references the C-sources zip files. I am not sure what will be the best path for me. To try and get MTx through p2c or have a go at the SOlaris port of free pascal 1.0.1 (quite old compared to the current version 2.0). I will find out ! groeten Neil ___ TeX-music mailing list TeX-music@icking-music-archive.org http://icking-music-archive.org/mailman/listinfo/tex-music
[TeX-music] PMX 2.507 Challenge to TeXperts
I've just uploaded PMX beta 2.507 to http://icking-music-archive.org/software/pmx/pmx2507.zip . It has an enhancement to the new global option AK for vertical positioning of rests in two-voice staves that I introduced in version 2.505: The option L (look left) in a rest will cause the vertical position of that rest to be based on the preceding note, rather than the following one as is the default when AK has been issued. There is a bugfix allowing unbeamed xtups with two flags. Finally there's a partial bugfix addressing a problem Cornelius recently flagged: In unbeamed xtuplets, the length of the bracket and position of the number are now adjusted horizontally to account for any inserted hardspaces. The fix is only partial in that the bracket still can end before the last stem. The algorithm is only approximate. The reason it's not exact is rather complicated. It has to do with the fact that every inserted hardspace decreases the space available for scaled space, but that in turn changes the exact hardspace required, since the fixed-length gaps where hardspace must be added have some scalable space in them too. Basically you have to get to the end of the line before you have enough information to compute the ratio of hardspace to scaled space. The brackets span both hardspace and scaled space, but when the \ovbkt command is issued, it has to give the length in \elemskips (which is the ratio of hardspace to scaled space). If the bracket has to span any hardspace, then you can't know the right number of \elemskips until you get to the end of the line. Instead of working out the necessary logic, I have punted and calculated each bracket length completely ignoring the effect of hardspace on \elemskip. I can see two possible ways to a full solution. First I could work out the necessary logic and programming, which I might do just for the challenge. But it seems to me that the TeXperts (Stanislav, are you listening?) ought to be able to design a two=part TeX command that draws a bracket like a slur, i.e., from point A to point B rather than from point A then move 3 inches to the right and 1 inch up. That would then make drawing these brackets so much easier that PMX could learn to do it really quick. --Don Simons ___ TeX-music mailing list TeX-music@icking-music-archive.org http://icking-music-archive.org/mailman/listinfo/tex-music
