[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Manipulating instrument names and staff group names

From: Jean Abou Samra
Subject: Re: Manipulating instrument names and staff group names
Date: Thu, 4 Nov 2021 22:36:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2

Le 04/11/2021 à 21:18, Lukas-Fabian Moser a écrit :

But I'm at a bit of a loss about your notion of a StaffMonoid. All sorts of math puns aside (a CommutativeStaffRing of nonzero characteristic especially for engraving _Le Spec de la Rose_ by Berlioz) - what do you mean by a StaffMonoid?
There is absolutely nothing besides the math pun. It was too tempting given that I know both Kieren and yourself have some background in that.


Just goes to show that it's possible to both get a joke completely and still miss it anyway. Lack of facial expressions is helpful in that regard.

It was meant to be the kind of humor spoken on a very
serious tone. Too bad that this doesn't hand on well
over the Internet.

I would put Span_arpeggio_engraver in StaffCollection. It makes sense for something intended at logically grouping staves, and doesn't harm after all: as long as the user does not \set StaffCollection.connectArpeggios, it has no effect.

Ok, done.

I also noticed that StaffCollection probably shouldn't have the Vertical_align_engraver, since this causes vertical spacing to be different. The original idea was that uncommenting in

\version "2.23.4"

bla = \repeat unfold 30 c'1

  \new Staff \bla
  \new StaffCollection \with {
    \override StaffSymbol.color = #blue
    instrumentName = Test
    \new Staff \bla
    \new Staff \bla
  \new Staff \bla

shouldn't change spacing at all.

Oh, was it? What is the point of StaffCollection then?
I thought it was meant to group staves from a logical
group of instruments. Don't you want to adjust the
vertical spacing for that?

Also, don't forget \alias StaffCollection in the definition of StaffGroup so users can write commands as \set StaffCollection.whatever = ... or \override StaffCollection.Whatever.whatnot = ... and have them work in all contexts that group staves.

Is that really desirable? I notice that PianoStaff is \alias'ed to GrandStaff, which makes sense somehow, but GrandStaff is _not_ \alias'ed to StaffGroup, and neither is ChoirStaff. (I have no preference in that regard, it's just I'm unsure about the consequences.)

My spontaneous reaction would be to think that, while
StaffGroup, ChoirStaff, GrandStaff and PianoStaff are
four different ways of grouping staves with no
conceptual hierarchy (even though I changed
so it used \StaffGroup to conveniently define the others,
but this does not end up as a relationship involving StaffGroup
as any kind of parent), StaffCollection encompasses all
four ways -- in OOP terms: a superclass with four
distinct subclasses. That said, it all depends on the
use cases, and as such it is well up to you to define
what the feature looks like and the problems it addresses.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]