guidolib-devel — The list is for discussion about development issues and API design.

Re: [Guidolib-devel] Articulations on Chords

[Dominique F. <fo...@gr...>]

> Le 13 sept. 2016 à 17:35, Arshia Cont <ars...@an...> a écrit :
> 
> Thanks again Dominique.
> 
> I fixed this through libmusicxml. Though I insist that Articulation on a chord in Guido should result into a single graphical markup but we can live with it! :)
> 
> The difficulty with your position is to “find” the right “dy” for the articulation while converting.
> 
> In MusicXML there are “relative-y” position and “placement” for each articulation. Is there any magic formula for converting these to Guido “dy”? By doing tests I realise that the “xml2guidovisitor::addPosition” in libmusicxml does NOT take into account the “placement” attribute which is apparently important for articulations.

Right and placement is poorly supported in guido…
The \marcato tag has an optional  ‘position’ parameter that can take ‘above’ or ‘below’ as values, I have to check for other articulations but I’m afraid it’s the only one. In addition, rendering is affected by the position specification even when the default computed position is the same :-( Try the following code as an example:
[
  \marcato(a2 g f e d c)
  \space<2cm>
  \marcato<position="above">(a2 g f e d c)
]
To me it looks like a bug...

I’ll look at this issue (including generalizing the position to all articulations) and see also if I can change the behavior for chords. But a bit patience will be required…

—
Dom


> 
> Thanks again.
> 
> 
> 
> 
> 
>> On 12 Sep 2016, at 15:14, Dominique Fober <fo...@gr...> wrote:
>> 
>> 
>>> Le 12 sept. 2016 à 14:22, Arshia Cont <ars...@an...> a écrit :
>>> 
>>> Hello list,
>>> 
>>> Doing some tests, I realised that articulations on CHORDS are repeated for every note in the chord. This results to not-very-beautiful graphical repetition of articulations (check for example \stacc({c,e,g} or \ten({c,e,g}). Ideally, for a chord we should have once graphical instance of the articulation. Is that correct?! or am I missing sth?
>> 
>> you could write {c,e, \stacc(g)}
>> or  {\stacc<dy=-5>(c) ,e, g}
>> does it solves your problem?
>> —
>> Dom
>> 
>>> 
>>> Thanks in advance,
>>> 
>>> 
>>> Arshia Cont
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Guidolib-devel mailing list
>>> Gui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>> 
> 

Re: [Guidolib-devel] Articulations on Chords

[Arshia C. <ars...@an...>]

Thanks again Dominique.

I fixed this through libmusicxml. Though I insist that Articulation on a chord in Guido should result into a single graphical markup but we can live with it! :)

The difficulty with your position is to “find” the right “dy” for the articulation while converting.

In MusicXML there are “relative-y” position and “placement” for each articulation. Is there any magic formula for converting these to Guido “dy”? By doing tests I realise that the “xml2guidovisitor::addPosition” in libmusicxml does NOT take into account the “placement” attribute which is apparently important for articulations.

Thanks again.





> On 12 Sep 2016, at 15:14, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 12 sept. 2016 à 14:22, Arshia Cont <ars...@an...> a écrit :
>> 
>> Hello list,
>> 
>> Doing some tests, I realised that articulations on CHORDS are repeated for every note in the chord. This results to not-very-beautiful graphical repetition of articulations (check for example \stacc({c,e,g} or \ten({c,e,g}). Ideally, for a chord we should have once graphical instance of the articulation. Is that correct?! or am I missing sth?
> 
> you could write {c,e, \stacc(g)}
> or  {\stacc<dy=-5>(c) ,e, g}
> does it solves your problem?
> —
> Dom
> 
>> 
>> Thanks in advance,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Articulations on Chords

[Arshia C. <ars...@an...>]

That’s what I discovered as well.

I’ll try to add this scheme to the libMusicXML since it embeds the chord inside articulations. Will report on libmusicxml mailing list.



> On 12 Sep 2016, at 15:14, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 12 sept. 2016 à 14:22, Arshia Cont <ars...@an...> a écrit :
>> 
>> Hello list,
>> 
>> Doing some tests, I realised that articulations on CHORDS are repeated for every note in the chord. This results to not-very-beautiful graphical repetition of articulations (check for example \stacc({c,e,g} or \ten({c,e,g}). Ideally, for a chord we should have once graphical instance of the articulation. Is that correct?! or am I missing sth?
> 
> you could write {c,e, \stacc(g)}
> or  {\stacc<dy=-5>(c) ,e, g}
> does it solves your problem?
> —
> Dom
> 
>> 
>> Thanks in advance,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Articulations on Chords

[Dominique F. <fo...@gr...>]

> Le 12 sept. 2016 à 14:22, Arshia Cont <ars...@an...> a écrit :
> 
> Hello list,
> 
> Doing some tests, I realised that articulations on CHORDS are repeated for every note in the chord. This results to not-very-beautiful graphical repetition of articulations (check for example \stacc({c,e,g} or \ten({c,e,g}). Ideally, for a chord we should have once graphical instance of the articulation. Is that correct?! or am I missing sth?

you could write {c,e, \stacc(g)}
or  {\stacc<dy=-5>(c) ,e, g}
does it solves your problem?
—
Dom

> 
> Thanks in advance,
> 
> 
> Arshia Cont
> ------------------------------------------------------------------------------
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Articulations on Chords

[Arshia C. <ars...@an...>]

Hello list,

Doing some tests, I realised that articulations on CHORDS are repeated for every note in the chord. This results to not-very-beautiful graphical repetition of articulations (check for example \stacc({c,e,g} or \ten({c,e,g}). Ideally, for a chord we should have once graphical instance of the articulation. Is that correct?! or am I missing sth?

Thanks in advance,


Arshia Cont

Re: [Guidolib-devel] Mark tag for Rehearsal Markups

[Arshia C. <ars...@an...>]

Dominique,

Once again many thanks.

You can forget my previous comments on default MARK position. I realise that it depends on the context and the fact that we have dx, dy position as option is sufficient enough for this! And in my case, converting from MusicXML, everything is already there!



> On 08 Sep 2016, at 18:16, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 7 sept. 2016 à 13:28, Arshia Cont <ars...@an...> a écrit :
>> 
>> In my on-going attempts to translate the maximum amount of information possible from MusicXML to Guido, I realised that whereas the MARK tag exists in Guido for Rehearsal Markups, probably its optical result is not currently satisfactory for regular use.
>> 
>> The MARK tag in Guido is a text whereas a real Rehearsal Mark should also render an Enclosure around that text (like most editions).
>> 
>> Such information already exists in the Rehearsal tag of MusicXML: http://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-rehearsal.htm
>> 
>> Is it possible/easy to add such closure for MARK tag in Guido?
> 
> that’s done !
> the result is on git, ‘dev’ branch
> an example is in gmn-examples/new-tags-v1.63/mark.gmn
> Some notes:
> - the default mark position has been changed to 2 half-spaces above the staff (was previously similar to the default text position i.e. below the staff), which seems to be the standard rule. 
> - due to historical (and stupid) reasons, the ‘circle’ and ‘oval’ enclosures are supported at syntactic level but not yet at graphic level.
> 
> Regarding the position, the \mark tag supports dx dy.
> —
> Dom
> 
>> 
>> Also, it’d be great to be able to extend MARK parameters and enable POSITION as well since this can be easily inferred from MusicXML.
>> 
>> Cheers,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Mark tag for Rehearsal Markups

[Arshia C. <ars...@an...>]

Dominique,

While you’re still “hot” on the Mark tag, a suggestion on default Mark position: 

The 2HS above the staff is just perfect. Could you also declare the default Horizontal position so that it would NOT collide with the event? If the associated “event” with MARK is high above the staff, there are collisions.

Note that usually MARK will be used at the beginning of a bar/measure. Ideally we should  position it on top of the “bar line”, if any (and for “rehearsal marks” there are always one right before).

I’ll look myself in how to improve this as well on my side.


Arshia

> On 08 Sep 2016, at 18:16, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 7 sept. 2016 à 13:28, Arshia Cont <ars...@an...> a écrit :
>> 
>> In my on-going attempts to translate the maximum amount of information possible from MusicXML to Guido, I realised that whereas the MARK tag exists in Guido for Rehearsal Markups, probably its optical result is not currently satisfactory for regular use.
>> 
>> The MARK tag in Guido is a text whereas a real Rehearsal Mark should also render an Enclosure around that text (like most editions).
>> 
>> Such information already exists in the Rehearsal tag of MusicXML: http://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-rehearsal.htm
>> 
>> Is it possible/easy to add such closure for MARK tag in Guido?
> 
> that’s done !
> the result is on git, ‘dev’ branch
> an example is in gmn-examples/new-tags-v1.63/mark.gmn
> Some notes:
> - the default mark position has been changed to 2 half-spaces above the staff (was previously similar to the default text position i.e. below the staff), which seems to be the standard rule. 
> - due to historical (and stupid) reasons, the ‘circle’ and ‘oval’ enclosures are supported at syntactic level but not yet at graphic level.
> 
> Regarding the position, the \mark tag supports dx dy.
> —
> Dom
> 
>> 
>> Also, it’d be great to be able to extend MARK parameters and enable POSITION as well since this can be easily inferred from MusicXML.
>> 
>> Cheers,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Mark tag for Rehearsal Markups

[Arshia C. <ars...@an...>]

Just great! Many thanks… .



> On 08 Sep 2016, at 18:16, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 7 sept. 2016 à 13:28, Arshia Cont <ars...@an...> a écrit :
>> 
>> In my on-going attempts to translate the maximum amount of information possible from MusicXML to Guido, I realised that whereas the MARK tag exists in Guido for Rehearsal Markups, probably its optical result is not currently satisfactory for regular use.
>> 
>> The MARK tag in Guido is a text whereas a real Rehearsal Mark should also render an Enclosure around that text (like most editions).
>> 
>> Such information already exists in the Rehearsal tag of MusicXML: http://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-rehearsal.htm
>> 
>> Is it possible/easy to add such closure for MARK tag in Guido?
> 
> that’s done !
> the result is on git, ‘dev’ branch
> an example is in gmn-examples/new-tags-v1.63/mark.gmn
> Some notes:
> - the default mark position has been changed to 2 half-spaces above the staff (was previously similar to the default text position i.e. below the staff), which seems to be the standard rule. 
> - due to historical (and stupid) reasons, the ‘circle’ and ‘oval’ enclosures are supported at syntactic level but not yet at graphic level.
> 
> Regarding the position, the \mark tag supports dx dy.
> —
> Dom
> 
>> 
>> Also, it’d be great to be able to extend MARK parameters and enable POSITION as well since this can be easily inferred from MusicXML.
>> 
>> Cheers,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Mark tag for Rehearsal Markups

[Dominique F. <fo...@gr...>]

> Le 7 sept. 2016 à 13:28, Arshia Cont <ars...@an...> a écrit :
> 
> In my on-going attempts to translate the maximum amount of information possible from MusicXML to Guido, I realised that whereas the MARK tag exists in Guido for Rehearsal Markups, probably its optical result is not currently satisfactory for regular use.
> 
> The MARK tag in Guido is a text whereas a real Rehearsal Mark should also render an Enclosure around that text (like most editions).
> 
> Such information already exists in the Rehearsal tag of MusicXML: http://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-rehearsal.htm
> 
> Is it possible/easy to add such closure for MARK tag in Guido?

that’s done !
the result is on git, ‘dev’ branch
an example is in gmn-examples/new-tags-v1.63/mark.gmn
Some notes:
- the default mark position has been changed to 2 half-spaces above the staff (was previously similar to the default text position i.e. below the staff), which seems to be the standard rule. 
- due to historical (and stupid) reasons, the ‘circle’ and ‘oval’ enclosures are supported at syntactic level but not yet at graphic level.

Regarding the position, the \mark tag supports dx dy.
—
Dom

> 
> Also, it’d be great to be able to extend MARK parameters and enable POSITION as well since this can be easily inferred from MusicXML.
> 
> Cheers,
> 
> 
> Arshia Cont
> ------------------------------------------------------------------------------
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] Generate Measure Number at the beginning of Page/line?

[Arshia C. <ars...@an...>]

Thanks Dominique,

> there are various ways to display measure numbers, see gmn-examples/new-tags-v1.54/measuresNumbering.gmn 
> or https://sourceforge.net/p/guidolib/code/ci/master/tree/gmn-examples/new-tags-v1.54/measuresNumbering.gmn <https://sourceforge.net/p/guidolib/code/ci/master/tree/gmn-examples/new-tags-v1.54/measuresNumbering.gmn>
> but there is nothing to get numbering at the beginning of a page

The feature of being able to generate Measure Numbers optically (whenever available) at the beginning of a Page is extremely useful.

I bet a lot of people use Guido to render scores in situations where responsiveness to Screen Size is needed and this is exactly where such an option can become useful.

[Guidolib-devel] Mark tag for Rehearsal Markups

[Arshia C. <ars...@an...>]

In my on-going attempts to translate the maximum amount of information possible from MusicXML to Guido, I realised that whereas the MARK tag exists in Guido for Rehearsal Markups, probably its optical result is not currently satisfactory for regular use.

The MARK tag in Guido is a text whereas a real Rehearsal Mark should also render an Enclosure around that text (like most editions).

Such information already exists in the Rehearsal tag of MusicXML: http://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-rehearsal.htm

Is it possible/easy to add such closure for MARK tag in Guido?

Also, it’d be great to be able to extend MARK parameters and enable POSITION as well since this can be easily inferred from MusicXML.

Cheers,


Arshia Cont

Re: [Guidolib-devel] Generate Measure Number at the beginning of Page/line?

[Dominique F. <fo...@gr...>]

> Le 6 sept. 2016 à 12:22, Arshia Cont <ars...@an...> a écrit :
> 
> Hello Guidoers,
> 
> Is there a way to force the renderer to generate Measure Numbers at the beginning of rendered “pages” (aka rows)?

there are various ways to display measure numbers, see gmn-examples/new-tags-v1.54/measuresNumbering.gmn 
or https://sourceforge.net/p/guidolib/code/ci/master/tree/gmn-examples/new-tags-v1.54/measuresNumbering.gmn <https://sourceforge.net/p/guidolib/code/ci/master/tree/gmn-examples/new-tags-v1.54/measuresNumbering.gmn>
but there is nothing to get numbering at the beginning of a page

—
Dom


> 
> Cheers,
> 
> 
> Arshia
> ------------------------------------------------------------------------------
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Generate Measure Number at the beginning of Page/line?

[Arshia C. <ars...@an...>]

Hello Guidoers,

Is there a way to force the renderer to generate Measure Numbers at the beginning of rendered “pages” (aka rows)?

Cheers,


Arshia

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Dominique,

Thanks for your response.

I believe I’m getting there slowly by improving the libMusicXML’s xml2guido and adding a Space tag when necessary. I check the “necessity” by looking at the note duration and the string length and for now, adding space tags using heuristics.

I believe that there’s a simple relation between an event duration and the default “space” (in HS) in the rendering result. If I can get access to that relation, I can easily automatise everything.

And of course, I’ll push everything on the libMusicXML’s GitHub when it passes our multiple tests.

Cheers,


Arshia

PS: Note that I finally ended up following the XML scheme for Lyrics which more or less comply to the Guido format if you set a lyric tag on each Guido Event (and avoid making lyrics phrases). This just ends up in a better translation… .



> On 05 Sep 2016, at 10:00, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 4 sept. 2016 à 12:17, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>> 
>> Thank you Dominique for the response.
>> 
>> The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used?
> 
> default unit is half-space but you can use any other unit (e.g. mm, cm, in…)
> 
>> And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?
> 
> half-space is relative to the current rendering, so it’s the better to use that
> 
>> 
>> Regarding the horizontal collision / spacing:
>> 
>> Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context.
> 
> right
> 
>> My guess is that Guido already does that for everything except for Lyrics.
> 
> there are probably other exceptions
> 
>> For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
>> What do you think?
> 
> Of course, taking account of lyrics at notes spacing level is the best solution, but it’s not yet the case. The spacing algorithm has been designed by Kai Renz years ago. Although it’s clearly formalized (see kai_renz_diss.pdf in the doc folder), the implementation style is a bit old, which makes it difficult to improve. 
> 
> One day, the main engine algorithms should be redesigned (a lot of code factorization to do, a more functional approach…) that’s a pending task for years. Only the time is missing for that (I think it’s a significant task). 
> 
> 
>> 
>> If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?
> 
> actually that’s quite difficult, spacing can vary greatly depending on many settings (page size, line breaks, settings of the rendering engine…). One solution could be to extend the \space tag (with an additional parameter) so that it applies the corresponding space only when necessary, i.e. only when the ‘normal’ space is less than the required space. That’s really not elegant but probably more easy to do than to modify the spacing algorithm.
> 
> —
> Dominique
> 
>> 
>> Many thanks,
>> 
>> 
>> Arshia
>> 
>>> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>>> 
>>>> Dominique,
>>>> 
>>>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>>>> 
>>>> While rendered (for example in QT GuidoEditor), look at :
>>>> 
>>>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>>>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
>>> 
>>> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
>>> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
>>> See the revised document attached
>>> 
>>>> 
>>>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
>>> 
>>> that’s now corrected and pushed to git (dev branch)
>>> 
>>> —
>>> Dom
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> Arshia
>>>> 
>>> <schubert.gmn>
>>>> 
>>>> 
>>>> <schubert.gmn>
>>>> 
>>>> 
>>>> 
>>>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>>>>> 
>>>>> 
>>>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>>>>> 
>>>>>> Hello Guido list,
>>>>>> 
>>>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>>>> 
>>>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>>>> 
>>>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>>>> 
>>>>>> Are there parameters in the renderer that controls these behaviors?
>>>>> 
>>>>> could you send some sample gmn code to illustrate?
>>>>> —
>>>>> Dom
>>>>> 
>>>>>> 
>>>>>> Thanks in advance,
>>>>>> 
>>>>>> 
>>>>>> Arshia Cont
>>>>>> ------------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> Guidolib-devel mailing list
>>>>>> Gui...@li... <mailto:Gui...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>>>> 
>>>> 
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Dominique F. <fo...@gr...>]

> Le 4 sept. 2016 à 12:17, Arshia Cont <ars...@an...> a écrit :
> 
> Thank you Dominique for the response.
> 
> The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used?

default unit is half-space but you can use any other unit (e.g. mm, cm, in…)

> And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

half-space is relative to the current rendering, so it’s the better to use that

> 
> Regarding the horizontal collision / spacing:
> 
> Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context.

right

> My guess is that Guido already does that for everything except for Lyrics.

there are probably other exceptions

> For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
> What do you think?

Of course, taking account of lyrics at notes spacing level is the best solution, but it’s not yet the case. The spacing algorithm has been designed by Kai Renz years ago. Although it’s clearly formalized (see kai_renz_diss.pdf in the doc folder), the implementation style is a bit old, which makes it difficult to improve. 

One day, the main engine algorithms should be redesigned (a lot of code factorization to do, a more functional approach…) that’s a pending task for years. Only the time is missing for that (I think it’s a significant task). 


> 
> If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

actually that’s quite difficult, spacing can vary greatly depending on many settings (page size, line breaks, settings of the rendering engine…). One solution could be to extend the \space tag (with an additional parameter) so that it applies the corresponding space only when necessary, i.e. only when the ‘normal’ space is less than the required space. That’s really not elegant but probably more easy to do than to modify the spacing algorithm.

—
Dominique

> 
> Many thanks,
> 
> 
> Arshia
> 
>> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
>> 
>> 
>>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>>> 
>>> Dominique,
>>> 
>>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>>> 
>>> While rendered (for example in QT GuidoEditor), look at :
>>> 
>>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
>> 
>> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
>> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
>> See the revised document attached
>> 
>>> 
>>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
>> 
>> that’s now corrected and pushed to git (dev branch)
>> 
>> —
>> Dom
>> 
>>> 
>>> Cheers,
>>> 
>>> Arshia
>>> 
>> <schubert.gmn>
>>> 
>>> 
>>> <schubert.gmn>
>>> 
>>> 
>>> 
>>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>>> 
>>>> 
>>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>>> 
>>>>> Hello Guido list,
>>>>> 
>>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>>> 
>>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>>> 
>>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>>> 
>>>>> Are there parameters in the renderer that controls these behaviors?
>>>> 
>>>> could you send some sample gmn code to illustrate?
>>>> —
>>>> Dom
>>>> 
>>>>> 
>>>>> Thanks in advance,
>>>>> 
>>>>> 
>>>>> Arshia Cont
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Guidolib-devel mailing list
>>>>> Gui...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>>> 
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Thank you Dominique for the response.

The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used? And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

Regarding the horizontal collision / spacing:

Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context. My guess is that Guido already does that for everything except for Lyrics. For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
What do you think?

If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

Many thanks,


Arshia


> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>> 
>> Dominique,
>> 
>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>> 
>> While rendered (for example in QT GuidoEditor), look at :
>> 
>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
> 
> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
> See the revised document attached
> 
>> 
>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
> 
> that’s now corrected and pushed to git (dev branch)
> 
> —
> Dom
> 
>> 
>> Cheers,
>> 
>> Arshia
>> 
> <schubert.gmn>
>> 
>> 
>> <schubert.gmn>
>> 
>> 
>> 
>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>> 
>>>> Hello Guido list,
>>>> 
>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>> 
>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>> 
>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>> 
>>>> Are there parameters in the renderer that controls these behaviors?
>>> 
>>> could you send some sample gmn code to illustrate?
>>> —
>>> Dom
>>> 
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Thank you Dominique for the response.

The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used? And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

Regarding the horizontal collision / spacing:

Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context. My guess is that Guido already does that for everything except for Lyrics. For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
What do you think?

If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

Many thanks,


Arshia

> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>> 
>> Dominique,
>> 
>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>> 
>> While rendered (for example in QT GuidoEditor), look at :
>> 
>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
> 
> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
> See the revised document attached
> 
>> 
>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
> 
> that’s now corrected and pushed to git (dev branch)
> 
> —
> Dom
> 
>> 
>> Cheers,
>> 
>> Arshia
>> 
> <schubert.gmn>
>> 
>> 
>> <schubert.gmn>
>> 
>> 
>> 
>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>> 
>>>> Hello Guido list,
>>>> 
>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>> 
>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>> 
>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>> 
>>>> Are there parameters in the renderer that controls these behaviors?
>>> 
>>> could you send some sample gmn code to illustrate?
>>> —
>>> Dom
>>> 
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Thank you Dominique for the response.

The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used? And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

Regarding the horizontal collision / spacing:

Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context. My guess is that Guido already does that for everything except for Lyrics. For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
What do you think?

If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

Many thanks,


Arshia

> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>> 
>> Dominique,
>> 
>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>> 
>> While rendered (for example in QT GuidoEditor), look at :
>> 
>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
> 
> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
> See the revised document attached
> 
>> 
>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
> 
> that’s now corrected and pushed to git (dev branch)
> 
> —
> Dom
> 
>> 
>> Cheers,
>> 
>> Arshia
>> 
> <schubert.gmn>
>> 
>> 
>> <schubert.gmn>
>> 
>> 
>> 
>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>> 
>>>> Hello Guido list,
>>>> 
>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>> 
>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>> 
>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>> 
>>>> Are there parameters in the renderer that controls these behaviors?
>>> 
>>> could you send some sample gmn code to illustrate?
>>> —
>>> Dom
>>> 
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Thank you Dominique for the response.

The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used? And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

Regarding the horizontal collision / spacing:

Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context. My guess is that Guido already does that for everything except for Lyrics. For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
What do you think?

If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

Many thanks,


Arshia

> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>> 
>> Dominique,
>> 
>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>> 
>> While rendered (for example in QT GuidoEditor), look at :
>> 
>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
> 
> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
> See the revised document attached
> 
>> 
>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
> 
> that’s now corrected and pushed to git (dev branch)
> 
> —
> Dom
> 
>> 
>> Cheers,
>> 
>> Arshia
>> 
> <schubert.gmn>
>> 
>> 
>> <schubert.gmn>
>> 
>> 
>> 
>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>> 
>>>> Hello Guido list,
>>>> 
>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>> 
>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>> 
>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>> 
>>>> Are there parameters in the renderer that controls these behaviors?
>>> 
>>> could you send some sample gmn code to illustrate?
>>> —
>>> Dom
>>> 
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Thank you Dominique for the response.

The StaffFormat is definitely what’s needed for the vertical spacing between staves! A simple question: When you put a number there, say “-5”, what’s the default unit used? And what would you recommend to us as unit so that it’d be ‘relatively’ correct on both Guido Desktop and say iOS+Android rendering?

Regarding the horizontal collision / spacing:

Though your solution solves the problem locally, the problem remains. You’d ideally want the ‘renderer’ to calculate the space not only based on local lyric text but also the rest of the GR context. My guess is that Guido already does that for everything except for Lyrics. For example, when you have a new Clef definition in the middle of a measure, Guido Renderer adjusts spacing… . My wild guess is that a lot of other renderers work like this for Lyrics… .
What do you think?

If “not”, then I’d certainly need to “calculate” the \space tag value based on context! Do you have any suggestions on how to “detect” collisions (or when that tag is needed) to start with?

Many thanks,


Arshia

> On 02 Sep 2016, at 15:08, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
>> 
>> Dominique,
>> 
>> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
>> 
>> While rendered (for example in QT GuidoEditor), look at :
>> 
>> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
>> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.
> 
> You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
> regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
> See the revised document attached
> 
>> 
>> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.
> 
> that’s now corrected and pushed to git (dev branch)
> 
> —
> Dom
> 
>> 
>> Cheers,
>> 
>> Arshia
>> 
> <schubert.gmn>
>> 
>> 
>> <schubert.gmn>
>> 
>> 
>> 
>>> On 02 Sep 2016, at 13:11, Dominique Fober <fo...@gr...> wrote:
>>> 
>>> 
>>>> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
>>>> 
>>>> Hello Guido list,
>>>> 
>>>> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
>>>> 
>>>> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
>>>> 
>>>> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
>>>> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
>>>> 
>>>> Are there parameters in the renderer that controls these behaviors?
>>> 
>>> could you send some sample gmn code to illustrate?
>>> —
>>> Dom
>>> 
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Dominique F. <fo...@gr...>]

> Le 2 sept. 2016 à 13:17, Arshia Cont <ars...@an...> a écrit :
> 
> Dominique,
> 
> As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.
> 
> While rendered (for example in QT GuidoEditor), look at :
> 
> - measure 7 (first appearance of Lyrics) where texts horizontally overlap.
> - measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.

You can make space between notes using the \space tag, that’s one way to solve the horizontal collision issue,
regarding vertical collisions with the next staff, you can also make space between staves using the  \staffFormat<dy=nnn> tag.
See the revised document attached

> 
> For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlock’.

that’s now corrected and pushed to git (dev branch)

—
Dom

> 
> Cheers,
> 
> Arshia
> 

Re: [Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Dominique,

As a sample score, attached is a direct import (from MusicXML) of Schubert’s “Der Wanderer” (voice + piano) to demonstrate the effect.

While rendered (for example in QT GuidoEditor), look at :

- measure 7 (first appearance of Lyrics) where texts horizontally overlap.
- measure 8: Note how the lyrics “her” collapses with the beaming of the lower voice (vertical spacing) which happens almost all the time.

For the Horizontal overlap, you can also check the “bach_lyrics.gmn” in the Guido Sample where “ge-schlach-“ is systematically overlapping ‘ge’ and ’schlach’.

Cheers,

Arshia

Re: [Guidolib-devel] Lyrics positioning/rendering

[Dominique F. <fo...@gr...>]

> Le 2 sept. 2016 à 12:32, Arshia Cont <ars...@an...> a écrit :
> 
> Hello Guido list,
> 
> I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.
> 
> I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:
> 
> (1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
> (2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.
> 
> Are there parameters in the renderer that controls these behaviors?

could you send some sample gmn code to illustrate?
—
Dom

> 
> Thanks in advance,
> 
> 
> Arshia Cont
> ------------------------------------------------------------------------------
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Lyrics positioning/rendering

[Arshia C. <ars...@an...>]

Hello Guido list,

I have recently achieved in converting MusicXML lyrics to Guido format using the Advanced Guido Proposal / lyrics additions.

I was wondering if there are ways to control their rendering? I see several problems that do not seem to be related to the dx,dy parameters:

(1) Sometimes the note/event spacing should be increased to avoid overlapping of lyric text in adjacent events.
(2) Sometimes the lyric text vertically overlaps the stems or stems from the voice below.

Are there parameters in the renderer that controls these behaviours?

Thanks in advance,


Arshia Cont

Re: [Guidolib-devel] Transposition Visitor for Guido

[Dominique F. <fo...@gr...>]

> Le 8 août 2016 à 15:32, Arshia Cont <ars...@an...> a écrit :
> 
> Hi again,
> 
> I am basically trying to use GuidoLib + libMusicXML and guidoAR in a single project.
> 
> I am running into too many namespace, header and method clashes and copies which are not actually the same. I have guidoLib + libMusicXML running fine, but having trouble including GuidoAR operations inside my project. I have managed to get rid of a lot of name clashes but seem stuck on Parser and ARType stuff. And my guess is that once this is overcome there are many more to come!

I really recommend to use them as libraries (solves the conflicts issues).
—
Dom

> 
> Has anyone tried to include GuidoAR operations inside GuidoLib? They seem to be simple and trivial (my purpose is to use the transposition!) but things seems to be copied from here and there to make them independent and apparently the common classes have not followed the same development pathway since their respective release.
> 
> Any thoughts or hints would be welcome!
> 
> 
> Arshia
> 
>> On 08 Aug 2016, at 09:57, Dominique Fober <fo...@gr...> wrote:
>> 
>> 
>>> Le 8 août 2016 à 09:46, Arshia Cont <ars...@an...> a écrit :
>>> 
>>> Hello list,
>>> 
>>> I see a [diatonic] transposition visitor for libMusicXML. I was wondering if such an operation is easily possible also on Guido scores and if there’s already an implementation there of?
>> 
>> you can do it using the guidoar library (also on sourceforge, same guidolib project)
>> 	https://sourceforge.net/p/guidolib/guidoar
>> this library takes gmn code on input and produce gmn code on output, next you’ll just have to render using the guidolib
>> —
>> Dom
>> 
>> 
>>> 
>>> Many thanks in advance,
>>> 
>>> 
>>> Arshia
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Guidolib-devel mailing list
>>> Gui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>> 
>