Nathan Chou writes:
> Hello,
>
> A quick question regarding the key-list argument to \= : if the list
> only has one key, it is assumed to be the id, as the share context is
> optional. When both the context and id are given, however, should the
> order of the keys be (context id) or (id context)
Hello,
A quick question regarding the key-list argument to \= : if the list
only has one key, it is assumed to be the id, as the share context is
optional. When both the context and id are given, however, should the
order of the keys be (context id) or (id context)? I initially
implemented the lat
Hello,
(@David: I did not know about that function, thanks)
I'm wondering how Dynamic_align_engraver should deal with cross-voice
dynamic spanners. I don't have any good ideas at the moment (the best
possibility I thought of is to have a DynamicLineSpanner follow a
cross-voice dynamic to the othe
Nathan Chou writes:
> On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup wrote:
>> Nathan Chou writes:
>>> That is a good point; I might agree with spanner id's not being shared
>>> across voices if nothing has been indicated. To make this less
>>> tedious, however: what if after the parent context
On Tue, Jul 5, 2016 at 1:54 AM, David Kastrup wrote:
> Nathan Chou writes:
>> That is a good point; I might agree with spanner id's not being shared
>> across voices if nothing has been indicated. To make this less
>> tedious, however: what if after the parent context in which to share
>> spanner
Nathan Chou writes:
> On Fri, Jul 1, 2016 at 12:48 AM, David Kastrup wrote:
>> But that means that you can no longer let people write individual parts
>> with several spanner ids independently even when there never is even
>> going to be any cross-Voice spanner. Spanner-ids like \=1 \=2 are not
On Fri, Jul 1, 2016 at 12:48 AM, David Kastrup wrote:
> But that means that you can no longer let people write individual parts
> with several spanner ids independently even when there never is even
> going to be any cross-Voice spanner. Spanner-ids like \=1 \=2 are not
> likely to be unique when
Nathan Chou writes:
> Thanks David and Urs for replying.
>
>>> There is a detail I would like to clarify. David suggested allowing \=
>>> to optionally specify the parent context in which a cross-voice
>>> spanner's information is shared (although I am not sure how that would
>>> be done with a k
Urs Liska writes:
> Am 01.07.2016 um 09:28 schrieb Jan-Peter Voigt:
>>> Hm. If this is a limitation required by the implementation then it's
>>> acceptable. But from a user perspective I would be very surprised if an
>>> ID isn't recognized without an explicitly named context around it. Isn't
>>>
Am 01.07.2016 um 09:28 schrieb Jan-Peter Voigt:
>> Hm. If this is a limitation required by the implementation then it's
>> acceptable. But from a user perspective I would be very surprised if an
>> ID isn't recognized without an explicitly named context around it. Isn't
>> that the (one) idea of
Am 01.07.2016 um 09:21 schrieb Urs Liska:
Am 01.07.2016 um 09:01 schrieb Nathan Chou:
Thanks David and Urs for replying.
There is a detail I would like to clarify. David suggested allowing \=
to optionally specify the parent context in which a cross-voice
spanner's information is shared (alt
Am 01.07.2016 um 09:01 schrieb Nathan Chou:
> Thanks David and Urs for replying.
>
>>> There is a detail I would like to clarify. David suggested allowing \=
>>> to optionally specify the parent context in which a cross-voice
>>> spanner's information is shared (although I am not sure how that wo
Thanks David and Urs for replying.
>> There is a detail I would like to clarify. David suggested allowing \=
>> to optionally specify the parent context in which a cross-voice
>> spanner's information is shared (although I am not sure how that would
>> be done with a key-list, since I think the sp
Urs Liska writes:
> Am 30.06.2016 um 14:47 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>>>
How does that differ from symbols?
>>> Ah, not in the Scheme domain, of course. But you can't *enter* them as
>>> LilyPond code, isn't it?
>> Can y
Am 30.06.2016 um 14:47 schrieb David Kastrup:
> Urs Liska writes:
>
>> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>>
>>> How does that differ from symbols?
>> Ah, not in the Scheme domain, of course. But you can't *enter* them as
>> LilyPond code, isn't it?
> Can you give an example for symbo
Urs Liska writes:
> Am 30.06.2016 um 14:37 schrieb David Kastrup:
>
>> How does that differ from symbols?
>
> Ah, not in the Scheme domain, of course. But you can't *enter* them as
> LilyPond code, isn't it?
Can you give an example for symbols "entered as LilyPond code" as
opposed to "in the Sch
Am 30.06.2016 um 14:37 schrieb David Kastrup:
> Urs Liska writes:
>
>> Am 30.06.2016 um 14:05 schrieb David Kastrup:
>>> Urs Liska writes:
>>>
Am 30.06.2016 um 11:52 schrieb David Kastrup:
>> There is a detail I would like to clarify. David suggested allowing \=
>>> to optionally s
Urs Liska writes:
> Am 30.06.2016 um 14:05 schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 30.06.2016 um 11:52 schrieb David Kastrup:
> There is a detail I would like to clarify. David suggested allowing \=
>> to optionally specify the parent context in which a cross-voice
>> s
Am 30.06.2016 um 14:05 schrieb David Kastrup:
> Urs Liska writes:
>
>> Am 30.06.2016 um 11:52 schrieb David Kastrup:
There is a detail I would like to clarify. David suggested allowing \=
> to optionally specify the parent context in which a cross-voice
> spanner's information is sh
Urs Liska writes:
> Am 30.06.2016 um 11:52 schrieb David Kastrup:
>>> There is a detail I would like to clarify. David suggested allowing \=
>>> > to optionally specify the parent context in which a cross-voice
>>> > spanner's information is shared (although I am not sure how that would
>>> > be
Am 30.06.2016 um 11:52 schrieb David Kastrup:
>> There is a detail I would like to clarify. David suggested allowing \=
>> > to optionally specify the parent context in which a cross-voice
>> > spanner's information is shared (although I am not sure how that would
>> > be done with a key-list, si
Nathan Chou writes:
> Hello,
>
> I have tried the same idea with context properties, and it seems to
> work just as well as my previous approach with a static member. (To
> summarize: cross voice spanners and the voice they currently belong to
> are stored in a property of some context containing
Hello,
I have tried the same idea with context properties, and it seems to
work just as well as my previous approach with a static member. (To
summarize: cross voice spanners and the voice they currently belong to
are stored in a property of some context containing both voices, like
Score. Each vo
Thank you Dan, David, Jan-Peter; I will try the suggestions out.
Nathan
On Sun, Jun 26, 2016 at 8:43 AM, Jan-Peter Voigt wrote:
>
>
> Am 26. Juni 2016 17:06:51 MESZ, schrieb David Kastrup :
>>Jan-Peter Voigt writes:
>> ...
>>> Whenever you are up to using static members, change it to properties
Am 26. Juni 2016 17:06:51 MESZ, schrieb David Kastrup :
>Jan-Peter Voigt writes:
> ...
>> Whenever you are up to using static members, change it to properties
>> of the Score context - or look for session global objects.
>
>"Session global" does not work with score markups in music:
ah, I wasn't
Jan-Peter Voigt writes:
> Hi all,
>
> @David: thank you for your "emergency call"!
> @Nathan: sorry, for giving you bad advise in this case!
>
> To summarize, what to do with spanners, tagged with an ID: Use context
> properties to store them "globally". You can consider the Score
> context "glob
Hi all,
@David: thank you for your "emergency call"!
@Nathan: sorry, for giving you bad advise in this case!
To summarize, what to do with spanners, tagged with an ID: Use context
properties to store them "globally". You can consider the Score context
"global". If there is a context defined wit
Jan-Peter Voigt writes:
> Hi Nathan, hi Dan,
>
> the "nearest" context might be on Staff level - or, if (for example)
> you have voices switching staves, on StaffGroup level, where a
> StaffGroup also might be a GrandStaff or the like. If the context
> property turns out to complex (I don't see a
Hi Nathan, hi Dan,
the "nearest" context might be on Staff level - or, if (for example) you have
voices switching staves, on StaffGroup level, where a StaffGroup also might be
a GrandStaff or the like. If the context property turns out to complex (I don't
see all consequences yet), you'll have
> On Jun 24, 2016, at 07:41 , Nathan Chou wrote:
>
> Hello,
>
> spanners with an id are handled as potentially being cross-voice. Each
> engraver maintains a static list member (so it is shared between all
> instances of an engraver) of named spanners and the voice each spanner
> currently belon
Hello,
Just wanted to update on my progress for the GSoC cross-voice spanners
project. The approach I am currently trying uses the existing
spanner-id property (which can be set like { c\=hello\< d\=hello\! });
spanners with an id are handled as potentially being cross-voice. Each
engraver maintai
31 matches
Mail list logo
