Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX
Stanislav, > it would be indeed possible, actualy much easier that the slurs. That's very good news. > However, I am long out of the TeX and PS programming, so I won't be of > any help here, I am afraid... :-( That's less good news ... I am tempted to try it myself but that would certainly not be any time soon. Best, Wilfried > -Ursprüngliche Nachricht- > Von: Stanislav Kneifl [mailto:[email protected]] > Gesendet: Freitag, 30. Dezember 2022 17:07 > An: Werner Icking Music Archive; Wilfried Lingenberg > Betreff: Re: [Tex-music] Tales from typesetting a professional edition > withMusiXTeX > > Hi, > > it would be indeed possible, actualy much easier that the slurs. > However, I am long out of the TeX and PS programming, so I won't be of > any help here, I am afraid... :-( > > Stanislav. > > Dne 30.12.2022 v 15:18 Wilfried Lingenberg napsal(a): > > I see! Then I had an incorrect idea about the current mechanics of > musixvbm. > > (Incidentally, I was really grateful when I discovered musixvbm! I do not > > want to know how the printed score would have looked without it.) > > > > Would it help to have a close look at musixps? For slurs, it calculates a > > Bezier curve between two given points. Maybe the algorithm could be > tweaked > > to obtain a "beam engine". (In that case, new beam commands would > probably > > best be incorporated into the musixps package.) > > > > Best, > > > > Wilfried --- [email protected] mailing list If you want to unsubscribe or look at the archives, go to https://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX
Hi, it would be indeed possible, actualy much easier that the slurs. However, I am long out of the TeX and PS programming, so I won't be of any help here, I am afraid... :-( Stanislav. Dne 30.12.2022 v 15:18 Wilfried Lingenberg napsal(a): I see! Then I had an incorrect idea about the current mechanics of musixvbm. (Incidentally, I was really grateful when I discovered musixvbm! I do not want to know how the printed score would have looked without it.) Would it help to have a close look at musixps? For slurs, it calculates a Bezier curve between two given points. Maybe the algorithm could be tweaked to obtain a "beam engine". (In that case, new beam commands would probably best be incorporated into the musixps package.) Best, Wilfried -Ursprüngliche Nachricht- Von: TeX-Music [mailto:tex-music-bounces+w.lingenberg=t- [email protected]] Im Auftrag von Hiroaki MORIMOTO Gesendet: Freitag, 30. Dezember 2022 14:54 An: Werner Icking Music Archive Betreff: Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX Yes of course! What I wished on beams in past years are very close to your request. Unfortunately current task of musixvbm is just only a simple replacement of low level drawing routine for beams (and hairpins) from font-patchwork-based into vector drawing (tpic specials or pdfTeX raw literal) without changing any syntaxes. That is the limit of my skill at that time. Also, not all coverage of dviwares. But in fact, as you mentioned, the vector-drawing routines would be essential to draw more correct beams. Sincerely, Hiroaki - Original Message - From: "Wilfried Lingenberg" To: "'Werner Icking Music Archive'" Date: Fri, 30 Dec 2022 04:13:06 +0100 Subject: Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX Hiroaki, I am not sure I understood correctly what you wrote, and certainly I do not know how musixvbm works internally. But my suspicion is that dealing with a slope, as you describe it, does not really play a part in the process. As I imagine it, the user would define two y-coordinates, for the beginning and the end of a beam. After MusiXTeX fixed the note spacing for a line, also the x-coordinates would be known. All musixvbm (or a descendant) would have to do now is, calculate a straight line between the two points as defined by their pairs of coordinates (plus giving it an appropriate vertical thickness and maybe adding 16th and higher beams). My guess is that musixvbm does something like that already now. And yes, this would require a new syntax. I don't think MusiXTeX's existing commands ("ibbl2g3" etc.) should be redefined. Instead, new commands should be made available for those to whom orthographical correctness matters. Does that make any sense? Wilfried -Urspr?ngliche Nachricht- Von: TeX-Music [mailto:tex-music-bounces+w.lingenberg=t- [email protected]] Im Auftrag von Hiroaki MORIMOTO Gesendet: Freitag, 30. Dezember 2022 03:42 An: Werner Icking Music Archive Betreff: Re: [Tex-music] Tales from typesetting a professional edition with MusiXTeX Hi, 1. Beams The main issues are (a) and (b) in follows: (a) floating point arithmetic such as multiplication and division to get the proper slope. For a long time I have no solution for it, however, just now, I googled on this issue and found a LaTeX2e package 'fp'. (I am now very far apart from LaTeX in my daily life for over 20 years so I know very little about recent status of LaTeX.) For my first impression, the fp package seems to be useable even on plain TeX with some small hacks to disable LaTeX2e-specific macros (\NeedsTeXFormat and \ProvidesPackage). We are not allowed to modify fp package itself for our side due to LPPL; therefore, we should put out some new idea to disable them without any harm, including consideration of MusiXTeX use inside a LaTeX document. (b) syntax. Current MusiXTeX (and all versions from its birth) deals with the beam slope value in a dynamic macro \b@p, and the final destination is a \count, i.e., integer. I think it will be a bit challenging to enable handling floating-point values: This needs modification to \setmaxinstruments (T.115 and later) and then harmful to many existing macros (especially musixps due to it's drastic diversion of use of registers). But I think it will be possible (by someone) and it is worth implementing to pass a floating point values as-is (for example, using some temporary macro instead of \count). An all-new implementation might be desirable but we should aware that it requires consensus to lost compatibility with legacy score sources and related programs such as PMX. Sincerely, Hiroaki --- [email protected] mailing list If you want to unsubscribe or look at the archives, go to https://tug.org/mailman/listinfo/tex-music
Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX
I see! Then I had an incorrect idea about the current mechanics of musixvbm. (Incidentally, I was really grateful when I discovered musixvbm! I do not want to know how the printed score would have looked without it.) Would it help to have a close look at musixps? For slurs, it calculates a Bezier curve between two given points. Maybe the algorithm could be tweaked to obtain a "beam engine". (In that case, new beam commands would probably best be incorporated into the musixps package.) Best, Wilfried > -Ursprüngliche Nachricht- > Von: TeX-Music [mailto:tex-music-bounces+w.lingenberg=t- > [email protected]] Im Auftrag von Hiroaki MORIMOTO > Gesendet: Freitag, 30. Dezember 2022 14:54 > An: Werner Icking Music Archive > Betreff: Re: [Tex-music] Tales from typesetting a professional edition > withMusiXTeX > > Yes of course! What I wished on beams in past years > are very close to your request. > > Unfortunately current task of musixvbm is just only a simple > replacement of low level drawing routine for beams > (and hairpins) from font-patchwork-based into vector > drawing (tpic specials or pdfTeX raw literal) without > changing any syntaxes. That is the limit of my skill > at that time. Also, not all coverage of dviwares. > But in fact, as you mentioned, the vector-drawing > routines would be essential to draw more correct beams. > > Sincerely, > Hiroaki > > > - Original Message - > > From: "Wilfried Lingenberg" > > To: "'Werner Icking Music Archive'" > > Date: Fri, 30 Dec 2022 04:13:06 +0100 > > Subject: Re: [Tex-music] Tales from typesetting a professional edition > > withMusiXTeX > > > > > > Hiroaki, > > > > I am not sure I understood correctly what you wrote, and certainly I do not > > know how musixvbm works internally. But my suspicion is that dealing with > a > > slope, as you describe it, does not really play a part in the process. > > > > As I imagine it, the user would define two y-coordinates, for the beginning > > and the end of a beam. After MusiXTeX fixed the note spacing for a line, > > also the x-coordinates would be known. All musixvbm (or a descendant) > would > > have to do now is, calculate a straight line between the two points as > > defined by their pairs of coordinates (plus giving it an appropriate > > vertical thickness and maybe adding 16th and higher beams). My guess is > that > > musixvbm does something like that already now. > > > > And yes, this would require a new syntax. I don't think MusiXTeX's existing > > commands ("ibbl2g3" etc.) should be redefined. Instead, new commands > should > > be made available for those to whom orthographical correctness matters. > > > > Does that make any sense? > > > > Wilfried > > > > > > > -Urspr?ngliche Nachricht- > > > Von: TeX-Music [mailto:tex-music-bounces+w.lingenberg=t- > > > [email protected]] Im Auftrag von Hiroaki MORIMOTO > > > Gesendet: Freitag, 30. Dezember 2022 03:42 > > > An: Werner Icking Music Archive > > > Betreff: Re: [Tex-music] Tales from typesetting a professional edition > > with > > > MusiXTeX > > > > > > Hi, > > > > > > 1. Beams > > > The main issues are (a) and (b) in follows: > > > (a) floating point arithmetic such as multiplication and division to get > > > the proper slope. > > > For a long time I have no solution for it, however, just now, I googled > > > on this issue and found a LaTeX2e package 'fp'. (I am now very far apart > > > from LaTeX in my daily life for over 20 years so I know very little about > > > recent status of LaTeX.) > > > For my first impression, the fp package seems to be useable even on > > > plain TeX with some small hacks to disable LaTeX2e-specific macros > > > (\NeedsTeXFormat and \ProvidesPackage). > > > We are not allowed to modify fp package itself for our side due to > > > LPPL; therefore, we should put out some new idea to disable them > > > without any harm, including consideration of MusiXTeX use inside a LaTeX > > > document. > > > > > > (b) syntax. > > > Current MusiXTeX (and all versions from its birth) deals with the beam > > > slope value in a dynamic macro \b@p, and the final destination is a > > > \count, i.e., integer. I think it will be a bit challenging to enable > > > handling floating-point values: This needs modification to > > > \setmaxinstruments (T.115 and later) and then harmful to many > &g
Re: [Tex-music] Tales from typesetting a professional edition withMusiXTeX
Yes of course! What I wished on beams in past years
are very close to your request.
Unfortunately current task of musixvbm is just only a simple
replacement of low level drawing routine for beams
(and hairpins) from font-patchwork-based into vector
drawing (tpic specials or pdfTeX raw literal) without
changing any syntaxes. That is the limit of my skill
at that time. Also, not all coverage of dviwares.
But in fact, as you mentioned, the vector-drawing
routines would be essential to draw more correct beams.
Sincerely,
Hiroaki
- Original Message -
> From: "Wilfried Lingenberg"
> To: "'Werner Icking Music Archive'"
> Date: Fri, 30 Dec 2022 04:13:06 +0100
> Subject: Re: [Tex-music] Tales from typesetting a professional edition
> withMusiXTeX
>
>
> Hiroaki,
>
> I am not sure I understood correctly what you wrote, and certainly I do not
> know how musixvbm works internally. But my suspicion is that dealing with a
> slope, as you describe it, does not really play a part in the process.
>
> As I imagine it, the user would define two y-coordinates, for the beginning
> and the end of a beam. After MusiXTeX fixed the note spacing for a line,
> also the x-coordinates would be known. All musixvbm (or a descendant) would
> have to do now is, calculate a straight line between the two points as
> defined by their pairs of coordinates (plus giving it an appropriate
> vertical thickness and maybe adding 16th and higher beams). My guess is that
> musixvbm does something like that already now.
>
> And yes, this would require a new syntax. I don't think MusiXTeX's existing
> commands ("ibbl2g3" etc.) should be redefined. Instead, new commands should
> be made available for those to whom orthographical correctness matters.
>
> Does that make any sense?
>
> Wilfried
>
>
> > -Urspr?ngliche Nachricht-
> > Von: TeX-Music [mailto:tex-music-bounces+w.lingenberg=t-
> > [email protected]] Im Auftrag von Hiroaki MORIMOTO
> > Gesendet: Freitag, 30. Dezember 2022 03:42
> > An: Werner Icking Music Archive
> > Betreff: Re: [Tex-music] Tales from typesetting a professional edition
> with
> > MusiXTeX
> >
> > Hi,
> >
> > 1. Beams
> > The main issues are (a) and (b) in follows:
> > (a) floating point arithmetic such as multiplication and division to get
> > the proper slope.
> > For a long time I have no solution for it, however, just now, I googled
> > on this issue and found a LaTeX2e package 'fp'. (I am now very far apart
> > from LaTeX in my daily life for over 20 years so I know very little about
> > recent status of LaTeX.)
> > For my first impression, the fp package seems to be useable even on
> > plain TeX with some small hacks to disable LaTeX2e-specific macros
> > (\NeedsTeXFormat and \ProvidesPackage).
> > We are not allowed to modify fp package itself for our side due to
> > LPPL; therefore, we should put out some new idea to disable them
> > without any harm, including consideration of MusiXTeX use inside a LaTeX
> > document.
> >
> > (b) syntax.
> > Current MusiXTeX (and all versions from its birth) deals with the beam
> > slope value in a dynamic macro \b@p, and the final destination is a
> > \count, i.e., integer. I think it will be a bit challenging to enable
> > handling floating-point values: This needs modification to
> > \setmaxinstruments (T.115 and later) and then harmful to many
> > existing macros (especially musixps due to it's drastic diversion
> > of use of registers).
> > But I think it will be possible (by someone) and it is worth implementing
> > to pass a floating point values as-is (for example, using some
> > temporary macro instead of \count).
> > An all-new implementation might be desirable but we should aware that
> > it requires consensus to lost compatibility with legacy score sources
> > and related programs such as PMX.
> >
> >
> > Sincerely,
> > Hiroaki
>
>
> ---
> [email protected] mailing list
> If you want to unsubscribe or look at the archives, go to
> https://tug.org/mailman/listinfo/tex-music
---
[email protected] mailing list
If you want to unsubscribe or look at the archives, go to
https://tug.org/mailman/listinfo/tex-music
