trevorbaca
commented
3 years ago Hi @gilbertohasnofb
By design. Though keep reading for thoughts about future tightening of the model.
Note that LilyPond scopes the context of LilyPond bar lines to the LilyPond score. We see that this is the case if we modify your first example to attach only a single bar line, and then look at the resulting LilyPond output:
string = r"\time 4/4 R1 R1 \time 6/4 R1 * 6/4 R1 * 6/4"
staff_1 = abjad.Staff(string)
staff_2 = abjad.Staff(string)
score = abjad.Score([staff_1, staff_2])
abjad.attach(abjad.BarLine("||"), staff_1[1])
#abjad.attach(abjad.BarLine("||"), staff_2[1])
abjad.f(score)
\new Score
<<
\new Staff
{
\time 4/4
R1
R1
\bar "||"
\time 6/4
R1 * 3/2
R1 * 3/2
}
\new Staff
{
\time 4/4
R1
R1
\time 6/4
R1 * 3/2
R1 * 3/2
}
>>
The LilyPond \bar command appears in only one staff. But of course LilyPond engraves the double bar in both staves.
Abjad does, in fact, model this:
bar_line = abjad.BarLine("||")
bar_line.context
'Score'Then, at attach-time Abjad checks for "contention" between two indicators that happen at the same moment but are "scoped" high enough (like at the level of the score) that they clash.
That check that Abjad is making is unmotivated in the example here (because the bar lines both "mean" the same thing: they're double bar lines). But imagine that you tried to attach a double bar in one staff and then a final bar in the other staff (at the same time). Then it's actually quite helpful that Abjad is alerting you to the fact that you're effectively trying to overwrite your own intentions.
(Even more so if you imagine setting conflicting metronome mark indicators at the same moment in different staves. Metronome marks are also scoped at the score.)
So the check will stay.
Your second example is different, however: my intention is to forbid the second example. I just haven't gotten around to it yet. I think the way it will work is this: when you go to attach a bar line to a note, rest, chord Abjad will check and see if the note, rest, chord is (ultimately) enclosed in a score. If yes, you can attach. If no, you'll get an exception.
I know on first glance all this might "feel" like restricting user functionality. But think about it for a moment or two and you'll realize the restriction is actually super helpful!
While we're at it, there's an analogous behavior with time signatures. I'll point it out here. And time signatures will also be subject to a slight behavior change when I get around to this part of the code.
Recall that time signatures are scoped to the staff context in LilyPond. This is also true in Abjad. Now, check out the difference between these two examples.
This does what you expect:
staff = abjad.Staff("c'4 d' e'")
time_signature = abjad.TimeSignature((3, 4))
abjad.attach(time_signature, staff[0])
abjad.f(staff)
\new Staff
{
\time 3/4
c'4
d'4
e'4
}This is probably a surprise!
voice = abjad.Voice("c'4 d' e'")
time_signature = abjad.TimeSignature((3, 4))
abjad.attach(time_signature, voice[0])
abjad.f(voice)
\new Voice
{
%%% \time 3/4 %%%
c'4
d'4
e'4
}Crazy, huh?
This is ancient code I wrote a million years ago. What's going on here is that I'm forbidding the time signature from visibly appearing in LilyPond until the Abjad user encloses the whole thing in an Abjad staff. Notice that now stuff works how you'd expect, with no commented-out time signature:
staff = abjad.Staff([voice])
abjad.f(staff)
\new Staff
{
\new Voice
{
\time 3/4
c'4
d'4
e'4
}
}The behavior's less than ideal because it's too implicit: Abjad users can do all this stuff without realizing what's happening behind the scenes. (Quite possibly being unaware that a time signature won't show up.)
Much better is the bar line behavior you stumbled upon: at least the exception trains users into how to work with the system!
Finally to note is that there's another very important motivator to all this context-checking at attach-time. When you start using abjad.get.effective() [which was abjad.inspect().effective in Abjad 3.1] all this "effective indicator" stuff only works when an explicit abjad.Staff or abjad.Score context is present.
This works exactly as you expect:
staff = abjad.Staff("c'4 d' e'")
time_signature = abjad.TimeSignature((3, 4))
abjad.attach(time_signature, staff[0])
for note in staff:
effective_time_signature = abjad.get.effective(note, abjad.TimeSignature)
print(note, effective_time_signature)
c'4 3/4
d'4 3/4
e'4 3/4But this doesn't:
voice = abjad.Voice("c'4 d' e'")
time_signature = abjad.TimeSignature((3, 4))
abjad.attach(time_signature, voice[0])
for note in voice:
effective_time_signature = abjad.get.effective(note, abjad.TimeSignature)
print(note, effective_time_signature)
c'4 3/4
d'4 None
e'4 NoneThis is basically Abjad pushing you to make sure there's an explicit abjad.Staff present when you're working with indicators that are naturally scoped at the staff, and also that you have an explicit abjad.Score present when you are working with indicators that are naturally scoped at the score.
When I add the generalized raise-an-exception-at-attach-time code then the behavior will be consistent, and the system will nudge you towards having explicit contexts.
gilbertohasnofb
When dealing with multiple staves that belong to an
abjad.Score, attempting to attach a bar line to more than one stave at a same given bar will result in an exception:The code above produces:
Attaching the barlines to the same positions but before adding the staves to a score will not result in an exception:
Is the first case happening by design or is that a bug? It seems odd that once a staff is part of a score it cannot receive barlines if another staff already has one at that given bar.