Re: Chord names clean-up; no more Banter, exceptionsPartial or \powerChords

[David Kastrup]

Flaming Hakama by Elaine  writes:

>> -- Forwarded message --
>> From: d...@gnu.org
>> To: v.villen...@gmail.com
>> Cc: lilypond-devel@gnu.org, re...@codereview-hr.appspotmail.com
>> Date: Tue, 07 Jan 2020 14:06:51 -0800
>> Subject: Re: Chord names clean-up; no more Banter, exceptionsPartial or
>> \powerChords. (issue 363880043 by v.villen...@gmail.com)
>>
>> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py
>> File python/convertrules.py (right):
>>
>>
>> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py#newcode3980
>> python/convertrules.py:3980
>> :
>> if re.search
>> (r"#[banter|jazz]-chord-names", str):
>> I have no idea what this regexp is actually supposed to be/do.  But it
>> needs to get fixed.  Any idea what this should be instead?
>>
>> As it is, it matches a # followed by one of the letters abejntrz| and
>> then -chord-names .  This is very likely not what is intended here.
>>
>> https://codereview.appspot.com/363880043/
>>
>
> My guess as to the intention is that it should match either
> "#banter-chord-names" or "#jazz-chord-names".
>
> Although, it is unclear why those strings are important.
>
> Seems like they just mistakenly used square brackets instead of parenthesis
> for grouping in the regular expression.

Ah yes, that makes sense.  Of course, those patterns are garbage as well
since the correct names would be banter-chordnames and jazz-chordnames.
But at least it appears like we are getting somewhere.

-- 
David Kastrup

Re: move some OLL functions to vanilla LilyPond? [was: A suggestion: add \rf to built-in dynamics]

[Urs Liska]

Am 7. Januar 2020 23:53:42 MEZ schrieb Andrew Bernard 
:
>Hi Malte,
>
>\shapeII is a function I use heavily - heavily - in all my work. It's
>indispensable for me at least. I'm very familiar with OpenLilyLib, and
>contribute a bit to it, so it's not an issue for me, but that's a
>function that really ought to go into lilypond core in my view.
>
>As for newbies not using OpenLilyLib, you can't make such as assertion
>because you cannot say what their level of experience with computers
>and software is, so I don't think that's a pertinent point.
>
>Perhaps ois the NR had instructions for how to install and use
>OpenLilyLib as a powerful addon, then it make have more 'street cred'
>and become more widely used in the way it is intended, not just copy
>and paste of bits. I do think people see it as far outside Lilypond
>and don't want to get involved, somehow.

I agree that openLilyLib could be introduced in the documentation or at least 
on the website.
However, I don't think OLL is ready for that. I I wouldn't want it to be 
officially endorsed as long as it is not at least basically documented.

Urs
>
>Andrew
>
>
>On Sat, 4 Jan 2020 at 22:34, Malte Meyn  wrote:
>
>> Am 04.01.20 um 12:29 schrieb Malte Meyn:
>
>> One could argue that openlilylib can be installed easily but users
>might
>> not want to install “addons” for basic tasks like this. (In fact, I
>have
>> never used openlilylib apart from copying definitions from the
>> definitions.ily files and I see myself as a advanced user; I don’t
>think
>> that many newbies will use oll …)
>>
>> Same argument for \shapeII.
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Chord names clean-up; no more Banter, exceptionsPartial or \powerChords

[Flaming Hakama by Elaine]

> -- Forwarded message --
> From: d...@gnu.org
> To: v.villen...@gmail.com
> Cc: lilypond-devel@gnu.org, re...@codereview-hr.appspotmail.com
> Date: Tue, 07 Jan 2020 14:06:51 -0800
> Subject: Re: Chord names clean-up; no more Banter, exceptionsPartial or
> \powerChords. (issue 363880043 by v.villen...@gmail.com)
>
> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py
> File python/convertrules.py (right):
>
>
> https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py#newcode3980
> python/convertrules.py:3980
> :
> if re.search
> (r"#[banter|jazz]-chord-names", str):
> I have no idea what this regexp is actually supposed to be/do.  But it
> needs to get fixed.  Any idea what this should be instead?
>
> As it is, it matches a # followed by one of the letters abejntrz| and
> then -chord-names .  This is very likely not what is intended here.
>
> https://codereview.appspot.com/363880043/
>

My guess as to the intention is that it should match either
"#banter-chord-names" or "#jazz-chord-names".

Although, it is unclear why those strings are important.

Seems like they just mistakenly used square brackets instead of parenthesis
for grouping in the regular expression.


HTH,

Elaine Alt
415 . 341 .4954   "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 23:21, Marnen Laibow-Koser  wrote:
> 
>>> Also, of course, the point is to do this in a way that doesn’t require
>> the end users to have MacPorts.
>> 
>> The Emacs.app seemed to be working when put in /Applications/ so it might
>> be distributed independently.
> 
> Right, unless it contains absolute paths to MacPorts-installed libraries
> outside the bundle (which would be horrible practice but I think is
> allowed).

Yes, it does, so MacPorts is required for it to work.

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Tue, Jan 7, 2020 at 5:58 PM Carl Sorensen  wrote:
[...]

> Here's a discussion about how to create a MacOS app bundle for Gnu Octave
> based on a MacPorts build similar to Hans's.
>
> I haven't worked through it, but I thought it might be a useful guide.  In
> particular, there is a shell script that is used to copy the MacPorts
> binaries into an app bundle.
>
> https://wiki.octave.org/Create_a_MacOS_X_App_Bundle_Using_MacPorts


I’ve seen that, but I’m not sure it’s directly applicable to LilyPond.  If
you think you can adapt something from it for our use, though, I’d be
delighted to see a suitable script!


>
> HTH,
>
> Carl


Best,

>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Carl Sorensen]

On 1/7/20, 3:22 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" 
 wrote:

On Tue, Jan 7, 2020 at 5:15 PM Hans Åberg  wrote:

>
> > On 7 Jan 2020, at 22:20, Marnen Laibow-Koser  wrote:
> >
> > On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg  wrote:
> > [...]
> >
> > FYI, it is possible to build apps using MacPorts, for example, there is
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems
> working if copied out of that directory.
> >
> > Thanks, I looked for something like that but didn’t see a general
> method.  Do you have any idea how this is done?
>
> No.


Yeah, neither do I.  Time to look at build scripts.

Here's a discussion about how to create a MacOS app bundle for Gnu Octave based 
on a MacPorts build similar to Hans's.

I haven't worked through it, but I thought it might be a useful guide.  In 
particular, there is a shell script that is used to copy the MacPorts binaries 
into an app bundle.

https://wiki.octave.org/Create_a_MacOS_X_App_Bundle_Using_MacPorts

HTH,

Carl
 

Re: move some OLL functions to vanilla LilyPond? [was: A suggestion: add \rf to built-in dynamics]

[Andrew Bernard]

Hi Malte,

\shapeII is a function I use heavily - heavily - in all my work. It's
indispensable for me at least. I'm very familiar with OpenLilyLib, and
contribute a bit to it, so it's not an issue for me, but that's a
function that really ought to go into lilypond core in my view.

As for newbies not using OpenLilyLib, you can't make such as assertion
because you cannot say what their level of experience with computers
and software is, so I don't think that's a pertinent point.

Perhaps ois the NR had instructions for how to install and use
OpenLilyLib as a powerful addon, then it make have more 'street cred'
and become more widely used in the way it is intended, not just copy
and paste of bits. I do think people see it as far outside Lilypond
and don't want to get involved, somehow.

Andrew


On Sat, 4 Jan 2020 at 22:34, Malte Meyn  wrote:

> Am 04.01.20 um 12:29 schrieb Malte Meyn:

> One could argue that openlilylib can be installed easily but users might
> not want to install “addons” for basic tasks like this. (In fact, I have
> never used openlilylib apart from copying definitions from the
> definitions.ily files and I see myself as a advanced user; I don’t think
> that many newbies will use oll …)
>
> Same argument for \shapeII.
>

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Tue, Jan 7, 2020 at 5:15 PM Hans Åberg  wrote:

>
> > On 7 Jan 2020, at 22:20, Marnen Laibow-Koser  wrote:
> >
> > On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg  wrote:
> > [...]
> >
> > FYI, it is possible to build apps using MacPorts, for example, there is
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems
> working if copied out of that directory.
> >
> > Thanks, I looked for something like that but didn’t see a general
> method.  Do you have any idea how this is done?
>
> No.


Yeah, neither do I.  Time to look at build scripts.


>
> > Also, of course, the point is to do this in a way that doesn’t require
> the end users to have MacPorts.
>
> The Emacs.app seemed to be working when put in /Applications/ so it might
> be distributed independently.


Right, unless it contains absolute paths to MacPorts-installed libraries
outside the bundle (which would be horrible practice but I think is
allowed).


>
> But Frescobaldi seems a good choice. It needs a lilypond binary. By
> suggestions of the FHS standard I and Werner Lemberg decided to put in
> /opt/lilypond/bin/lilypond.


I plan to use LilyPad like the current Mac distributions do.  I agree that
Frescobaldi might be a better choice in the long run.

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 22:35, Jonas Hahnfeld via Discussions on LilyPond 
> development  wrote:
> 
> By far no Mac expert, but if dynamic libraries are problematic would it
> help to have a static executable? I experimented with such a setup for
> Linux, and I eventually got it to build. Not sure what the status of my
> script is, I can try to dig it up…

Dynamic libraries have long been the default on MacOS, but the paths are 
hardcoded into the binary. So I figure an app needs relative paths to its 
resources.

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 22:20, Marnen Laibow-Koser  wrote:
> 
> On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg  wrote:
> [...]
> 
> FYI, it is possible to build apps using MacPorts, for example, there is 
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems 
> working if copied out of that directory.
> 
> Thanks, I looked for something like that but didn’t see a general method.  Do 
> you have any idea how this is done?

No.

> Also, of course, the point is to do this in a way that doesn’t require the 
> end users to have MacPorts. 

The Emacs.app seemed to be working when put in /Applications/ so it might be 
distributed independently.

But Frescobaldi seems a good choice. It needs a lilypond binary. By suggestions 
of the FHS standard I and Werner Lemberg decided to put in 
/opt/lilypond/bin/lilypond.

Re: Chord names clean-up; no more Banter, exceptionsPartial or \powerChords. (issue 363880043 by v.villen...@gmail.com)

[dak]

https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/363880043/diff/80001/python/convertrules.py#newcode3980
python/convertrules.py:3980: if re.search
(r"#[banter|jazz]-chord-names", str):
I have no idea what this regexp is actually supposed to be/do.  But it
needs to get fixed.  Any idea what this should be instead?

As it is, it matches a # followed by one of the letters abejntrz| and
then -chord-names .  This is very likely not what is intended here.

https://codereview.appspot.com/363880043/

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Tue, Jan 7, 2020 at 4:35 PM Jonas Hahnfeld  wrote:
[...]

> By far no Mac expert, but if dynamic libraries are problematic would it
> help to have a static executable?


Maybe.  If I understand correctly, though, .app bundles are *designed* to
easily contain dylibs, frameworks, and other dependencies, so (assuming
something like dylibbundler can help automate the packaging process) that’s
the least of our problems.

Nontechnical Mac OS X users are not accustomed to dealing with “naked”
executables not contained in .app bundles.  The GUI doesn’t even provide a
good way of doing so; it’s just not the way the OS works.

In other words, for typical users, the executable is going to have to get
packaged in an .app bundle regardless of whether it’s statically or
dynamically linked.

I experimented with such a setup for
> Linux, and I eventually got it to build. Not sure what the status of my
> script is, I can try to dig it up...


That could be useful; I’d like to see it if possible.  Thanks!


>
> Jonas


Best,

>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Dienstag, den 07.01.2020, 15:52 -0500 schrieb Marnen Laibow-Koser:
> On Thu, Oct 17, 2019 at 7:08 PM Marnen Laibow-Koser <
> mar...@marnen.org
> >
> wrote:
> 
> > 
> > On Thu, Oct 17, 2019 at 6:52 PM Hans Åberg <
> > haber...@telia.com
> > > wrote:
> > 
> > > 
> > > > On 18 Oct 2019, at 00:30, Marnen Laibow-Koser <
> > > > mar...@marnen.org
> > > > >
> > > 
> > > wrote:
> > > > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg <
> > > > haber...@telia.com
> > > > > wrote:
> > > > 
> > > > > I made an installer into /opt/lilypond/ on MacOS 10.15, which you 
> > > > > might
> > > > > try out.
> > > > 
> > > > 
> > > > With port mdmg/mpkg, or some other way?
> > > 
> > > Yes, see
> > > https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html
> > > 
> > > 
> > > > How do I try this out?
> > > 
> > > Try this link:
> > > https://web2.storegate.com/share/oCQjV4r
> > > 
> > > 
> > 
> > Awesome, thanks; I’ll try it when I get a chance. I still want to get an
> > .app bundle built, but it’s good to know that the mdmg approach actually
> > works as advertised. :)
> > 
> 
> Some updates.  For the time being, at least, I've changed approaches.
> Since I couldn't understand much of GUB's OS detection logic, and no one
> seemed able to help with that, I abandoned GUB entirely for my latest
> attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
> Werner!).
> 
> My current plan is now to build a 64-bit build of LilyPad.app and put the
> LilyPond binary in there, then use
> https://github.com/auriamg/macdylibbundler
>  or some similar tool to package
> the dylib dependencies in the app bundle.  While it's overcomplicated
> thanks to poor documentation and obsolescent ways of doing things, this
> seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
> bundle that will run on Catalina.
> 
> Once I produce a usable Mac 64-bit build, I intend to automate the process
> (probably with something like Buildkite) and be able to produce usable
> builds for every future release.
> 
> Thoughts?  Suggestions?  Considerations?  Anyone want to help?

By far no Mac expert, but if dynamic libraries are problematic would it
help to have a static executable? I experimented with such a setup for
Linux, and I eventually got it to build. Not sure what the status of my
script is, I can try to dig it up...

Jonas


signature.asc
Description: This is a digitally signed message part

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Tue, Jan 7, 2020 at 4:16 PM Hans Åberg  wrote:
[...]

>
> FYI, it is possible to build apps using MacPorts, for example, there is
> emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems
> working if copied out of that directory.


Thanks, I looked for something like that but didn’t see a general method.
Do you have any idea how this is done?

Also, of course, the point is to do this in a way that doesn’t require the
end users to have MacPorts.

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Hans Åberg]

> On 7 Jan 2020, at 21:52, Marnen Laibow-Koser  wrote:
> 
> Some updates.  For the time being, at least, I've changed approaches.
> Since I couldn't understand much of GUB's OS detection logic, and no one
> seemed able to help with that, I abandoned GUB entirely for my latest
> attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
> Werner!).
> 
> My current plan is now to build a 64-bit build of LilyPad.app and put the
> LilyPond binary in there, then use
> https://github.com/auriamg/macdylibbundler or some similar tool to package
> the dylib dependencies in the app bundle.  While it's overcomplicated
> thanks to poor documentation and obsolescent ways of doing things, this
> seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
> bundle that will run on Catalina.

FYI, it is possible to build apps using MacPorts, for example, there is 
emacs-app that installs Emacs.app in /Applications/MacPorts/, and it seems 
working if copied out of that directory.

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Oct 17, 2019 at 7:08 PM Marnen Laibow-Koser 
wrote:

>
>
> On Thu, Oct 17, 2019 at 6:52 PM Hans Åberg  wrote:
>
>>
>>
>> > On 18 Oct 2019, at 00:30, Marnen Laibow-Koser 
>> wrote:
>> >
>> > On Thu, Oct 17, 2019 at 6:24 PM Hans Åberg  wrote:
>> >
>> >> I made an installer into /opt/lilypond/ on MacOS 10.15, which you might
>> >> try out.
>> >
>> >
>> > With port mdmg/mpkg, or some other way?
>>
>> Yes, see
>> https://lists.gnu.org/archive/html/lilypond-devel/2019-03/msg00065.html
>>
>> > How do I try this out?
>>
>> Try this link:
>> https://web2.storegate.com/share/oCQjV4r
>>
>
> Awesome, thanks; I’ll try it when I get a chance. I still want to get an
> .app bundle built, but it’s good to know that the mdmg approach actually
> works as advertised. :)
>

Some updates.  For the time being, at least, I've changed approaches.
Since I couldn't understand much of GUB's OS detection logic, and no one
seemed able to help with that, I abandoned GUB entirely for my latest
attempt and used MacPorts to build a 64-bit LilyPond binary (thanks,
Werner!).

My current plan is now to build a 64-bit build of LilyPad.app and put the
LilyPond binary in there, then use
https://github.com/auriamg/macdylibbundler or some similar tool to package
the dylib dependencies in the app bundle.  While it's overcomplicated
thanks to poor documentation and obsolescent ways of doing things, this
seems like a potentially easy way to get a usable 64-bit LilyPond Mac .app
bundle that will run on Catalina.

Once I produce a usable Mac 64-bit build, I intend to automate the process
(probably with something like Buildkite) and be able to produce usable
builds for every future release.

Thoughts?  Suggestions?  Considerations?  Anyone want to help?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

PATCHES - Countdown for January 7th

[pkx166h]

Hello,

Here is the current patch countdown list. The next countdown will be on
January 9th.

A quick synopsis of all patches currently in the review process can be
found here:

http://philholmes.net/lilypond/allura/




  Push:

5650 Use C++11 "override" keyword - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5650
http://codereview.appspot.com/551320043

5649 flower: Add boolean return value to 'Rational' class. - Werner LEMBERG
https://sourceforge.net/p/testlilyissues/issues/5649
http://codereview.appspot.com/581400043

5601 Changes.tely (2.20): \afterGrace command got an optional argument
that should be documented - James Lowe
https://sourceforge.net/p/testlilyissues/issues/5601
http://codereview.appspot.com/551260043


  Countdown:

No patches on Countdown at this time.


  Review:

No Patches in review at this time.


  New:

No New patches at this time.


  Waiting:

5309 find_score_context () and find_global_context () - Dan Eble
https://sourceforge.net/p/testlilyissues/issues/5309
http://codereview.appspot.com/561290043




***


Regards,

James

Re: lilypond's python code analysis by LGTM.com

[Jonas Hahnfeld]

Am Dienstag, den 07.01.2020, 20:24 +0100 schrieb David Kastrup:
> David Kastrup <
> d...@gnu.org
> > writes:
> 
> > Werner LEMBERG <
> > w...@gnu.org
> > > writes:
> > 
> > > This looks interesting!
> > > 
> > >   
> > > https://lgtm.com/projects/g/lilypond/lilypond
> > > 
> > 
> > I'll agree that a number of those (not all) look worth changing.
> 
> I'll go through some.

About half of them is not valid anymore (string exceptions are gone,
division is now compatible with Python 3, etc.). The reason is that the
repository at https://github.com/lilypond/lilypond hasn't been updated
since June. Not sure who's responsible / able to do this


signature.asc
Description: This is a digitally signed message part

Re: lilypond's python code analysis by LGTM.com

[David Kastrup]

David Kastrup  writes:

> Werner LEMBERG  writes:
>
>> This looks interesting!
>>
>>   https://lgtm.com/projects/g/lilypond/lilypond
>
> I'll agree that a number of those (not all) look worth changing.

I'll go through some.

-- 
David Kastrup

Re: lilypond's python code analysis by LGTM.com

[David Kastrup]

Werner LEMBERG  writes:

> This looks interesting!
>
>   https://lgtm.com/projects/g/lilypond/lilypond

I'll agree that a number of those (not all) look worth changing.

-- 
David Kastrup

lilypond's python code analysis by LGTM.com

[Werner LEMBERG]

This looks interesting!

  https://lgtm.com/projects/g/lilypond/lilypond


Werner

Re: Weird intermediate context creation

[Dan Eble]

On Jan 7, 2020, at 09:26, Dan Eble  wrote:
> 
> On Jan 6, 2020, at 17:01, David Kastrup  wrote:
>> 
 If I write
 
 << \new Staff { c' } \new Voice { d' } >>
 
 should the d' insinuate itself into the same staff as the c' ?
>>> 
>>> You didn't specify a staff for the d', so I don't see grounds for
>>> dissatisfaction if LilyPond were to do that.
>> 
>> It's the same as
>> 
>> << \new StaffGroup { c' } \new Staff { d' } >>
>> 
>> where it clearly seems inappropriate to make the Staff be a part of the
>> StaffGroup.
> 
> The context schema makes these cases different.
> 
> In the new-Voice case, the Score does not accept the Voice directly.  A Staff 
> is required between the Staff and the Voice, so the question "Which Staff?" 
> arises.

Oops: "A Staff is required between the SCORE and the Voice …"

> 
> In the new-Staff case, the Score accepts the Staff.  Placing it in a 
> StaffGroup is not considered.
> 
> (Thanks for the rest of your reply too; I haven't digested it all yet.)
> — 
> Dan
> 

Re: Weird intermediate context creation

[Dan Eble]

On Jan 6, 2020, at 17:01, David Kastrup  wrote:
> 
>>> If I write
>>> 
>>> << \new Staff { c' } \new Voice { d' } >>
>>> 
>>> should the d' insinuate itself into the same staff as the c' ?
>> 
>> You didn't specify a staff for the d', so I don't see grounds for
>> dissatisfaction if LilyPond were to do that.
> 
> It's the same as
> 
> << \new StaffGroup { c' } \new Staff { d' } >>
> 
> where it clearly seems inappropriate to make the Staff be a part of the
> StaffGroup.

The context schema makes these cases different.

In the new-Voice case, the Score does not accept the Voice directly.  A Staff 
is required between the Staff and the Voice, so the question "Which Staff?" 
arises.

In the new-Staff case, the Score accepts the Staff.  Placing it in a StaffGroup 
is not considered.

(Thanks for the rest of your reply too; I haven't digested it all yet.)
— 
Dan