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

Re: [Guidolib-devel] UTF-8 or Unicode text?

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

> Le 29 août 2017 à 13:43, Michael Chourdakis <win...@gm...> a écrit :
> 
> I 'm trying to add some greek (say, instrument names), but only in ANSI mode the text is recognized.
> 
> Does the library support UTF-8 font encoding?

yes it does and the \instr tag below works on my side.
try using the GuidoEditor
othewise if the code is file based, make sure it’s encoded without BOM

> 
> \instr<"αβγ"> fails.
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] UTF-8 or Unicode text?

[Michael C. <win...@gm...>]

I 'm trying to add some greek (say, instrument names), but only in ANSI
mode the text is recognized.

Does the library support UTF-8 font encoding?

\instr<"αβγ"> fails.

[Guidolib-devel] Large width

[Michael C. <win...@gm...>]

I have a case that I have created a system of 8 measures without auto
breaking. However the notes are somehow squeezed, presumably because the
library thinks that I have to fit it in A4.

What is the proper way to tell the library I have more width available.
Changing the Guido Page Format width only creates more empty space.

Re: [Guidolib-devel] new engine version 1.6.5

[Michael C. <win...@gm...>]

I 'm trying, but I do get some weird results.
I 'm trying to debug based on the DLLs, not the Guido source.
When I pass my own Direct2D (incomplete) implementation, I get some calls
to MoveTo() and SetLineWidth() with weird float values.

Perhaps anyone can share with me a "correct" draw code (that would simply
draw a guido string to a HDC) so I am sure that I am calling the library
correctly.
Currently I 'm doing this (error checking removed):

---------------------------------
GSystemWin32 sys(hDC, hDC);
auto ddev = sys.CreateDisplayDevice();
auto& dev = *ddev;

GuidoInitDesc gd = { &dev, 0, "guido2", "Calibri" };
GuidoOnDrawDesc desc;
GuidoInit(&gd);
GuidoPageFormat fmt = { 0 };
GuidoGetDefaultPageFormat(&fmt);
fmt.width = 2080;
fmt.height = 1600;
 ARHandler arh;
GuidoParseString(gstr, &arh);
GuidoAR2GR(arh, 0, &desc.handle);
GuidoResizePageToMusic(desc.handle);
GuidoGetPageFormat(desc.handle, 1, &fmt);

desc.hdc = &dev;
desc.page = 1;
desc.updateRegion.erase = true;
desc.scrollx = desc.scrolly = 0;
desc.sizex = (int)fmt.width;
desc.sizey = (int)fmt.height;
GuidoResizePageToMusic(desc.handle);
desc.scrollx = desc.scrolly = 0;
GuidoErrCode ec = GuidoOnDraw(&desc);
GuidoResizePageToMusic(desc.handle);

-------------------------------

This works fine with GSystemWin32sys.









2017-08-21 11:58 GMT+03:00 Dominique Fober <fo...@gr...>:

> Hi Michael,
>
> The GDI an GDIPlus devices are quite old. I didn’t checked how it works on
> the latest Windows OS.
> In addition, there is no application to test on the repository. I suggest
> to test with a minimal application in order to find what’s going wrong.
> Regarding Direct2D, I’m not aware of any implementation. It should not be
> difficult to build one, you have only to implement the VGDevice, VGSystem
> and VGFont interfaces.
> —
> Dominique
>
>
> Le 12 août 2017 à 21:39, Michael Chourdakis <win...@gm...> a
> écrit :
>
> I 've trouble with GDI+.
>
> GSystemWin32 sys(hDC, hDC);
> DeviceWin32 dev(hDC, &sys);
> This works.
>
> GSystemWin32GDIPlus sys(hDC,hDC);
> GDeviceWin32GDIPlus dev(hDC,&sys);
>
> This succeeds, but I get an empty white bitmap.
>
> Am I missing some extra initialization for GDI+?
> Also, I 'm willing to make a Direct2D implementation, anyone already
> working on it?
>
> Thanks.
>
>
>
>
> 2017-07-25 15:57 GMT+03:00 Dominique Fober <fo...@gr...>:
>
>> Hi all,
>>
>> The last commit to the ‘dev’ branch brings a significant change to the
>> guido engine.
>> Internal operations have been revised in a more functional approach,
>> which is transparent for end users.
>> It comes also with a syntax change for ornaments (\trill \turn \mordent)
>> that requires existing gmn code to be updated.
>> The reason of this breach of compatibility is quite simple: the previous
>> syntax was making use of a chord to specify the non-notated note part of
>> the ornament (e.g. \trill{g, f#} to indicate a trill on ‘g’ using ‘f#’ as
>> second note), which was preventing chords ornaments.
>> With the new design, ornaments work like other tags and the alternate
>> note is specified as a parameter (e.g. \trill<“f#’>(g) ).
>>
>> By the way and since compatibility was broken, inverted dy for dynamics
>> (\cresc, \decresc) has also been fixed and works now similarly to all the
>> other tags. Again, existing scripts with dynamics and dy attributes have to
>> be updated.
>>
>> These are the major changes. See the change log for all details and let
>> me know if these changes pose problems to you.
>> All the best,
>> —
>> Dominique
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
> _________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>
>
>

Re: [Guidolib-devel] new engine version 1.6.5

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

Hi Michael,

The GDI an GDIPlus devices are quite old. I didn’t checked how it works on the latest Windows OS.
In addition, there is no application to test on the repository. I suggest to test with a minimal application in order to find what’s going wrong.
Regarding Direct2D, I’m not aware of any implementation. It should not be difficult to build one, you have only to implement the VGDevice, VGSystem and VGFont interfaces.
—
Dominique


> Le 12 août 2017 à 21:39, Michael Chourdakis <win...@gm...> a écrit :
> 
> I 've trouble with GDI+.
> 
> 		GSystemWin32 sys(hDC, hDC);
> 		DeviceWin32 dev(hDC, &sys);
> 		
> This works.
> 
> 		GSystemWin32GDIPlus sys(hDC,hDC);
> 		GDeviceWin32GDIPlus dev(hDC,&sys);	
> 
> This succeeds, but I get an empty white bitmap.
> 
> Am I missing some extra initialization for GDI+?
> Also, I 'm willing to make a Direct2D implementation, anyone already working on it?
> 
> Thanks.
> 
> 
> 
> 
> 2017-07-25 15:57 GMT+03:00 Dominique Fober <fo...@gr... <mailto:fo...@gr...>>:
> Hi all,
> 
> The last commit to the ‘dev’ branch brings a significant change to the guido engine.
> Internal operations have been revised in a more functional approach, which is transparent for end users.
> It comes also with a syntax change for ornaments (\trill \turn \mordent) that requires existing gmn code to be updated.
> The reason of this breach of compatibility is quite simple: the previous syntax was making use of a chord to specify the non-notated note part of the ornament (e.g. \trill{g, f#} to indicate a trill on ‘g’ using ‘f#’ as second note), which was preventing chords ornaments.
> With the new design, ornaments work like other tags and the alternate note is specified as a parameter (e.g. \trill<“f#’>(g) ).
> 
> By the way and since compatibility was broken, inverted dy for dynamics (\cresc, \decresc) has also been fixed and works now similarly to all the other tags. Again, existing scripts with dynamics and dy attributes have to be updated.
> 
> These are the major changes. See the change log for all details and let me know if these changes pose problems to you.
> All the best,
> —
> Dominique
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li... <mailto:Gui...@li...>
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel <https://lists.sourceforge.net/lists/listinfo/guidolib-devel>
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] new engine version 1.6.5

[Michael C. <win...@gm...>]

I 've trouble with GDI+.

GSystemWin32 sys(hDC, hDC);
DeviceWin32 dev(hDC, &sys);
This works.

GSystemWin32GDIPlus sys(hDC,hDC);
GDeviceWin32GDIPlus dev(hDC,&sys);

This succeeds, but I get an empty white bitmap.

Am I missing some extra initialization for GDI+?
Also, I 'm willing to make a Direct2D implementation, anyone already
working on it?

Thanks.




2017-07-25 15:57 GMT+03:00 Dominique Fober <fo...@gr...>:

> Hi all,
>
> The last commit to the ‘dev’ branch brings a significant change to the
> guido engine.
> Internal operations have been revised in a more functional approach, which
> is transparent for end users.
> It comes also with a syntax change for ornaments (\trill \turn \mordent)
> that requires existing gmn code to be updated.
> The reason of this breach of compatibility is quite simple: the previous
> syntax was making use of a chord to specify the non-notated note part of
> the ornament (e.g. \trill{g, f#} to indicate a trill on ‘g’ using ‘f#’ as
> second note), which was preventing chords ornaments.
> With the new design, ornaments work like other tags and the alternate note
> is specified as a parameter (e.g. \trill<“f#’>(g) ).
>
> By the way and since compatibility was broken, inverted dy for dynamics
> (\cresc, \decresc) has also been fixed and works now similarly to all the
> other tags. Again, existing scripts with dynamics and dy attributes have to
> be updated.
>
> These are the major changes. See the change log for all details and let me
> know if these changes pose problems to you.
> All the best,
> —
> Dominique
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>

[Guidolib-devel] new engine version 1.6.5

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

Hi all,

The last commit to the ‘dev’ branch brings a significant change to the guido engine. 
Internal operations have been revised in a more functional approach, which is transparent for end users.
It comes also with a syntax change for ornaments (\trill \turn \mordent) that requires existing gmn code to be updated.
The reason of this breach of compatibility is quite simple: the previous syntax was making use of a chord to specify the non-notated note part of the ornament (e.g. \trill{g, f#} to indicate a trill on ‘g’ using ‘f#’ as second note), which was preventing chords ornaments.
With the new design, ornaments work like other tags and the alternate note is specified as a parameter (e.g. \trill<“f#’>(g) ).

By the way and since compatibility was broken, inverted dy for dynamics (\cresc, \decresc) has also been fixed and works now similarly to all the other tags. Again, existing scripts with dynamics and dy attributes have to be updated.

These are the major changes. See the change log for all details and let me know if these changes pose problems to you. 
All the best,
—
Dominique

[Guidolib-devel] audioMeasureNum for new system line

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

Hello all,

I have been using the ‘audioMeasuresNum’ parameter in the meter tag. I can see that there are ‘on’, ‘off’ and ‘page’ options.

It would be very useful (and natural) to have a ‘newline’ option where measure numbers would appear upon a line break for a system on a page.

Or maybe it already exists?


Arshia

[Guidolib-devel] guidolib src are on github

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

Hi all,

The source code of the guidolib and guidoar projects are now on github :
	https://github.com/grame-cncm/guidolib <https://github.com/grame-cncm/guidolib>
	https://github.com/grame-cncm/guidoar <https://github.com/grame-cncm/guidoar>

It goes with some changes with the development strategy :
- future developments should be made on the ‘dev’ branch only
- contributions are to be made via pull requests

- sourceforge repository is not writable any more (although I’ll try to keep it in sync with github)

You must start from a fresh clone of the github repository. 
(In order to import the repository to gihub, I’ve had to rewrite the history a bit and you could get some trouble if you use the old sf repo)

All the best,
—
Dominique

Re: [Guidolib-devel] Controlling system render height

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

> Le 6 janv. 2017 à 12:34, Arshia Cont <ars...@an...> a écrit :
> 
> Hello Dominique et al.
> 
> So in order to create an artificial rendered dynamic zoom, I believe we should be playing around with StaffFormat’s Size parameter (3pt by default), combined with API’s Spring parameter to introduce more space between events. I believe it’s doable.
> 
> For the StaffFormat, I can see three ways of doing it. I’m wondering which one you’d recommend me to go for:
> 
> (1) Modify the GMN source (such as in GuidoAR). Not ideal since it’d reduce dynamicity of the library and not elegant! :)
> (2) Modify the AR attributes of all staves, and re-render
> (3) Directly modify parameters in the GR domain, such as staffLSPACE (or similar) after a thorough study of dependencies, and re-render

actually, my view about the problem to solve (apart collisions) is not so clear and thus it’s a bit difficult to answer.
Maybe we can discuss that via skype.
—
Dom 

> 
> Let me know which way you’d pick and I’ll go through the necessary learning curve.
> 
> 
> Arshia
> 
> 
>> On 04 Jan 2017, at 14:58, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>> 
>> 
>>> Le 4 janv. 2017 à 14:40, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>> 
>>> Thank you Dominique.
>>> 
>>> The StaffFormat tag’s Size parameter seems to be able to do the job, if we change the GMN score directly.
>>> 
>>> Is there a way to control this parameter for the entire score from the API? I don’t see anything like this in GuidoGrParameters that I can control from the API.
>> 
>> no, the API is not designed to affect the guido code itself (in a given way, that’s what it should do to control this parameter)
>> 
>>> 
>>> I tried creating a “zoom” using the PageFormat of the API but somehow the HEIGHT parameter is not as effective as the WIDTH parameter. Meaning that I can get “pages” with long Height but the rendered staff inside does not occupy much of it.
>> 
>> maybe using the optimalPageFill attribute of the GuidoLayoutSettings
>> you can experiment that with the GuidoEditor preferences pane.
>> 
>> 
>>> 
>>> 
>>>> On 04 Jan 2017, at 12:31, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>>>> 
>>>> 
>>>>> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>>>> 
>>>>> Hello Guido List,
>>>>> 
>>>>> I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .
>>>>> 
>>>> 
>>>> you should look at the ‘gmn-examples/tags/staff*.gmn’ files
>>>> 	https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/ <https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/>
>>>> does it answers your question?
>>>> you could also use the page format tag (or API parameter) and / or zoom in the rendered score
>>>> —
>>>> Dom
>>>> 
>>>> 
>>>>> Is it somehow fixed in the system? Any way to control this from the engine?
>>>>> 
>>>>> Thanks in advance,
>>>>> 
>>>>> 
>>>>> Arshia Cont
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most 
>>>>> engaging tech sites, SlashDot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>>> _______________________________________________
>>>>> Guidolib-devel mailing list
>>>>> Gui...@li... <mailto:Gui...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel <https://lists.sourceforge.net/lists/listinfo/guidolib-devel>
>>>> 
>>> 
>> 
> 

Re: [Guidolib-devel] Controlling system render height

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

Hello Dominique et al.

So in order to create an artificial rendered dynamic zoom, I believe we should be playing around with StaffFormat’s Size parameter (3pt by default), combined with API’s Spring parameter to introduce more space between events. I believe it’s doable.

For the StaffFormat, I can see three ways of doing it. I’m wondering which one you’d recommend me to go for:

(1) Modify the GMN source (such as in GuidoAR). Not ideal since it’d reduce dynamicity of the library and not elegant! :)
(2) Modify the AR attributes of all staves, and re-render
(3) Directly modify parameters in the GR domain, such as staffLSPACE (or similar) after a thorough study of dependencies, and re-render

Let me know which way you’d pick and I’ll go through the necessary learning curve.


Arshia


> On 04 Jan 2017, at 14:58, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 4 janv. 2017 à 14:40, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>> 
>> Thank you Dominique.
>> 
>> The StaffFormat tag’s Size parameter seems to be able to do the job, if we change the GMN score directly.
>> 
>> Is there a way to control this parameter for the entire score from the API? I don’t see anything like this in GuidoGrParameters that I can control from the API.
> 
> no, the API is not designed to affect the guido code itself (in a given way, that’s what it should do to control this parameter)
> 
>> 
>> I tried creating a “zoom” using the PageFormat of the API but somehow the HEIGHT parameter is not as effective as the WIDTH parameter. Meaning that I can get “pages” with long Height but the rendered staff inside does not occupy much of it.
> 
> maybe using the optimalPageFill attribute of the GuidoLayoutSettings
> you can experiment that with the GuidoEditor preferences pane.
> 
> 
>> 
>> 
>>> On 04 Jan 2017, at 12:31, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>>> 
>>> 
>>>> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>>> 
>>>> Hello Guido List,
>>>> 
>>>> I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .
>>>> 
>>> 
>>> you should look at the ‘gmn-examples/tags/staff*.gmn’ files
>>> 	https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/ <https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/>
>>> does it answers your question?
>>> you could also use the page format tag (or API parameter) and / or zoom in the rendered score
>>> —
>>> Dom
>>> 
>>> 
>>>> Is it somehow fixed in the system? Any way to control this from the engine?
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> 
>>>> Arshia Cont
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most 
>>>> engaging tech sites, SlashDot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>>>> _______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li... <mailto:Gui...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel <https://lists.sourceforge.net/lists/listinfo/guidolib-devel>
>>> 
>> 
> 

Re: [Guidolib-devel] Controlling system render height

[Philippe C. <phi...@an...>]

Hello Dominique,

thanks a lot for your answer. The StaffFormat parameter seems to be great
for adjusting the height of each individual staff / note in one staff.
Is there some parameter that would enlarge height?
Or some parameter that would enlarge both while keeping (almost) constant the
height/width proportion?

Thank you very much!

Philippe Cuvillier

2017-01-04 14:40 GMT+01:00 Arshia Cont <ars...@an...>:

> Thank you Dominique.
>
> The StaffFormat tag’s Size parameter seems to be able to do the job, if we
> change the GMN score directly.
>
> Is there a way to control this parameter for the entire score from the
> API? I don’t see anything like this in GuidoGrParameters that I can control
> from the API.
>
> I tried creating a “zoom” using the PageFormat of the API but somehow the
> HEIGHT parameter is not as effective as the WIDTH parameter. Meaning that I
> can get “pages” with long Height but the rendered staff inside does not
> occupy much of it.
>
>
>
>
> On 04 Jan 2017, at 12:31, Dominique Fober <fo...@gr...> wrote:
>
>
> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an...> a écrit :
>
> Hello Guido List,
>
> I was wondering if there’s a mean to control the “size” of a rendered
> score in a page, for readability purposes on a page. This can be achieved
> somehow if we can control the Height of the system on a page. Playing
> around with the engine, I don’t seem to be able to control this parameter.
> Ideally you’d want to control a default staff height where the system would
> infer from that given a score… .
>
>
> you should look at the ‘gmn-examples/tags/staff*.gmn’ files
> https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/
> does it answers your question?
> you could also use the page format tag (or API parameter) and / or zoom in
> the rendered score
> —
> Dom
>
>
> Is it somehow fixed in the system? Any way to control this from the engine?
>
> Thanks in advance,
>
>
> Arshia Cont
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org <http://slashdot.org/>!
> http://sdm.link/slashdot
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>
>

Re: [Guidolib-devel] Controlling system render height

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

> Le 4 janv. 2017 à 14:40, Arshia Cont <ars...@an...> a écrit :
> 
> Thank you Dominique.
> 
> The StaffFormat tag’s Size parameter seems to be able to do the job, if we change the GMN score directly.
> 
> Is there a way to control this parameter for the entire score from the API? I don’t see anything like this in GuidoGrParameters that I can control from the API.

no, the API is not designed to affect the guido code itself (in a given way, that’s what it should do to control this parameter)

> 
> I tried creating a “zoom” using the PageFormat of the API but somehow the HEIGHT parameter is not as effective as the WIDTH parameter. Meaning that I can get “pages” with long Height but the rendered staff inside does not occupy much of it.

maybe using the optimalPageFill attribute of the GuidoLayoutSettings
you can experiment that with the GuidoEditor preferences pane.


> 
> 
>> On 04 Jan 2017, at 12:31, Dominique Fober <fo...@gr... <mailto:fo...@gr...>> wrote:
>> 
>> 
>>> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>>> 
>>> Hello Guido List,
>>> 
>>> I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .
>>> 
>> 
>> you should look at the ‘gmn-examples/tags/staff*.gmn’ files
>> 	https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/ <https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/>
>> does it answers your question?
>> you could also use the page format tag (or API parameter) and / or zoom in the rendered score
>> —
>> Dom
>> 
>> 
>>> Is it somehow fixed in the system? Any way to control this from the engine?
>>> 
>>> Thanks in advance,
>>> 
>>> 
>>> Arshia Cont
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most 
>>> engaging tech sites, SlashDot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>>> _______________________________________________
>>> Guidolib-devel mailing list
>>> Gui...@li... <mailto:Gui...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel <https://lists.sourceforge.net/lists/listinfo/guidolib-devel>
>> 
> 

Re: [Guidolib-devel] Controlling system render height

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

Thank you Dominique.

The StaffFormat tag’s Size parameter seems to be able to do the job, if we change the GMN score directly.

Is there a way to control this parameter for the entire score from the API? I don’t see anything like this in GuidoGrParameters that I can control from the API.

I tried creating a “zoom” using the PageFormat of the API but somehow the HEIGHT parameter is not as effective as the WIDTH parameter. Meaning that I can get “pages” with long Height but the rendered staff inside does not occupy much of it.




> On 04 Jan 2017, at 12:31, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an... <mailto:ars...@an...>> a écrit :
>> 
>> Hello Guido List,
>> 
>> I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .
>> 
> 
> you should look at the ‘gmn-examples/tags/staff*.gmn’ files
> 	https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/ <https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/>
> does it answers your question?
> you could also use the page format tag (or API parameter) and / or zoom in the rendered score
> —
> Dom
> 
> 
>> Is it somehow fixed in the system? Any way to control this from the engine?
>> 
>> Thanks in advance,
>> 
>> 
>> Arshia Cont
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most 
>> engaging tech sites, SlashDot.org <http://slashdot.org/>! http://sdm.link/slashdot <http://sdm.link/slashdot>
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li... <mailto:Gui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 

Re: [Guidolib-devel] Controlling system render height

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

> Le 4 janv. 2017 à 10:55, Arshia Cont <ars...@an...> a écrit :
> 
> Hello Guido List,
> 
> I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .
> 

you should look at the ‘gmn-examples/tags/staff*.gmn’ files
	https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/ <https://sourceforge.net/projects/guidolib/files/gmn-examples/tags/>
does it answers your question?
you could also use the page format tag (or API parameter) and / or zoom in the rendered score
—
Dom


> Is it somehow fixed in the system? Any way to control this from the engine?
> 
> Thanks in advance,
> 
> 
> Arshia Cont
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] help needed

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

Hello Dominique et al.

Happy new year and thanks for the release.

We constantly build the Qt apps on OSX and compile GuidoLib on iOS. We hope to contribute to the iOS code soon when we have a better idea of what we’re doing! :) You can count on us!

Cheers


Arshia Cont

> On 03 Jan 2017, at 12:53, Dominique Fober <fo...@gr...> wrote:
> 
> Hi all,
> 
> Packaging the guido engine is a bit tedious : the number of supported platforms and architectures (linux, tacos, windows, android, iOS), the different languages supported (c/c++, java, javascript, python…), the various environments (Qt, OpenFramework, OpenGL…), all that makes the packaging task a bit beyond my means. In particular, there is currently no public sdk for android and iOS. Linux is also poorly supported (Debian only for the moment). 
> Testing the various distributions is also time consuming and limited to a small set of operating systems and architectures (e.g. the Qt applications package for windows has been checked on windows 10 and windows 8.1 only).  
> Any help would be appreciated.
> 
> All the best,
> —
> Dominique
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Controlling system render height

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

Hello Guido List,

I was wondering if there’s a mean to control the “size” of a rendered score in a page, for readability purposes on a page. This can be achieved somehow if we can control the Height of the system on a page. Playing around with the engine, I don’t seem to be able to control this parameter. Ideally you’d want to control a default staff height where the system would infer from that given a score… .

Is it somehow fixed in the system? Any way to control this from the engine?

Thanks in advance,


Arshia Cont

[Guidolib-devel] help needed

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

Hi all,

Packaging the guido engine is a bit tedious : the number of supported platforms and architectures (linux, tacos, windows, android, iOS), the different languages supported (c/c++, java, javascript, python…), the various environments (Qt, OpenFramework, OpenGL…), all that makes the packaging task a bit beyond my means. In particular, there is currently no public sdk for android and iOS. Linux is also poorly supported (Debian only for the moment). 
Testing the various distributions is also time consuming and limited to a small set of operating systems and architectures (e.g. the Qt applications package for windows has been checked on windows 10 and windows 8.1 only).  
Any help would be appreciated.

All the best,
—
Dominique
 

[Guidolib-devel] Guido Engine version 1.63

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

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/>

And all the best for the new year,
—
Dominique


Change list
---------------
- accidentals collision detection improved, 
  it comes with a change in handling dx in \acc tag: it is now applied to the solved collision
- fix a bug with \space tag at the beginning of a slice (e.g. after a bar): space was ignored
- strategy improved for creating natural keys: when the key signature increases the current key
  no natural key is created unless the 'hideNaturals' tag parameter is set.
- key layout improved : decreases right space after a natural key
- fix dispNote issue in tuplets when value is /32 or /64
- octava tag: draw extensions lines
- new autopos attribute for lyrics: when 'on', the lyrics are placed below the bottom of
  the bounding box that includes all the notes of the staff.
- fix a bug with incorrect placement of position tags in multi-voices scores with \staff tags 
- fix appearance issue with tuplets (dispNote attribute) and durations that normally 
  required to be splitted. Support of dispNote for rests.
- various issues with clefs corrected (duplicate clefs, clef - meter inversion)
- system style for bar format is now supported by repeat bars
- new style "none" for \acc tag, intended to avoid the second accidental in case of tied notes  
- articulations support a position parameter with "above" or "below" values
- default placement of marcato change to above
- chords: better support of articulations tags 
- slurs redesigned
- autoMeasuresNum attribute of the \meter tag supports "page" value
- new GuidoGetMeter API
- new 'enclosure' parameter for \mark tag (see sample gmn files)
- incorrect beaming corrected:  a beam could sometimes cross a beat,
- incorrect beam start corrected for tied notes starting off beat
- bug in Midi export corrected (velocity was always 0)
- crash bug corrected with meter<"0">, was due to new beaming strategy
- beamed half notes support arbitrary 'empty' durations
- new \beamsFull tag introduced to allow rests in auto beaming

Re: [Guidolib-devel] Articulations on Chords

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

Hi Arshia and all,

The issue with articulations on chords is now fixed.
Articulations also support placement (“above”, “below”)
Yet there is no sample gmn file, apart in 'regression-tests/articulations’. I’ll add some asap.
Everything is on git, ‘dev’ branch.
Best,
—
Dom
 

> 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.
> 
> 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] Generate Measure Number at the beginning of Page/line?

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

Thank you a million Dominique.

It seems to work fine.

The “numDy” and “numDx” parameters on \bar does not seem to be effective when “autoMeasuresNum” is set to “page”. This said, I realize that on some devices the X-Position is out-of-page so I was trying to test this to see if it works but it doesn’t.

I see the same behaviour on a fresh compile of GuidoEditor on Mac.

> On 15 Sep 2016, at 11:51, Dominique Fober <df...@gm...> wrote:
> 
> Hi Arshia,
> 
> 
>> 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)?
> 
> That’s done.
> The autoMeasuresNum attribute of \meter supports ‘page’ as value
> e.g. \meter<"2/4", autoMeasuresNum="page”>
> There is a sample code in 'gmn-examples/new-tags-v1.63/measuresNumberingPage.gmn’
> To get it, you have to update your ‘dev’ branch.
> —
> Dom
> 
> 
>> 
>> Cheers,
>> 
>> 
>> Arshia
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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...>]

Dominique,

I see this on iOS. See the attached Screenshot (which is very basic Guido Render from XML). I use the “grParameters.layoutSettings.systemsDistribution = kNeverDistrib” to get 1 system per page.

Note that we start to see measure numbers on the fifth page only because the first letter is out-of-page here.

In case it helps, here are the grParameters that we pass to AR2GR:

	grParameters.layoutSettings.spring = 1.1f;
	grParameters.layoutSettings.force = 750;
	grParameters.layoutSettings.systemsDistribution = kNeverDistrib; // Important to get 1 system per page
	grParameters.layoutSettings.systemsDistance = 10000; // Important to get 1 system per page
	grParameters.layoutSettings.neighborhoodSpacing = 0;
	grParameters.layoutSettings.optimalPageFill = 1;
	grParameters.layoutSettings.resizePage2Music = 1;
	
	grParameters.pageFormat.width = GuidoInches2Unit(MAX(width, 370) / 72.0); // ≥370px to avoid re-layout when the force-spring algorithm can't cope with high-density areas (making one long page)
	grParameters.pageFormat.height = 0;
	grParameters.pageFormat.marginbottom = 0;
	grParameters.pageFormat.margintop = GuidoInches2Unit((15) / 72.0);
	grParameters.pageFormat.marginleft = GuidoInches2Unit(0 / 72.0);
	grParameters.pageFormat.marginright = 0;








> On 15 Sep 2016, at 14:59, Dominique Fober <df...@gm...> wrote:
> 
> 
>> Le 15 sept. 2016 à 14:47, Arshia Cont <ars...@an...> a écrit :
>> 
>> Thank you a million Dominique.
>> 
>> It seems to work fine.
>> 
>> The “numDy” and “numDx” parameters on \bar does not seem to be effective when “autoMeasuresNum” is set to “page”. This said, I realize that on some devices the X-Position is out-of-page so I was trying to test this to see if it works but it doesn’t.
> 
> nothing can escape your vigilance ! you’re right, that’s due to implementation issues (the number is actually displayed by the next bar)
> However, since the page break location is not supposed to be known, I dont know why (and how) specific settings should be applied to the number when “autoMeasuresNum” is set to “page”. 
> If really needed, I can try to restore the bar specific settings.
> 
> Can you give more details for the out-of-page issue? (what kind of device? an example?)
> —
> Dom
> 
> 
>> 
>> I see the same behaviour on a fresh compile of GuidoEditor on Mac.
>> 
>>> On 15 Sep 2016, at 11:51, Dominique Fober <df...@gm...> wrote:
>>> 
>>> Hi Arshia,
>>> 
>>> 
>>>> 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)?
>>> 
>>> That’s done.
>>> The autoMeasuresNum attribute of \meter supports ‘page’ as value
>>> e.g. \meter<"2/4", autoMeasuresNum="page”>
>>> There is a sample code in 'gmn-examples/new-tags-v1.63/measuresNumberingPage.gmn’
>>> To get it, you have to update your ‘dev’ branch.
>>> —
>>> Dom
>>> 
>>> 
>>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>> Arshia
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> 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?

[Dominique F. <df...@gm...>]

> Le 15 sept. 2016 à 14:47, Arshia Cont <ars...@an...> a écrit :
> 
> Thank you a million Dominique.
> 
> It seems to work fine.
> 
> The “numDy” and “numDx” parameters on \bar does not seem to be effective when “autoMeasuresNum” is set to “page”. This said, I realize that on some devices the X-Position is out-of-page so I was trying to test this to see if it works but it doesn’t.

nothing can escape your vigilance ! you’re right, that’s due to implementation issues (the number is actually displayed by the next bar)
However, since the page break location is not supposed to be known, I dont know why (and how) specific settings should be applied to the number when “autoMeasuresNum” is set to “page”. 
If really needed, I can try to restore the bar specific settings.

Can you give more details for the out-of-page issue? (what kind of device? an example?)
—
Dom


> 
> I see the same behaviour on a fresh compile of GuidoEditor on Mac.
> 
>> On 15 Sep 2016, at 11:51, Dominique Fober <df...@gm...> wrote:
>> 
>> Hi Arshia,
>> 
>> 
>>> 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)?
>> 
>> That’s done.
>> The autoMeasuresNum attribute of \meter supports ‘page’ as value
>> e.g. \meter<"2/4", autoMeasuresNum="page”>
>> There is a sample code in 'gmn-examples/new-tags-v1.63/measuresNumberingPage.gmn’
>> To get it, you have to update your ‘dev’ branch.
>> —
>> Dom
>> 
>> 
>>> 
>>> Cheers,
>>> 
>>> 
>>> Arshia
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> 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?

[Dominique F. <df...@gm...>]

Hi Arshia,


> 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)?

That’s done.
The autoMeasuresNum attribute of \meter supports ‘page’ as value
e.g. \meter<"2/4", autoMeasuresNum="page”>
There is a sample code in 'gmn-examples/new-tags-v1.63/measuresNumberingPage.gmn’
To get it, you have to update your ‘dev’ branch.
—
Dom


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

Re: [Guidolib-devel] Articulations on Chords

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

Thank you Dominique! 

I can be patient and I can also help and participate.

> On 13 Sep 2016, at 18:00, Dominique Fober <fo...@gr...> wrote:
> 
> 
>> Le 13 sept. 2016 à 17:35, Arshia Cont <ars...@an... <mailto: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... <mailto:fo...@gr...>> wrote:
>>> 
>>> 
>>>> Le 12 sept. 2016 à 14:22, Arshia Cont <ars...@an... <mailto: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... <mailto:Gui...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>> 
>