guidolib-devel Mailing List for GUIDOLib

Brought to you by: dfober, hhoos, jkilian, letz, orlarey

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

You can subscribe to this list here.

2003	Jan (8)	Feb (4)	Mar (1)	Apr	May	Jun (1)	Jul	Aug	Sep (2)	Oct	Nov (1)	Dec (5)
2004	Jan (10)	Feb (9)	Mar (5)	Apr	May (4)	Jun (3)	Jul	Aug	Sep (1)	Oct	Nov	Dec (3)
2005	Jan	Feb (6)	Mar	Apr	May	Jun (1)	Jul (1)	Aug	Sep	Oct	Nov	Dec
2006	Jan	Feb	Mar (4)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb (1)	Mar	Apr	May	Jun (1)	Jul	Aug (1)	Sep (7)	Oct (1)	Nov	Dec
2009	Jan	Feb	Mar	Apr	May (1)	Jun (2)	Jul	Aug	Sep (1)	Oct	Nov	Dec
2010	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct (1)	Nov	Dec
2011	Jan	Feb	Mar (3)	Apr	May (1)	Jun (10)	Jul (1)	Aug	Sep	Oct	Nov (2)	Dec (1)
2012	Jan	Feb (2)	Mar	Apr (1)	May (9)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb (1)	Mar	Apr	May	Jun	Jul (1)	Aug (3)	Sep	Oct	Nov	Dec
2014	Jan (6)	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep (2)	Oct (1)	Nov	Dec (6)
2015	Jan (1)	Feb (1)	Mar (3)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (7)	Dec (1)
2016	Jan	Feb (2)	Mar	Apr	May	Jun (5)	Jul (7)	Aug (12)	Sep (30)	Oct	Nov	Dec
2017	Jan (10)	Feb	Mar (1)	Apr (1)	May	Jun	Jul (1)	Aug (14)	Sep (2)	Oct	Nov	Dec
2019	Jan	Feb (2)	Mar	Apr	May	Jun	Jul	Aug (2)	Sep (2)	Oct (4)	Nov	Dec
2020	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2021	Jan	Feb (2)	Mar (2)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

1 2 3 .. 10 > >> (Page 1 of 10)

Re: [Guidolib-devel] Percussion notes

From: Dominique F. <fo...@gr...> - 2021-03-07 17:43:22

Hi Michael,

Le dim. 7 mars 2021 à 11:37, Michael Chourdakis <win...@gm...> a
écrit :

> Is there a format to write percussion notes in a full staff ?
> The kick/drums can be drawn with common notes, but I 'd also want to draw
> the hit/ride/crash with 'X' note with stems for my drumloop.
>

you can use the \noteFormat
<https://guidodoc.grame.fr/refs/tags/Notes/#noteformat> tag to control the
note head
you can also have a look at the guidoeditor examples 1
<https://guidoeditor.grame.fr/?src=examples/Notes/noteFormat2.gmn> and 2
<https://guidoeditor.grame.fr/?src=examples/Notes/noteFormat3.gmn>
--
Dominique


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

[Guidolib-devel] Percussion notes

From: Michael C. <win...@gm...> - 2021-03-07 10:37:24

Is there a format to write percussion notes in a full staff ?
The kick/drums can be drawn with common notes, but I 'd also want to draw
the hit/ride/crash with 'X' note with stems for my drumloop.

Re: [Guidolib-devel] Latest Guido + Direct2D

From: Dominique F. <fo...@gr...> - 2021-02-02 15:59:49

Attachments: image.png

could you post the corresponding guido code ?
Do you get the same behavior with the GuidoEditor ?
Regarding the Ellipse function, that's a recent addition to the GDevice and
yet it has not been implemented by all devices.
(I think the GDIPlus device too). Could you make a PR with your addition ?

Le mar. 2 févr. 2021 à 15:54, Michael Chourdakis <win...@gm...> a
écrit :

> In latest guido build I have this weird thing:
>
> [image: image.png]
>
> Also, the note hit test does not have a width, but it does have the height
> (in virtual void Graph2TimeMap(const FloatRect& box2, const TimeSegment&
> dates, const GuidoElementInfos& infos) the box2 has same "right").
>
> Also, it seems an alignment/position issue? 4/4, measure "2", stems are
> weird.
> In the latest git the Direct2D code does not compile, I had to use my own
> by adding also the Ellipse functions.
>
>
>
>
> MICHAEL CHOURDAKIS, PhD
> DSP & ARTIFICIAL INTELLIGENSE
> SOFTWARE ENGINEER
> www.turbo-play.com
>
>
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>

[Guidolib-devel] Latest Guido + Direct2D

From: Michael C. <win...@gm...> - 2021-02-02 14:29:10

Attachments: image.png

In latest guido build I have this weird thing:

[image: image.png]

Also, the note hit test does not have a width, but it does have the height
(in virtual void Graph2TimeMap(const FloatRect& box2, const TimeSegment&
dates, const GuidoElementInfos& infos) the box2 has same "right").

Also, it seems an alignment/position issue? 4/4, measure "2", stems are
weird.
In the latest git the Direct2D code does not compile, I had to use my own
by adding also the Ellipse functions.




MICHAEL CHOURDAKIS, PhD
DSP & ARTIFICIAL INTELLIGENSE
SOFTWARE ENGINEER
www.turbo-play.com

[Guidolib-devel] Guido Engine version 1.68

From: Dominique F. <fo...@gr...> - 2020-03-02 17:08:23

Hi all,

A new version of the Guido Engine Library, applications and tools are
available from GitHub:

https://github.com/grame-cncm/guidolib/releases


The javascript/WASM Guido library is also available from npm:

https://www.npmjs.com/package/@grame/guidolib


Dominique Fober


11 cours de Verdun - Gensoul 69002 Lyon
tél  : +33 (0) 472 07 37 00
http://www.grame.fr

Re: [Guidolib-devel] Drawing roll-form

From: Dominique F. <fo...@gr...> - 2019-10-09 14:40:17

Hi Michael,

Regarding the point a): you have just to use the \pageFormat tag (
https://guidodoc.grame.fr/refs/tags/Layout/#pageformat) and to set the page
width to a pseudo-infinite value.
It's less obvious for b): in fact, the basic answer is no, you can't ask
the engine to draw from measure n to m, and you can't impose a spacing
either. But I think there are simple solutions.

Regarding the measures subset: you can draw in an offscreen and next copy
only the selected measures. Using the mapping API (GUIDOScoreMap.h), you
can get all the information to cut one or several measures in your
offscreen and to copy them anywhere you want.
The spacing issue is more complex: actually, if you want a temporal
alignment between the score and your sequencer, it's probably more easy to
do it the reverse way i.e. change the spacing in your sequencer for
alignment to the score. Again the mapping API makes it easy to do.
--
Dominique


Le mar. 8 oct. 2019 à 22:17, Michael Chourdakis <win...@gm...> a
écrit :

> In my sequencer I want more control on the drawing.
> Basically I want to be able
>
> a) to draw it in one system (that is, no break to multiple systems, just
> draw up to available width
>
> b) Start and end in a specific measure, say draw from measure 2 to measure
> 4. Ideally, with my own spacing (so the measure is aligned in my sequencer,
> for example).
>
> Are these possible somehow?
>
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>

[Guidolib-devel] Drawing roll-form

From: Michael C. <win...@gm...> - 2019-10-08 20:16:57

In my sequencer I want more control on the drawing.
Basically I want to be able

a) to draw it in one system (that is, no break to multiple systems, just
draw up to available width

b) Start and end in a specific measure, say draw from measure 2 to measure
4. Ideally, with my own spacing (so the measure is aligned in my sequencer,
for example).

Are these possible somehow?

Re: [Guidolib-devel] Guido Questions

From: Dominique F. <fo...@gr...> - 2019-10-02 08:02:09

Hi Henry,



> Le 28 sept. 2019 à 00:04, Henry Flurry <gui...@he...> a écrit :
> 
> I too would be interested in the ability of a hit-testing mechanism - ideally for any element that can be specified in the score.
> 
> I've been pondering this for some time, and I have not yet imagined a strong solution.
> 
> Simply returning a "note" (Event?) from a hit test does not seem detailed enough.  For example, with a unison, how do we know which note was hit?

I agree.

> 
> If however, there was a way to tag each element in a predictable manner, then that tag could be returned for testing and for enabling interaction with the generated score.

good idea!

> 
> Some ideas: 
> - When using human generated scores, Guido could create default tags that are automatically generated from the score itself.  E.g., line & character (an admittedly brute-force method), plus type and details of element might be suitable.  The type and details could suffice for some (e.g., the note on a particular beat); and the line and character could be enough for someone to code more specific details.

I had already thought about that. It could also be used to relate a graphic position and the corresponding textual description, which would be very useful for long scores.

> - Then have the ability to specify actual tags (names?) to each element.  That would require changes to the parser.  Specific tags would be cumbersome for human generated scores, but would be useful for computer generated scores.

adding specific tags to tag elements? is that what you mean? That’s an idea too.

> - If not have manually defined tags as an option for each element in the ASCII score, perhaps export the ability to do this with function calls so if someone is writing code to generate scores through direct function calls, they could add specific tags.

it's probably the best option for the needs Michael's referring to.

> 
> Finally, where is the hit test information stored when a score is generated?  Is it part of some lcurrently, arger data structure, or is it a separate data structure generated in a similar way to the score being generated?

currently, the ‘mapping’ information (i.e. bounding box and associated time interval) is stored along with each graphic element.

> 
> All of these ideas come from a cursory examination of the GUIDOLib, not from an attempt to use it extensively.  Thus my conjectures may reflect fundamental misunderstandings about the library.


thanks for your suggestions
—
Dominique


> 
> Thanks,
> Henry
> 
> 
>> On Sep 27, 2019, at 8:44 AM, Michael Chourdakis <win...@gm...> wrote:
>> 
>> I'm up to putting Quido to my sequencer.
>> 
>> There are questions:
>> 
>> 1. I'm trying to create a Direct2D device so Guido can use my normal render target, hardware accelerated.
>> This is the output:
>> 
>> <image.png>
>> 
>> When using the implemented HDC, this is the correct one:
>> 
>> <image.png>
>> <image.png>
>> 
>> It seems to me that some weird scaling occurs. 
>> 
>> This is my code:
>> 
>> virtual void	DrawMusicSymbol(float x, float y, unsigned int inSymbolID) 
>> {
>> EnsureBrush();
>> D2D1_RECT_F ly = { 0 };
>> wstring yy = inSymbolID;
>> auto ty = MeasureString(mSys->WriteFactory, mCurrMusicFont.Text, yy.c_str(), yy.length()); 
>> // To measure width and height, irrelevant
>> 
>> // The following is weird, probably
>> ly.left = (NextOrigin.x + x)* Scale.x;
>> ly.top = (NextOrigin.y + y)*Scale.y;
>> ly.right = ly.left + std::get<0>(ty);
>> ly.bottom = ly.top + std::get<1>(ty);
>> 
>> mSys->rt->DrawTextW(yy.c_str(), yy.length(), mCurrMusicFont.Text, ly, NextColor);
>> }
>> 
>> I need to understand more on scaling perhaps. Any ideas?
>> 
>> 2. Can the guido factory create all sort of elements? I want to create a score editor and I can use it if it can create everything, otherwise I will simply edit gmn sources with my code.
>> 
>> 3. Is there a hit testing mechanism, information about where each element is drawn? Notes particularly. So they can be hit-tested with the mouse and edited perhaps. If not, I can make a keyboard-only editor.
>> 
>> Best Regards,
>> 
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 
> 
> 
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] Guido Questions

From: Dominique F. <fo...@gr...> - 2019-10-02 07:34:20

<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="ApplePlainTextBody">Hi Michael,<br><br><br>Difficult to answer on the graphic problem and the offset. I don’t know Direct2D.<br>You should have a look at other device implementations.<br>The fact is that normally there is no need for scaling (that’s transparent). <br>As far as I can remember, it seems to me that there was a similar problem with the opengl device.<br><br>Regarding the question #2 the answer is yes: the guido factory can create all sort of elements. It’s actually used by the parser to create the AR representation. The API is a bit ugly and could be greatly improved, especially by making it more functional. Currently it works entirely by side effect :-(<br><br>And for the question #3: there is no hit testing mechanism but it should be easy to build one using the mapping api.<br>Have a look at “GUIDOScoreMap.h” : there are methods to inspect the graphic score and to associate elements, rectangles and time intervals. If you need more information, it could be easy to extend.<br><br>Best<br>—<br>Dominique<br><br><br><br><br><blockquote type="cite">Le 27 sept. 2019 à 17:44, Michael Chourdakis &lt;win...@gm...&gt; a écrit :<br><br>I'm up to putting Quido to my sequencer.<br><br>There are questions:<br><br>1. I'm trying to create a Direct2D device so Guido can use my normal render target, hardware accelerated.<br>This is the output:<br><br>&lt;image.png&gt;<br><br>When using the implemented HDC, this is the correct one:<br><br>&lt;image.png&gt;<br>&lt;image.png&gt;<br><br>It seems to me that some weird scaling occurs. <br><br>This is my code:<br><br> virtual void<span class="Apple-tab-span" style="white-space:pre">	</span>DrawMusicSymbol(float x, float y, unsigned int inSymbolID) <br>{<br>EnsureBrush();<br>D2D1_RECT_F ly = { 0 };<br>wstring yy = inSymbolID;<br>auto ty = MeasureString(mSys-&gt;WriteFactory, mCurrMusicFont.Text, yy.c_str(), yy.length()); <br>// To measure width and height, irrelevant<br><br>// The following is weird, probably<br>ly.left = (NextOrigin.x + x)* Scale.x;<br>ly.top = (NextOrigin.y + y)*Scale.y;<br>ly.right = ly.left + std::get&lt;0&gt;(ty);<br>ly.bottom = ly.top + std::get&lt;1&gt;(ty);<br><br>mSys-&gt;rt-&gt;DrawTextW(yy.c_str(), yy.length(), mCurrMusicFont.Text, ly, NextColor);<br>}<br><br>I need to understand more on scaling perhaps. Any ideas?<br><br>2. Can the guido factory create all sort of elements? I want to create a score editor and I can use it if it can create everything, otherwise I will simply edit gmn sources with my code.<br><br>3. Is there a hit testing mechanism, information about where each element is drawn? Notes particularly. So they can be hit-tested with the mouse and edited perhaps. If not, I can make a keyboard-only editor.<br><br>Best Regards,<br><br>_______________________________________________<br>Guidolib-devel mailing list<br>Gui...@li...<br>https://lists.sourceforge.net/lists/listinfo/guidolib-devel<br></blockquote><br></div></body></html>

Re: [Guidolib-devel] Guido Questions

From: Henry F. <gui...@He...> - 2019-09-27 22:21:39

I too would be interested in the ability of a hit-testing mechanism - ideally for any element that can be specified in the score.

I've been pondering this for some time, and I have not yet imagined a strong solution.

Simply returning a "note" (Event?) from a hit test does not seem detailed enough.  For example, with a unison, how do we know which note was hit?

If however, there was a way to tag each element in a predictable manner, then that tag could be returned for testing and for enabling interaction with the generated score.

Some ideas: 
- When using human generated scores, Guido could create default tags that are automatically generated from the score itself.  E.g., line & character (an admittedly brute-force method), plus type and details of element might be suitable.  The type and details could suffice for some (e.g., the note on a particular beat); and the line and character could be enough for someone to code more specific details.
- Then have the ability to specify actual tags (names?) to each element.  That would require changes to the parser.  Specific tags would be cumbersome for human generated scores, but would be useful for computer generated scores.
- If not have manually defined tags as an option for each element in the ASCII score, perhaps export the ability to do this with function calls so if someone is writing code to generate scores through direct function calls, they could add specific tags.

Finally, where is the hit test information stored when a score is generated?  Is it part of some larger data structure, or is it a separate data structure generated in a similar way to the score being generated?

All of these ideas come from a cursory examination of the GUIDOLib, not from an attempt to use it extensively.  Thus my conjectures may reflect fundamental misunderstandings about the library.

Thanks,
Henry


> On Sep 27, 2019, at 8:44 AM, Michael Chourdakis <win...@gm...> wrote:
> 
> I'm up to putting Quido to my sequencer.
> 
> There are questions:
> 
> 1. I'm trying to create a Direct2D device so Guido can use my normal render target, hardware accelerated.
> This is the output:
> 
> <image.png>
> 
> When using the implemented HDC, this is the correct one:
> 
> <image.png>
> <image.png>
> 
> It seems to me that some weird scaling occurs. 
> 
> This is my code:
> 
>  virtual void	DrawMusicSymbol(float x, float y, unsigned int inSymbolID) 
> {
> EnsureBrush();
> D2D1_RECT_F ly = { 0 };
> wstring yy = inSymbolID;
> auto ty = MeasureString(mSys->WriteFactory, mCurrMusicFont.Text, yy.c_str(), yy.length()); 
> // To measure width and height, irrelevant
> 
> // The following is weird, probably
> ly.left = (NextOrigin.x + x)* Scale.x;
> ly.top = (NextOrigin.y + y)*Scale.y;
> ly.right = ly.left + std::get<0>(ty);
> ly.bottom = ly.top + std::get<1>(ty);
> 
> mSys->rt->DrawTextW(yy.c_str(), yy.length(), mCurrMusicFont.Text, ly, NextColor);
> }
> 
> I need to understand more on scaling perhaps. Any ideas?
> 
> 2. Can the guido factory create all sort of elements? I want to create a score editor and I can use it if it can create everything, otherwise I will simply edit gmn sources with my code.
> 
> 3. Is there a hit testing mechanism, information about where each element is drawn? Notes particularly. So they can be hit-tested with the mouse and edited perhaps. If not, I can make a keyboard-only editor.
> 
> Best Regards,
> 
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Guido Questions

From: Michael C. <win...@gm...> - 2019-09-27 15:45:05

Attachments: image.png image.png image.png

I'm up to putting Quido to my sequencer.

There are questions:

1. I'm trying to create a Direct2D device so Guido can use my normal render
target, hardware accelerated.
This is the output:

[image: image.png]

When using the implemented HDC, this is the correct one:

[image: image.png]
[image: image.png]

It seems to me that some weird scaling occurs.

This is my code:

 virtual void DrawMusicSymbol(float x, float y, unsigned int inSymbolID)
{
EnsureBrush();
D2D1_RECT_F ly = { 0 };
wstring yy = inSymbolID;
auto ty = MeasureString(mSys->WriteFactory, mCurrMusicFont.Text,
yy.c_str(), yy.length());
// To measure width and height, irrelevant

// The following is weird, probably
ly.left = (NextOrigin.x + x)* Scale.x;
ly.top = (NextOrigin.y + y)*Scale.y;
ly.right = ly.left + std::get<0>(ty);
ly.bottom = ly.top + std::get<1>(ty);

mSys->rt->DrawTextW(yy.c_str(), yy.length(), mCurrMusicFont.Text, ly,
NextColor);
}

I need to understand more on scaling perhaps. Any ideas?

2. Can the guido factory create all sort of elements? I want to create a
score editor and I can use it if it can create everything, otherwise I will
simply edit gmn sources with my code.

3. Is there a hit testing mechanism, information about where each element
is drawn? Notes particularly. So they can be hit-tested with the mouse and
edited perhaps. If not, I can make a keyboard-only editor.

Best Regards,

[Guidolib-devel] Guido Engine version 1.67 on npm

From: Dominique F. <fo...@gr...> - 2019-08-29 11:47:38

Hi,

The javascript Guido library version 1.67 is  available from npm:
https://www.npmjs.com/package/@grame/guidolib

Note that the library is only available as a wasm (WebAssembly) library. It
changes the way the library must be loaded. (see the enclosed guidoengine
class).

Dominique Fober

GRAME - Centre national de création musicale
11 cours de Verdun -Gensoul 69002 Lyon
tél  : +33 (0) 472 07 37 00
fax : +33 (0) 472 07 37 01
http://www.grame.fr

[Guidolib-devel] Guido Engine version 1.67

From: Dominique F. <fo...@gr...> - 2019-08-29 11:35:20

Hi,

A new version of the Guido Engine Library, applications and tools is
available from GitHub:
https://github.com/grame-cncm/guidolib/releases

Reminder:
since release 1.66, a single package provides all the components (SDKs,
tools, applications) for Mac OS and Windows.
The other platforms have to download and compile the source package.

Dominique Fober

GRAME - Centre national de création musicale
11 cours de Verdun -Gensoul 69002 Lyon
tél  : +33 (0) 472 07 37 00
fax : +33 (0) 472 07 37 01
http://www.grame.fr

[Guidolib-devel] Guido Engine Javascript version 1.66

From: Dominique F. <fo...@gr...> - 2019-02-26 10:30:04

Hi,

The Javascript Guido Engine Library is now available from npm:
	https://www.npmjs.com/package/@grame/guidolib

All the best,
—
Dominique

[Guidolib-devel] Guido Engine version 1.66

From: Dominique F. <fo...@gr...> - 2019-02-26 10:18:31

Hi,

A new version of the Guido Engine Library, applications and tools is available from the sourceforge files section:	
	https://sourceforge.net/projects/guidolib/files/ <https://sourceforge.net/projects/guidolib/files/>
or from GitHub:
	https://github.com/grame-cncm/guidolib/releases

Note that now, a single package provides all the components (SDKs, tools, applications) for Mac OS and Windows. 
Other platforms have to download and compile the source package.


All the best,
—
Dominique


Change list
-----------------------------------------
- new pedalOn and pedalOff tags
- intens tag: add text before and after attributes
- fingering tag: add position attribute, add global settings
- add -viewport option to guido2svg
- new \arpeggio tag
- new GuidoGetMetersAt API
- fix slur rendering with one grace note and a regular note 
- fix slur collision with chords 
- fix incorrect cresc. on single chord
- fix incorrect articulations position in case of enforced beaming
- fix incorrect text position for marks
- fix \intens bounding box
- fix noteFormat issue within chords (issue  #17)
- dm parameter removed from \cresc and \decresc tags (redundant with \i)
- fix ignored dx parameter for \systemFormat tag
- fix inverted dy for dynamics (\cresc, \decresc)
- ornaments syntax change (affects \trill, \mordent, \turn): they don't use a chord for 
  specification any more, but can be applied to (real) chord. Tag parameters have been redesigned.
- slurs: dx[12] and dy[12] are now taken into account when curve direction (up | down) is set,
  dx and dy are now applied as offsets to dx1, dx2 and dy1, dy2
- new staff distance parameter for fixed stave spacing feature (\staffFormat<distance>)
- new GuidoShowElement API
- the \instr tag supports font attributes (font, size, format...) and auto position 
  using the autopos attribute or using the \auto or \set tag
- new autoInstrPos attribute for the \set tag
- fix incorrect tempo position at line break
- fix incorrect barline between a grace note and note
- crash bug fixed: may occur with \newLine tag followed by a \meter tag
- new mapping behaviour:
	- if a rest starts a bar, GuidoGetStaffMap extends its mapping box to the left barline (to keep 
	  old behaviour, use GuidoGetStaffMapV1)
	- if all bars at a given date, over all staves, start with a rest, GuidoGetSystemMap extends the 
	  first mapping box of the measure to the left barline (to keep old behaviour, use GuidoGetSystemMapV1)
- new \harmony tag
- SVG output change: tags are not using the short form anymore (e.g. <line ... /> is now  <line ...></line>)
- grace notes are included in the previous event mapping area
- supports complex meters with different units
- strategy changed for key change: naturals are hidden by default when the key increases or decreases 
  in the same direction (flats or sharps). This behavior can always be overridden using the 'hideNaturals' tag parameter.
- svg device font colors management changed in order to avoid setting the color when no color is specified on gmn side.
- fix svg export viewBox size with piano roll
- fix slope issue with slurs
- new autopos attribute for dynamics (\cresc and \dim)
- fix newline issue with crescendo and diminuendo
- fix beaming issue with trills
- whole measure rests management (ignored when the meter is not set):
  rest appearance is forced to semibreve
  fix rest centering with end bar, double bar and repeat bars  
- support for \clef<"c0">
- fix grace notes beaming issue: regular beaming ignores graces notes
  they may be beamed using a dedicated \beam tag
- fix native graphic device issues
- new GuidoGetNotesDensity API. The notes density is computed on the x axis only. 
  It represents the ratio between the space occupied by the notes over each measure of each staff.
  The maximum density is retained over a single line.
- new feature to check and solve lyrics collisions, available using an extension of GuidoLayoutSettings.
  Note that solving collisions modifies the internal AR representation but changes are reverted when
  no check is required. 
- new repeat attribute for trills
- new autoLyricsPos attribute for the \set tag
- fix automatic y position for lyrics