Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect rendering for multi-voice Clef Change #95

Open
arshiacont opened this issue Sep 27, 2019 · 7 comments
Open

Incorrect rendering for multi-voice Clef Change #95

arshiacont opened this issue Sep 27, 2019 · 7 comments

Comments

@arshiacont
Copy link

Unit test:

{[ \staff<1> 
   (* meas. 1 *)  \clef<"g2"> {e/1, b/1  }
 \bar
   (* meas. 2 *)  \clef<"f4"> \restFormat<dy=-2>( _/4)
 \clef<"g2">  {e/2, g/2, c2/2  } {e1/4, g/4, c2/4  } ]
 , 
[ \staff<1> 
   (* meas. 1 *)  \clef<"g2"> empty/1 \bar
   (* meas. 2 *)  \clef<"f4"> {e-2/1, e-1/1  } ]
  }

leads to:
image

whereas the second voice alone is
image

corresponding to:

{[ \staff<1> 
   (* meas. 1 *)  \clef<"g2"> empty/1 \bar
   (* meas. 2 *)  \clef<"f4"> {e-2/1, e-1/1  } ]}
@arshiacont
Copy link
Author

I thought for a second that the behaviour is coherent sincethe F clef part of Voice 2 spans the "G CLEF" part of Voice 1. But reducing that part to the clef span results to the same behaviour:

{[ \staff<1> 
   (* meas. 1 *)  \clef<"g2"> {e/1, b/1  }
 \bar
   (* meas. 2 *)  \clef<"f4"> \restFormat<dy=-2>( _/4)
 \clef<"g2">  {e/2, g/2, c2/2  } {e1/4, g/4, c2/4  } ]
 , 
[ \staff<1> 
   (* meas. 1 *)  \clef<"g2"> empty/1 \bar
   (* meas. 2 *)  \clef<"f4"> {e-2/4, e-1/4  } empty/2 empty/4 ]
  }

@dfober
Copy link
Member

dfober commented Dec 2, 2019

I strongly discourage the use of keys in this context. In fact, it would seem that it is necessary to put at least one note in F clef on the staff 1 to correct the problem. But the notation can become very ambiguous:

{
[
	\clef<"g2"> { e/1, g }
	% the following uses the f clef (that is on the second voice)
	_/4 e-0/4
	% and back to explicit g clef
	\clef<"g2">  { e1/2, g, c2 } { e1/4, g, c2 } 
] , 
[
	\staff<1>  empty/1 \bar
	\clef<"f4"> { e-2/4, e-1 }
]
}

@arshiacont
Copy link
Author

Then what would be the correct way to write such a score without adding a new note that the composer hasn't written?? :)
To me, there should be some sort of Clef/Position check in the AR to determine the correct clef at each time-position between voices to avoid this.
In fact, this is how I manage to do it in xml2guido (I do book-keeping of (clef, position) for each voice in a staff).

@dfober
Copy link
Member

dfober commented Dec 5, 2019

it would seem that it is necessary to put at least one note in F clef on the staff 1

was not intended as a solution, just as a debugging remark. But the ambiguity in the notation remains.
Sorry for the confusion.

@arshiacont
Copy link
Author

No problem. Let me know if I can contribute / test.

@arshiacont
Copy link
Author

Notes: Behaviour only on chords.

@arshiacont
Copy link
Author

Another example for the same problem where the "chord" annotated with (* PROBLEM*) in measure 2 is being rendered in a different clef than indicated:

{
[ \staff<1> 
   (* meas. 1 *)  
   \clef<"f4"> \key<2>  
   \stemsUp d0/8. 
   \clef<"g2">  \tieBegin:1<curve="down"> d1/16 d/8 \tieEnd:1
  \tieBegin:1<curve="up"> b/2. \bar
 
   (* meas. 2 *)  \stemsUp \beamsOff b/4. \tieEnd:1 
   \tieBegin:1<curve="up"> b/4. b/8 \tieEnd:1 
   \clef<"f4"> 
   empty/8 empty/8]
 , 
[ \staff<1> 
(* meas. 1 *)  empty*3/8 \stemsDown 
\beamBegin:1 d/8. 
 d/16 b0/8  \beamEnd:1 \tieBegin:1<curve="down"> d1/4. \bar
(* meas. 2 *) d/4. \tieEnd:1 
\stemsDown \beamBegin:1 b0/8. d/16 b0/8 \beamEnd:1  
 { d1/8., f#/8.  } (* PROBLEM *)
  \beamBegin:1  f#/16 f#0/8\beamEnd:1 
  ]
}

image

NOTE: This only happens if that event is a Chord... . If I change it to a note, everything is gonna be fine (here changing that chord { d1/8., f#/8. } to d1/8.:

image

@dfober If you guide on where to look, I might be able to fix this as I'm getting more and more acquainted with the library! ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants