Mixed chord/note mode
We had this discussion a longer time ago, with chords and notes
conflicting in that : is used for tremolo notation, too.
Now I've had the idea that _inside_ of < > we don't need to notate
durations and thus < c: > would be unambiguous.
Of course the reality is that :8 is not part of the duration but a
separate tremolo event that is interpreted by the Stem_engraver . It
can be entered even inside a chord but is ignored there.
One can also write things like
trem=:8
{ c \trem }
Ouch.
Now never mind the inconsistency: as we don't _need_ stem tremolos
inside of chords, I'd lean towards hijacking colon there in \notemode .
Strictly speaking that is an incompatibility, in practice I consider it
very unlikely that anybody used this for entering stuff that is not
typeset by default.
Chord modifiers are a bit of a puzzlement to figure out later, but
something like would (I think) be a major chord, a minor
chord and so on. With regard to positioning and inversions, I'd lean
towards interpreting the octave information in this entry mode: that
makes it feasible to mix chords and single notes without ambiguity.
Polychords? Would want weeding out duplicate notes.
This is just a handwaving sketch about entry; conveying information to
the chord namer would remain an open issue at first and may possibly be
better tackled in the context of integrating the pending GSoC chord
work.
Does that sound reasonable/useful/whatever ?
--
David Kastrup
Re: Mixed chord/note mode
Hi David, > _inside_ of < > we don't need to notate durations > I'd lean towards hijacking colon there in \notemode . > This is just a handwaving sketch about entry; conveying information to > the chord namer would remain an open issue at first and may possibly be > better tackled in the context of integrating the pending GSoC chord work. > > Does that sound reasonable/useful/whatever ? Sounds both reasonable and useful to me! Is there any chance that in the future we might want to add an easy UI for different duration-log elements in a single chord (e.g., for violin triple-stops)? That might be something like , right? That's the only potential stumbling-block I can currently foresee in this approach. Cheers, Kieren.
Re: Mixed chord/note mode
Kieren MacMillan writes: > Hi David, > >> _inside_ of < > we don't need to notate durations > >> I'd lean towards hijacking colon there in \notemode . > >> This is just a handwaving sketch about entry; conveying information to >> the chord namer would remain an open issue at first and may possibly be >> better tackled in the context of integrating the pending GSoC chord work. >> >> Does that sound reasonable/useful/whatever ? > > Sounds both reasonable and useful to me! > > Is there any chance that in the future we might want to add an easy UI > for different duration-log elements in a single chord (e.g., for > violin triple-stops)? That might be something like , right? > That's the only potential stumbling-block I can currently foresee in > this approach. I don't see any reason not to use <> for that purpose. It already is valid input and puts everything to a single stem but doesn't get the heads and some other things right. The only niggle with that is that to get per-note (rather than per-chord) articulations/fingerings, you'd need to write << 2 4 4 >> or << 2 4 >> since << c2-1 e4-2 g4-3 >> would produce per-chord articulations. But entry-wise, this is already supported well enough. The typesetter messes it up and I am not sure about the MIDI rendition. But it shouldn't require new syntax, even if it seems tricky for people to understand how << ... >> is something totally different from the shorthand << ... \\ ... >> . -- David Kastrup
Re: Mixed chord/note mode
Le 13/08/2022 à 22:04, David Kastrup a écrit :
Does that sound reasonable/useful/whatever ?
I don't want to make my opinion sound too strong, but to be
honest, I'm not fond of it. I would find it confusing if
both stuff and were valid but had totally different
meanings.
From time to time, a user asks on the mailing lists why
fingeringOrientations isn't working for them because they
missed that for it to work, notes have to be put into
single-note chords ...
Random idea, I don't know if it actually makes a lot of sense:
{ c:M c:M8 c:m c:m8 }
(force "major" to be explicit so ‘:’ has chord meaning if followed
by a chord modifier, and tremolo meaning if followed by a number)
Re: Mixed chord/note mode
Jean Abou Samra writes:
> Le 13/08/2022 à 22:04, David Kastrup a écrit :
>> Does that sound reasonable/useful/whatever ?
>
>
>
> I don't want to make my opinion sound too strong, but to be
> honest, I'm not fond of it. I would find it confusing if
> both stuff and were valid but had totally different
> meanings.
Well, we are currently in the position where both
and c:8
are accepted syntactically and create a music expression, but the former
is garbage that is not getting typeset but possibly has some effect in
MIDI when using articulate.ly .
A constrained chord mode available inside of chord angle brackets is not
too bad in my book.
The last time we had a discussion about joining notemode and chordmode
into one composite mode (often _only_ being able to talk in terms of
chords rather than combinations of notes and chords is too constrained
for practical purposes), we did not really arrive at any syntax people
considered favorable. Personally, I'd rather write tremolos as /8
rather than :8...
> From time to time, a user asks on the mailing lists why
> fingeringOrientations isn't working for them because they
> missed that for it to work, notes have to be put into
> single-note chords ...
>
> Random idea, I don't know if it actually makes a lot of sense:
>
> { c:M c:M8 c:m c:m8 }
>
> (force "major" to be explicit so ‘:’ has chord meaning if followed
> by a chord modifier, and tremolo meaning if followed by a number)
c:5 is already valid and meaningful.
--
David Kastrup
Re: Mixed chord/note mode
Le 13/08/2022 à 23:11, David Kastrup a écrit :
Jean Abou Samra writes:
Le 13/08/2022 à 22:04, David Kastrup a écrit :
Does that sound reasonable/useful/whatever ?
I don't want to make my opinion sound too strong, but to be
honest, I'm not fond of it. I would find it confusing if
both stuff and were valid but had totally different
meanings.
Well, we are currently in the position where both
and c:8
are accepted syntactically and create a music expression, but the former
is garbage that is not getting typeset but possibly has some effect in
MIDI when using articulate.ly .
Yes, so is something I'll never care about or see in the manual.
If I have to learn both and recall which is which, mental trouble
arises. It's not that _I_ can't remember it, but we need to think
about beginners and casual users ...
A constrained chord mode available inside of chord angle brackets is not
too bad in my book.
The last time we had a discussion about joining notemode and chordmode
into one composite mode (often _only_ being able to talk in terms of
chords rather than combinations of notes and chords is too constrained
for practical purposes), we did not really arrive at any syntax people
considered favorable. Personally, I'd rather write tremolos as /8
rather than :8...
{ c1*7/8 }
vs
{ c1*7 /8 }
Maybe use “//” if we go the route of changing tremolo syntax?
From time to time, a user asks on the mailing lists why
fingeringOrientations isn't working for them because they
missed that for it to work, notes have to be put into
single-note chords ...
Random idea, I don't know if it actually makes a lot of sense:
{ c:M c:M8 c:m c:m8 }
(force "major" to be explicit so ‘:’ has chord meaning if followed
by a chord modifier, and tremolo meaning if followed by a number)
c:5 is already valid and meaningful.
In chord mode? Yes. Not sure I understand your objection. Could
you explain?
Re: Can't have rehearsal mark and segno mark at same moment
Le 10/08/2022 à 20:48, Jean Abou Samra a écrit : Le 10/08/2022 à 20:35, Vincent Gay a écrit : 10 août 2022 20:20:52 Jean Abou Samra : Another open question is how several marks, of any kind, should be positioned relative to each other when they are at the same place. In the example that started this thread, should the "A" mark be above the segno mark, or on its right, or on its left? Please, let the one who writes the score decide for himself. \tweak is perfect for that. I completely agree that it should be user-settable, but we need to pick a default. Besides, I am not aware of a currently existing simple interface for stacking (say) a RehearsalMark and a MetronomeMark horizontally. If you \tweak X-offset, the value has to be manually adjusted. I actually wrote a snippet last year that automated horizontal stacking for RehearsalMark and MetronomeMark. https://lists.gnu.org/archive/html/lilypond-user/2021-09/msg00426.html So there is some work to be done to implement automatic horizontal stacking in the first place. If it should be the default, it needs to be done first. If not, it can be done later. I now have a patch locally that renames AdHocMarkEvent into LegacyAdHocMarkEvent (also ad-hoc-mark-event into legacy-ad-hoc-mark-event), and reintroduces an AdHocMarkEvent that creates AdHocMark grobs. The syntax is \adHocMark or \adHocEndMark , any number of events is allowed in the same timestep. The default for alignment is to stack AdHocMarks according to input order. (It is the responsibility of the user to avoid dependency on event order with << >> constructs. I'm not sure if this concerning; this issue already exists with text scripts and I don't recall problems, so I think it should be OK, but feedback is welcome.) The plan is to keep \mark for now, but recommend against it in the documentation. Based on how we see usage evolve (from the mailing lists), it could be reasonable to deprecate and actually remove this syntax at some point, but this is a decision I prefer to leave for the future. If anyone has objections, voicing them now would spare me some time writing documentation and regtests. Thanks, Jean
Re: Mixed chord/note mode
Jean Abou Samra writes:
> Le 13/08/2022 à 23:11, David Kastrup a écrit :
>
>> Well, we are currently in the position where both
>>
>> and c:8
>>
>> are accepted syntactically and create a music expression, but the
>> former is garbage that is not getting typeset but possibly has some
>> effect in MIDI when using articulate.ly .
>
>
>
> Yes, so is something I'll never care about or see in the manual.
So why care?
> If I have to learn both and recall which is which, mental trouble
> arises. It's not that _I_ can't remember it, but we need to think
> about beginners and casual users ...
Colon already _is_ being used in chord mode. It's not like we are
opening a new can of worms here.
>> The last time we had a discussion about joining notemode and chordmode
>> into one composite mode (often _only_ being able to talk in terms of
>> chords rather than combinations of notes and chords is too constrained
>> for practical purposes), we did not really arrive at any syntax people
>> considered favorable. Personally, I'd rather write tremolos as /8
>> rather than :8...
>
>
>
> { c1*7/8 }
>
> vs
>
> { c1*7 /8 }
Yikes. Maybe we had that discussion already.
> Maybe use “//” if we go the route of changing tremolo syntax?
Well, this is one of those cases where I get the "even worse" vibe from
most alternative suggestions.
>>> From time to time, a user asks on the mailing lists why
>>> fingeringOrientations isn't working for them because they
>>> missed that for it to work, notes have to be put into
>>> single-note chords ...
>>>
>>> Random idea, I don't know if it actually makes a lot of sense:
>>>
>>> { c:M c:M8 c:m c:m8 }
>>>
>>> (force "major" to be explicit so ‘:’ has chord meaning if followed
>>> by a chord modifier, and tremolo meaning if followed by a number)
>> c:5 is already valid and meaningful.
>
>
> In chord mode? Yes.
This wasn't a chord mode proposal. It was for recognising chords in
notemode.
> Not sure I understand your objection. Could you explain?
--
David Kastrup
Re: GSoC page
Hi all, > - Support for style sheets: Abraham, Kieren? Definitely still available to be, and interested in being, the “Community Mentor” on that! Thanks, Kieren.
Re: Can't have rehearsal mark and segno mark at same moment
On Aug 13, 2022, at 19:00, Jean Abou Samra wrote: > > I now have a patch locally that renames AdHocMarkEvent into > LegacyAdHocMarkEvent > (also ad-hoc-mark-event into legacy-ad-hoc-mark-event), If I were less familiar with this stuff, I would probably be confused by leaving "ad-hoc" in these names while introducing not-very-closely related things that also have "ad-hoc" in their names. Would you be willing to use another name? My best idea is nonce-rehearsal-mark-event. The rest of your plan sounds fine. — Dan
