Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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*

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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 >

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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,

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

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

Re: [GSoC] spanners project update

> 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

Re: GSoC spanners project

Nathan Chou writes: > Hello, > > Thank you for the information! I have been thinking more and a few > questions have come to mind: > > * However the cross voice Spanner object is created, is it expected to > be identical to the object currently created by the hidden voice >

Re: GSoC spanners project

Hello, Thank you for the information! I have been thinking more and a few questions have come to mind: * However the cross voice Spanner object is created, is it expected to be identical to the object currently created by the hidden voice workaround? Just to make sure, Spanners are Grobs, which

Re: GSoC spanners project

Nathan Chou writes: > Hello, > > I have somewhat looked at the code and want to confirm my > understanding of the current behavior: > * While the file is parsed in Scheme, spanners cause a START and STOP > event with an appropriate type to be created in the context they >

Re: GSoC spanners project

Hello, I have somewhat looked at the code and want to confirm my understanding of the current behavior: * While the file is parsed in Scheme, spanners cause a START and STOP event with an appropriate type to be created in the context they belong to * After creation of the Music objects, where

Re: GSoC spanners project

Hi Nathan and Jeffrey, Great to have you on board for LilyPond GSoC! I'll be working on a GSoC project for Mozilla Calendar, so won't be as active with LilyPond, but I'll try to help with development questions if I can. Cheers, -Paul ___

Re: GSoC spanners project

Nathan, Welcome to GSoC and to LilyPond development! I'm excited to have you on board working on the cross-voice spanners project. It's a great project, and will resolve one of the consistent difficulties with LilyPond. Please feel free to ask for help on lilypond-devel. We'd love to help you

Re: GSoC spanners project

Hello list, hello Nathan, I want to second Nathans introduction and gracefully advocate for supporting him/us in this endeavor - to support polyphonic slurs and the like! More to come! Cheers Jan-Peter Am 07.05.2016 um 07:00 schrieb Nathan Chou: Hello all, I am a second-year student