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

[Guidolib-devel] migration to git

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

Dear all,

The guidolib source code and resources have migrated to git. Due to the inlining of the svn branches, only the svn/mapping branch has been reported to git and thus the history is lost for git but still available from svn.
For the moment, the git repository is organized in 2 branches:
 - a 'master' branch updated to the last published version
 - a 'dev' branch updated to the current developments
All the next developments will be committed to git. 
Like the cvs repository, the svn repository remains available, but should not evolve any more. 
Best,
--
Dominique 

[Guidolib-devel] guidolib v.1.46

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

Hi,

A new version of the Guido Engine Library, applications and tools are available from the sourceforge files section. 
The main changes are:
- export to svg 	: embedded in GuidoEditor or available using guido2svg command line tool
- export to midifile 	: embedded in GuidoEditor or available using guido2midi command line tool
This version has been purged from all memory leaks and should be more robust to syntax errors
In addition, several bugs (crash bugs or incorrect rendering) have been corrected.
The Max and PureData external have also been updated to run with this version.
See the change log for details and read the IMPORTANT NOTE below.

Best,
--
Dominique


===================
  IMPORTANT NOTE:
===================
- the guido font (guido2.ttf) has been modified: you should install the new version for a correct rendering (automatically done on ubuntu)
- for developers: up to now, it was possible to release the ARHandler and GRHandler (using GuidoFreeAR and GuidoFreeGR) in any order but that was a side effect of memory leaks. Now, you should release them in the reverse order of allocation (i.e. call GuidoFreeGR first and next GuidoFreeAR)

----------------------------------------------------------------
  Change log
----------------------------------------------------------------
2011-11-25 version 1.4.6
- memory leaks corrected
- corrects accidentals management with system bar and implicit bars

----------------------------------------------------------------
      version 1.4.5  (not officialy released) 
- guido font modified - new version is 3.3 (required for correct whole rest rendering)
- MIDI file export capabilities and new GuidoAR2MIDIFile API
- incorrect rendering of \alter in chords corrected
- potential crash with \acc incorrect spec corrected
- potential crash bug with \text tag corrected
- change in accidental management to cover octave changes
  and to comply to the practice described in "Behind Bars" E. Gould p. 79
- corrects a bug in tuplet display (e.g. strange vertical bar with values like [_/28 c2/16])
- corrects a scaling bug in tempo rendering (musical form was not visible)
- duration spec supports absolute time using 'ms' form (e.g. e1*1500ms). 
  The absolute time is converted to an equivalent music time assuming that a quarter note is 1000mls.
- new GuidoGetVersionStr API
- bug in xxxBeg:id xxxEnd:id parsing corrected: id was always null leading to an incorrect rendering
- new embedded svg device and new GuidoSVGExport API

[Guidolib-devel] guidolib v.1.44

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

Dear all,

A new version of the Guido Engine Library is available from the sourceforge files section. 
See the change log below for details.

Best,
--
Dominique


----------------------------------------------------------------
2011- version 1.4.4
- factory API revised
- bench tools included but not compiled by default (actually in progress)
- GDeviceOSX change: defaults now to Quartz coordinates space unless _USE_QD_COORDINATES_
  is defined. Embedded Quartz device uses QD coordinates.
- clef change resets current accidentals (as described by Gould in "Behind bars" p.78)
- key signature lost after clef change corrected (patch by Yu Fan)
- minimum distance between staves is back to 'uncorrected' version
  the change introduced by version 1.4.1 results in incorrect mappings

Re: [Guidolib-devel] Guido library speed optimization

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

Le 29 juin 2011 à 20:13, Yu Fan a écrit :

> Hi,
>      I have Guido running on iPad now. The sheet renders very well.
>      But due to iPad's limited process power,  it took 4 to 5 second to load a small sheet.

that's strange and I don't think that it's only due to iPad limited process power. 
Could you send me the small sheet you used, I'd like to test (but I don't have an iPad)


>      I run a profile and it shows that 77% cpu time is spent on ARMusicalVoice::GetNext() function.
>     This function is call by ARMusic::doAutoBreak() for many times.

That's interesting! It means it could be improved on a very local basis. 
But how did you got this result? did you used shark? on the iPad or or your dev platform?
I've made a time profiling on my side and I got only 5,4% for ARMusicalVoice::GetNext().

More generally I agree that the engine could be improved (although it's doing quite a fast good job). 
But that's a tricky task: e.g. the ARMusicalVoice::GetNext method is complex, it could be reorganized a bit, but the risk is to broke something.

--
Dom


>     
>     Any suggestion would be appreciated!
> 
>      Thank you!
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2_______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] Guido library speed optimization

[Yu F. <yuf...@gm...>]

Hi,
     I have Guido running on iPad now. The sheet renders very well.
     But due to iPad's limited process power,  it took 4 to 5 second to load
a small sheet.
     I run a profile and it shows that 77% cpu time is spent
on ARMusicalVoice::GetNext() function.
    This function is call by ARMusic::doAutoBreak() for many times.

    Any suggestion would be appreciated!

     Thank you!

[Guidolib-devel] iOS compatibility

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

Hi all,

This is to mention a contribution from Yu Fan to make the guido library code compatible with iOS. 
The main change introduced is a change in the GDeviceOSX coordinate system: historically, the device was using Quickdraw coordinates and this behavior has been preserved (using scaling and translation) when the device moved to Quartz. The GDeviceOSX default behavior is now to use the Quartz coordinate system. The previous behavior can be preserved by defining a label named _USE_QD_COORDINATES_.
 
Best,
--
Dominique

Re: [Guidolib-devel] sever bug of full rest

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

The problem is now fixed:
- a clef change doesn't reset the key signature accidentals any more (bug and patch reported by Yu Fan)
- a clef change resets the current measure accidentals (as described by Gould in "Behind bars" p.78)

The change has been committed to the 'mapping' branch.
--
Dom


Le 28 juin 2011 à 15:01, Dominique Fober a écrit :

> 
> Le 27 juin 2011 à 16:45, Jürgen F. Kilian a écrit :
> 
>> Hi,
>> 
>> I can only agree with Dominique, the score shows exactly what one 
>> expects from the .gmn input.
>> For the case, that the first bar in staff 2 is meant to be empty, one 
>> has to replace _/1 by empty/1 .
>> 
>> What I'm not sure about is, if the clef change in staff 2 should 
>> actually reset the key-signature.
>> To me there are pro and con arguments for this behaviour.
> 
> You're right. Actually here is what Gould says in 'Behind bars' p.78:
> 
> "An accidental holds good only in the clef in which it is written; A change of
> clef requires a further accidental for a note of the same pitch."
> 
> Of course, this is true for accidentals but not for keys. I've corrected the keys issue
> but it introduced a bad behavior for accidentals. Back to my copy... :-(
> 
> --
> Dom
> 
> 
>> 
>> Dominique, do you have more information about this special case from 
>> literature?
>> 
>> 
>> Best regards,
>> 
>> Jürgen
>> 
>> 
>> 
>> Am 27.06.2011 12:05, schrieb Dominique Fober:
>>> Hi,
>>> 
>>> Sorry but I don't see where the problem is. The score looks correct to
>>> me: a silent measure is commonly indicated by a whole rest (regardless
>>> of the time signature) which is always centered on the measure (see [1,
>>> 2, 3] below)
>>> Best,
>>> --
>>> Dominique
>>> 
>>> 
>>> [1] G. Read. Music Notation - A Manual of Modern Practice. Taplinger
>>> Publishing Co., Inc., 1979.
>>> [2] T. Ross. The Art of Music Engraving. Hansen Books, 1987.
>>> [3] E. Gould. Behind Bars. Faber Music, 2011.
>>> 
>>> 
>>> Le 20 juin 2011 à 17:20, 余璠 a (&crit :
>>> 
>>>> hi,
>>>> I found a bug about handling full stop with guido 1.43
>>>> Note all measures are the same except the first one of second staff.
>>>> If the rest is replace by note, the problem is gone.
>>>> Please take a look at it.
>>>> Thank you!
>>>> { [ \staff<1>
>>>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"g2">
>>>> d&2/2. _*3/16 f1/16 \bar
>>>> (* meas. 9 *) d&2/2. _*3/16 f1/16 \bar
>>>> (* meas. 10 *) d&2/2. _*3/16 f1/16 \bar
>>>> (* meas. 11 *) d&2/2. _*3/16 f1/16 \bar ],
>>>> [ \staff<2>
>>>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"f4">
>>>> _/1 \bar
>>>> (* meas. 9 *) d&1/2. _*3/16 f-1/16 \clef<"f4"> \bar
>>>> (* meas. 10 *) d&1/2. _*3/16 f-1/16 \bar
>>>> (* meas. 11 *) d&1/2. _*3/16 f-1/16 \bar ]
>>>> }
>>>> 
>>> 
>>> 
>>> 
>>>> <Capture.PNG>------------------------------------------------------------------------------
>>>> EditLive Enterprise is the world's most technically advanced content
>>>> authoring tool. Experience the power of Track Changes, Inline Image
>>>> Editing and ensure content is compliant with Accessibility Checking.
>>>> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
>>>> Guidolib-devel mailing list
>>>> Gui...@li...
>>>> <mailto:Gui...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> All of the data generated in your IT infrastructure is seriously valuable.
>>> Why? It contains a definitive record of application performance, security
>>> threats, fraudulent activity, and more. Splunk takes this data and makes
>>> sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-d2d-c2
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Guidolib-devel mailing list
>>> Gui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>> 
>> 
>> -- 
>> Jürgen
>> 
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security 
>> threats, fraudulent activity, and more. Splunk takes this data and makes 
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] sever bug of full rest

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

Le 27 juin 2011 à 16:45, Jürgen F. Kilian a écrit :

> Hi,
> 
> I can only agree with Dominique, the score shows exactly what one 
> expects from the .gmn input.
> For the case, that the first bar in staff 2 is meant to be empty, one 
> has to replace _/1 by empty/1 .
> 
> What I'm not sure about is, if the clef change in staff 2 should 
> actually reset the key-signature.
> To me there are pro and con arguments for this behaviour.

You're right. Actually here is what Gould says in 'Behind bars' p.78:

"An accidental holds good only in the clef in which it is written; A change of
clef requires a further accidental for a note of the same pitch."

Of course, this is true for accidentals but not for keys. I've corrected the keys issue
but it introduced a bad behavior for accidentals. Back to my copy... :-(

--
Dom


> 
> Dominique, do you have more information about this special case from 
> literature?
> 
> 
> Best regards,
> 
> Jürgen
> 
> 
> 
> Am 27.06.2011 12:05, schrieb Dominique Fober:
>> Hi,
>> 
>> Sorry but I don't see where the problem is. The score looks correct to
>> me: a silent measure is commonly indicated by a whole rest (regardless
>> of the time signature) which is always centered on the measure (see [1,
>> 2, 3] below)
>> Best,
>> --
>> Dominique
>> 
>> 
>> [1] G. Read. Music Notation - A Manual of Modern Practice. Taplinger
>> Publishing Co., Inc., 1979.
>> [2] T. Ross. The Art of Music Engraving. Hansen Books, 1987.
>> [3] E. Gould. Behind Bars. Faber Music, 2011.
>> 
>> 
>> Le 20 juin 2011 à 17:20, 余璠 a (&crit :
>> 
>>> hi,
>>> I found a bug about handling full stop with guido 1.43
>>> Note all measures are the same except the first one of second staff.
>>> If the rest is replace by note, the problem is gone.
>>> Please take a look at it.
>>> Thank you!
>>> { [ \staff<1>
>>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"g2">
>>> d&2/2. _*3/16 f1/16 \bar
>>> (* meas. 9 *) d&2/2. _*3/16 f1/16 \bar
>>> (* meas. 10 *) d&2/2. _*3/16 f1/16 \bar
>>> (* meas. 11 *) d&2/2. _*3/16 f1/16 \bar ],
>>> [ \staff<2>
>>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"f4">
>>> _/1 \bar
>>> (* meas. 9 *) d&1/2. _*3/16 f-1/16 \clef<"f4"> \bar
>>> (* meas. 10 *) d&1/2. _*3/16 f-1/16 \bar
>>> (* meas. 11 *) d&1/2. _*3/16 f-1/16 \bar ]
>>> }
>>> 
>> 
>> 
>> 
>>> <Capture.PNG>------------------------------------------------------------------------------
>>> EditLive Enterprise is the world's most technically advanced content
>>> authoring tool. Experience the power of Track Changes, Inline Image
>>> Editing and ensure content is compliant with Accessibility Checking.
>>> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
>>> Guidolib-devel mailing list
>>> Gui...@li...
>>> <mailto:Gui...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2d-c2
>> 
>> 
>> 
>> _______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 
> 
> -- 
> Jürgen
> 
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security 
> threats, fraudulent activity, and more. Splunk takes this data and makes 
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] sever bug of full rest

[余 <yuf...@ho...>]

hi，	Well, the problem is not the first measure, but the third and forth measure.        There're unnecessary accidentals after the clef change.
	 This is already patch in trunk, by Fober yesterday.
> Date: Mon, 27 Jun 2011 16:45:15 +0200
> From: ki...@no...
> To: gui...@li...; yuf...@ho...
> Subject: Re: [Guidolib-devel] sever bug of full rest
> 
> Hi,
> 
> I can only agree with Dominique, the score shows exactly what one 
> expects from the .gmn input.
> For the case, that the first bar in staff 2 is meant to be empty, one 
> has to replace _/1 by empty/1 .
> 
> What I'm not sure about is, if the clef change in staff 2 should 
> actually reset the key-signature.
> To me there are pro and con arguments for this behaviour.
> 
> Dominique, do you have more information about this special case from 
> literature?
> 
> 
> Best regards,
> 
> Jürgen
> 
> 
> 
> Am 27.06.2011 12:05, schrieb Dominique Fober:
> > Hi,
> >
> > Sorry but I don't see where the problem is. The score looks correct to
> > me: a silent measure is commonly indicated by a whole rest (regardless
> > of the time signature) which is always centered on the measure (see [1,
> > 2, 3] below)
> > Best,
> > --
> > Dominique
> >
> >
> > [1] G. Read. Music Notation - A Manual of Modern Practice. Taplinger
> > Publishing Co., Inc., 1979.
> > [2] T. Ross. The Art of Music Engraving. Hansen Books, 1987.
> > [3] E. Gould. Behind Bars. Faber Music, 2011.
> >
> >
> > Le 20 juin 2011 à 17:20, 余 a (&crit :
> >
> >> hi,
> >> I found a bug about handling full stop with guido 1.43
> >> Note all measures are the same except the first one of second staff.
> >> If the rest is replace by note, the problem is gone.
> >> Please take a look at it.
> >> Thank you!
> >> { [ \staff<1>
> >> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"g2">
> >> d&2/2. _*3/16 f1/16 \bar
> >> (* meas. 9 *) d&2/2. _*3/16 f1/16 \bar
> >> (* meas. 10 *) d&2/2. _*3/16 f1/16 \bar
> >> (* meas. 11 *) d&2/2. _*3/16 f1/16 \bar ],
> >> [ \staff<2>
> >> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"f4">
> >> _/1 \bar
> >> (* meas. 9 *) d&1/2. _*3/16 f-1/16 \clef<"f4"> \bar
> >> (* meas. 10 *) d&1/2. _*3/16 f-1/16 \bar
> >> (* meas. 11 *) d&1/2. _*3/16 f-1/16 \bar ]
> >> }
> >>
> >
> >
> >
> >> <Capture.PNG>------------------------------------------------------------------------------
> >> EditLive Enterprise is the world's most technically advanced content
> >> authoring tool. Experience the power of Track Changes, Inline Image
> >> Editing and ensure content is compliant with Accessibility Checking.
> >> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> >> Guidolib-devel mailing list
> >> Gui...@li...
> >> <mailto:Gui...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> >
> >
> >
> > ------------------------------------------------------------------------------
> > All of the data generated in your IT infrastructure is seriously valuable.
> > Why? It contains a definitive record of application performance, security
> > threats, fraudulent activity, and more. Splunk takes this data and makes
> > sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-d2d-c2
> >
> >
> >
> > _______________________________________________
> > Guidolib-devel mailing list
> > Gui...@li...
> > https://lists.sourceforge.net/lists/listinfo/guidolib-devel
> 
> 
> -- 
> Jürgen
 		 	   		  

Re: [Guidolib-devel] sever bug of full rest

[Jürgen F. K. <ki...@no...>]

Hi,

I can only agree with Dominique, the score shows exactly what one 
expects from the .gmn input.
For the case, that the first bar in staff 2 is meant to be empty, one 
has to replace _/1 by empty/1 .

What I'm not sure about is, if the clef change in staff 2 should 
actually reset the key-signature.
To me there are pro and con arguments for this behaviour.

Dominique, do you have more information about this special case from 
literature?


Best regards,

Jürgen



Am 27.06.2011 12:05, schrieb Dominique Fober:
> Hi,
>
> Sorry but I don't see where the problem is. The score looks correct to
> me: a silent measure is commonly indicated by a whole rest (regardless
> of the time signature) which is always centered on the measure (see [1,
> 2, 3] below)
> Best,
> --
> Dominique
>
>
> [1] G. Read. Music Notation - A Manual of Modern Practice. Taplinger
> Publishing Co., Inc., 1979.
> [2] T. Ross. The Art of Music Engraving. Hansen Books, 1987.
> [3] E. Gould. Behind Bars. Faber Music, 2011.
>
>
> Le 20 juin 2011 à 17:20, 余璠 a (&crit :
>
>> hi,
>> I found a bug about handling full stop with guido 1.43
>> Note all measures are the same except the first one of second staff.
>> If the rest is replace by note, the problem is gone.
>> Please take a look at it.
>> Thank you!
>> { [ \staff<1>
>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"g2">
>> d&2/2. _*3/16 f1/16 \bar
>> (* meas. 9 *) d&2/2. _*3/16 f1/16 \bar
>> (* meas. 10 *) d&2/2. _*3/16 f1/16 \bar
>> (* meas. 11 *) d&2/2. _*3/16 f1/16 \bar ],
>> [ \staff<2>
>> (* meas. 1 *) \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"f4">
>> _/1 \bar
>> (* meas. 9 *) d&1/2. _*3/16 f-1/16 \clef<"f4"> \bar
>> (* meas. 10 *) d&1/2. _*3/16 f-1/16 \bar
>> (* meas. 11 *) d&1/2. _*3/16 f-1/16 \bar ]
>> }
>>
>
>
>
>> <Capture.PNG>------------------------------------------------------------------------------
>> EditLive Enterprise is the world's most technically advanced content
>> authoring tool. Experience the power of Track Changes, Inline Image
>> Editing and ensure content is compliant with Accessibility Checking.
>> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
>> Guidolib-devel mailing list
>> Gui...@li...
>> <mailto:Gui...@li...>
>> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
>
>
>
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel


-- 
Jürgen

Re: [Guidolib-devel] sever bug of full rest

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

Hi,

Sorry but I don't see where the problem is. The score looks correct to me: a silent measure is commonly indicated by a whole rest (regardless of the time signature) which is always centered on the measure (see [1, 2, 3] below)
Best,
--
Dominique


[1] G. Read. Music Notation - A Manual of Modern Practice. Taplinger Publishing Co., Inc., 1979. 
[2] T. Ross. The Art of Music Engraving. Hansen Books, 1987.
[3] E. Gould. Behind Bars. Faber Music, 2011.


Le 20 juin 2011 $)A($ 17:20, S`$*HNXP a (&crit :

> hi,
>      I found a bug about handling full stop with guido 1.43
>      Note all measures are the same except the first one of second staff.
>      If the rest is replace by note, the problem is gone.
>      Please take a look at it. 
>      Thank you!
> { [ \staff<1>
>    (* meas. 1 *)  \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"g2"> d&2/2. _*3/16 f1/16 \bar
>    (* meas. 9 *)  d&2/2. _*3/16 f1/16 \bar
>    (* meas. 10 *) d&2/2. _*3/16 f1/16 \bar
>    (* meas. 11 *) d&2/2. _*3/16 f1/16 \bar ], 
>   [ \staff<2> 
>    (* meas. 1 *)  \key<-5> \meter<"4/4", autoBarlines="off"> \clef<"f4"> _/1 \bar 
>    (* meas. 9 *)  d&1/2. _*3/16 f-1/16 \clef<"f4"> \bar 
>    (* meas. 10 *) d&1/2. _*3/16 f-1/16 \bar 
>    (* meas. 11 *) d&1/2. _*3/16 f-1/16 \bar ]
>  }
> 



> <Capture.PNG>------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

[Guidolib-devel] guidolib v.1.43

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

Dear all,

A new version of the Guido Engine Library and applications is available from the sourceforge files section. 
The release 1.43 provides microtonal support (new \alter tag) and cautionary accidentals (\acc tag extension).
See the changelog (http://sourceforge.net/projects/guidolib/files) for more details.

In addition, a Sibelius plugin to export to Guido Music Notation format is available. For the story, this plugin has been designed by Juergen Kilian years ago and reappeared very recently thanks to João Pais. I've refreshed the source code and it supports now almost the basic notation features.
See at http://sourceforge.net/projects/guidolib/files/Sibelius

Best,
--
Dominique

Re: [Guidolib-devel] Using Guido for follow-along realtime playback

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

Hi

Le 19 mars 2011 à 02:40, Steve Mokris a écrit :

> I've developed a simple application that uses ARFactory to generate and typeset a score.  I'm interested in adding realtime playback functionality to this application --- so that the user can press the "play" button, causing the notes currently being played to be highlighted, and a cursor line to move across the system --- similar to the attached screenshot of Cakewalk's Score View.
> 
> Do you have any suggestions as to how I should approach this?
> 
> In other words...  Assuming I'm able to determine which AR/GRNotes are currently active, how should I go about:
> 	1. changing the color of those notes temporarily

there is a \noteFormat tag to control the color of a note:
	[ g \noteFormat<color="red">( a f) \noteFormat<color="0x888888">g a ]
but doing this way means to recompute the whole score in real-time only to change one note color.
It could work but only with short score.

> 	2. determining the bounding box of the affected notes (so I can rerender just that part of the display)
> 	3. determining the bounding box of the current measure in the system (so I can linearly-interpolate and draw the cursor)
> ?

that's what I'm using to put a cursor on the score. The guido mapping API (see GUIDOScoreMap.h) can deliver various bounding boxes (notes, staves, measures boundaries...) with the associated time information. Note that the mapping API delivers also the mapping between 'rolled' and 'unrolled' time which may be viewed as the correspondence between the score time and the performance time (i.e. with repetitions, jumps to coda, etc...).

The Qt guido editor can show the various mappings available (using the preference pane)
see at http://sourceforge.net/projects/guidolib/files/Qt%20Applications/

Best (and feel free to ask for any help),
--
Dominique

ps: the inscore project (http://inscore.sf.net) is using guido and makes an extensive use of mappings to synchronize various objects to a score.

[Guidolib-devel] Using Guido for follow-along realtime playback

[Steve M. <st...@ko...>]

I've developed a simple application that uses ARFactory to generate and typeset a score.  I'm interested in adding realtime playback functionality to this application --- so that the user can press the "play" button, causing the notes currently being played to be highlighted, and a cursor line to move across the system --- similar to the attached screenshot of Cakewalk's Score View.

Do you have any suggestions as to how I should approach this?

In other words...  Assuming I'm able to determine which AR/GRNotes are currently active, how should I go about:
	1. changing the color of those notes temporarily
	2. determining the bounding box of the affected notes (so I can rerender just that part of the display)
	3. determining the bounding box of the current measure in the system (so I can linearly-interpolate and draw the cursor)
?

Thanks,
Steve

[Guidolib-devel] Qt applications: new release available

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

Dear all,

A new version of the Guido/Qt applications bundle is available from the sourceforge files section. 
The change concerns the GuidoEditor:

GuidoEditor - version 2.1 - march 2011
- bug with print menu corrected: a new score was not printed unless saved to a file
- same bug with export corrected
- mutli formats export. The format is infered from the target file extension.
  PNG is the default when no extension is specified. PDF output supported.


Best,
--
Dominique

[Guidolib-devel] guidolib v.1.40

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

Dear all,

I'm happy to inform you that a new version of the Guido Engine Library and applications is available from the sourceforge files section. 
The release 1.40 provides a Java JNI interface. It also includes externals for Max/MSP and Pure Data.
The main change concerning the SDK is the removal of the old mapping API that is replaced with a new one, thus it breaks compatibility with previous versions. See the changelog (http://sourceforge.net/projects/guidolib/files/DevKits) for more details.

Best,
--
Dominique

[Guidolib-devel] guidolib v.1.38

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

Dear all,

A new version of the Guido Engine Library and applications is  
available from the sourceforge download section. The score layout  
engine has been improved and extended to support new tags:
- new articulations: short/long fermatas, 4 different pizzicati,  
harmonics, staccatissimo
- ornaments implemention : mordents, turn, trill
- articulations position corrected
The Guido font has also been extended.
The Guido applications has been packaged to be independent and  
standalone applications: they refer to embedded fonts and libraries  
(nothing to install into the system).
See at: http://sourceforge.net/projects/guidolib/files/

We wish to thank Samuel Brochot for his efficient contribution to the  
development of the GUIDO library release 1.38 (also named release  
Brochot :-)).

Best,
--
Dominique

Re: [Guidolib-devel] 64 bit platform related bugs

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

Hi Bart,

Le 16 juin 09 à 11:52, Bart Spaans a écrit :

> Hi there,
>
> I tried to compile guidolib 1.37 on 64bit Linux today, but ran into
> some problems:
>
>
> In src/graphic/GRSingleNote.cpp:
>
> ../src/graphic/GRSingleNote.cpp: In member function ‘virtual char*
> GRSingleNote::getGGSInfo(int) const’:
> ../src/graphic/GRSingleNote.cpp:143: error: cast from ‘const
> GRSpring*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp:145: error: cast from ‘const
> GRSpring*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp: In member function ‘virtual void
> GRSingleNote::GGSOutput() const’:
> ../src/graphic/GRSingleNote.cpp:180: error: cast from ‘const
> GRSingleNote*’ to ‘int’ loses precision
> ../src/graphic/GRSingleNote.cpp:190: error: cast from ‘const
> GRSingleNote*’ to ‘int’ loses precision
>

these errors are related to GGS (Guido Graphic Stream), a work in  
progress but actually stalled...
it could be safely moved out of the compiled code using conditional  
inclusion (e.g. #define and #ifdef)

> Line 143, 145: prevspring and nextspring should be casted to long int
> instead of int. Furthermore, snprintf's format string should use %ld
> instead of %d.
> Line 180, 190: el->setID should both cast to long int instead of int.
>

fine ! I've made the changes and they are committed to trunk.

>
> In ../src/graphic/GRTempo.cpp:
>
> ../src/graphic/GRTempo.cpp: In member function ‘void
> GRTempo::DrawText(VGDevice&, const char*, float, float, float*)
> const’:
> ../src/graphic/GRTempo.cpp:237: error: ‘strlen’ was not declared in  
> this scope
>
> This file should include string.h
>

that's already fixed, but not yet on trunk.

>
> After fixing this compilation of the static library went fine, but I
> was looking for a dynamic library (to load from within Python).

you're probably using the linux/makefile. It should become obsolete  
soon. The preferred way is now to use cmake to generate the makefiles/ 
porjects for each platform/environment. It generates a dynamic  
library. See the cmake folder.

> Some
> changes in the Makefile gave me one eventually, but when I tried to
> load it, it immediately segfaulted. I'm not sure if this was also a 64
> bit related issue or that I screwed something up, but it did raise
> some questions regarding the cross-platformness of it all. My question
> is basically: is 64 bit supported or should I stop trying to get it to
> run and try to compile it with 32 bit libs?

As far as I know, the library has never been compiled on 64 bits  
architectures.
I've made the changes to compile for Mac OS X 64 bits... and bumped  
into some lack of support from the system libraries and even from some  
system include files that don't support 64 bits arch.
Unfortunately, I miss a 64 bits linux station to test.  Did you tried  
a 32 bits version to see if the segfaul is still there ?

>
> I was recommended to try out this library, because we are looking for
> cross platform functions that can draw music notation in real-time
> (say, for use in applications like music editors) and this library
> could supposedly do it.

yes it does: it is cross-platform, we use it on Mac OS, Windows and  
linux (only QT based graphic rendering is actually supported on linux)  
and it's probably the only C/C++ library that provides graphic music  
score rendering.

> It would be great if it did, but at this point
> I unfortunately can't test this premise. Would this be possible and if
> so are there some docs available regarding GUIDOLib's internals?

see the doc folder, it contains doxyfiles and some papers, including  
the phd these from Kai Renz, the engine designer.

All the best,
--
Dominique

[Guidolib-devel] 64 bit platform related bugs

[Bart S. <rhi...@gm...>]

Hi there,

I tried to compile guidolib 1.37 on 64bit Linux today, but ran into
some problems:


In src/graphic/GRSingleNote.cpp:

../src/graphic/GRSingleNote.cpp: In member function ‘virtual char*
GRSingleNote::getGGSInfo(int) const’:
../src/graphic/GRSingleNote.cpp:143: error: cast from ‘const
GRSpring*’ to ‘int’ loses precision
../src/graphic/GRSingleNote.cpp:145: error: cast from ‘const
GRSpring*’ to ‘int’ loses precision
../src/graphic/GRSingleNote.cpp: In member function ‘virtual void
GRSingleNote::GGSOutput() const’:
../src/graphic/GRSingleNote.cpp:180: error: cast from ‘const
GRSingleNote*’ to ‘int’ loses precision
../src/graphic/GRSingleNote.cpp:190: error: cast from ‘const
GRSingleNote*’ to ‘int’ loses precision

Line 143, 145: prevspring and nextspring should be casted to long int
instead of int. Furthermore, snprintf's format string should use %ld
instead of %d.
Line 180, 190: el->setID should both cast to long int instead of int.


In ../src/graphic/GRTempo.cpp:

../src/graphic/GRTempo.cpp: In member function ‘void
GRTempo::DrawText(VGDevice&, const char*, float, float, float*)
const’:
../src/graphic/GRTempo.cpp:237: error: ‘strlen’ was not declared in this scope

This file should include string.h


After fixing this compilation of the static library went fine, but I
was looking for a dynamic library (to load from within Python). Some
changes in the Makefile gave me one eventually, but when I tried to
load it, it immediately segfaulted. I'm not sure if this was also a 64
bit related issue or that I screwed something up, but it did raise
some questions regarding the cross-platformness of it all. My question
is basically: is 64 bit supported or should I stop trying to get it to
run and try to compile it with 32 bit libs?

I was recommended to try out this library, because we are looking for
cross platform functions that can draw music notation in real-time
(say, for use in applications like music editors) and this library
could supposedly do it. It would be great if it did, but at this point
I unfortunately can't test this premise. Would this be possible and if
so are there some docs available regarding GUIDOLib's internals?

Thanks in advance
Best regards,
Bart Spaans

[Guidolib-devel] guidolib v.1.37

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

Hi,

The Guido Engine Library SDKs have been updated to the version 1.37  
and are available from the sourceforge download section.
In addition, new releases of the Qt applications have also been  
published in binary form for MacOS and Windows (linux is supported but  
not in binary form).

See at: http://sourceforge.net/project/showfiles.php?group_id=68683

Best,
--
Dominique

[Guidolib-devel] Visual C++ 2005 & gcc support

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

Dear all,

This is to let you know that the guidolib has been 'ported' :-)  to  
Visual C++ 2005 on windows. A lot of code modifications have been  
needed (mainly for security enhancement) and the project outputs have  
been carefully tested, but you're invited to check on your side and to  
send me any comment or bug report (if any).
In addition, the support for gcc (via mingw) has also been added with  
a codeblocks project ( http://www.codeblocks.org/ ). Only the guido  
library project is provided, since the noteviewer depends on the MFC,  
I didn't tried to build a codeblocks project.

All the best,
--
Dominique

Re: [Guidolib-devel] Problems fixed when opening some gmn

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

Hi,

Thanks a lot for pointing out the problems.  There was actually a real  
problem with ScoreSymbolMap.cpp and with the gmn file.
They have been corrected but I didn't used your patch for several  
reasons:
- first, you have to know that the guidolib developments have switched  
to svn for a couple of weeks. Use definitely the svn repository for up- 
to-date source code. The cvs repository is available only for  
historical reasons (I mean, to keep the development history).
- next and concerning the ScoreSymbolMap problem, it has been  
corrected but using a slightly more efficient solution
- finally concerning the crash bug, it cames from empty \tagBegin  
\tagEnd forms i.e. range tags without content. Your proposed solution  
didn't worked on my side. The solution was somewhere else, at AR to GR  
conversion level: now, the corresponding GR tags are not created  
(anyway it doesn't make sense for empty range tags).
All the corrections have been committed on sourceforge to svn.

Best regards,
--
Dominique




Le 25 sept. 08 à 21:43, Mathieu Labbé a écrit :

> Hello,
> I'm developping a program like the GuidoQtViewer application. I  
> found the GuidoLib very useful. It draws scoresheet very well but I  
> had some problems when opening differents gmn (some are generated  
> with MusicXML2Guido from the MusicXML librairy). I had the same bugs  
> with the original GuidoQtViewer. The application crashed each time I  
> opened almost all of my gmn files. So I found problems in the code  
> and I fixed them. I attached to this message the patch and a gmn  
> file to test with.
>
> Configuration:
> Windows XP
> Microsoft Visual Studio 2005
> Last CVS version, compiled from source using win32 projects
> GuidoQtViewer compiled using qmake and nmake
>
> Bugs information :
> **
> File : lib-score-engine-add/ScoreSymbolMap.cpp
>
> There was a crashed when iterating the 'childs' vector. When erasing  
> a child, the program crashed when "--ptr" is done.
>
> **
> File : lib-score-engine/abstract/ARPositionTag.h
>
> I don't know for what it is used, but what I know is that when a  
> correspondance tag is deleted, his parent didn't know it, so the  
> parent had a bad reference (bad pointer). I had the  
> "mParentCorrespondence" attribute. When a child referenced by  
> another tag is deleted, in his destructor it will set his reference  
> in the parent to null. The crash happened when getCorrespondence()  
> is called with the mPositionTag referenced deleted memory.
>
> Hope that could be in the next version. Thx for this great library.
>
> Mathieu Labbé
>
>
>
> < 
> BeetAnGeSample 
> .gmn 
> > 
> < 
> guidolib 
> .patch 
> > 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel

Re: [Guidolib-devel] Error C2512 building on VS2005

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

Hi Mathieu,

Le 25 sept. 08 à 21:57, Mathieu Labbé a écrit :

> Hi,
> I have a problem when I build from source (CVS) the GuidoEngineLib  
> on Visual Studio 2005. I got this error:
>
> 1>c:\libraries\guidolib\lib-score-engine-add\debugdevice.h(120) :  
> error C2512: 'std::basic_ostream<_Elem,_Traits>' : no appropriate  
> default constructor available
> 1>        with
> 1>        [
> 1>            _Elem=char,
> 1>            _Traits=std::char_traits<char>
> 1>        ]

Actually, the real problem is the Microsoft compatibility with  
Microsoft :-))
It's always a significant (and painful) effort to 'port' Visual Studio  
6 code to Visual Studio 2005. There are always some API changes and  
some unexpected behavioral changes, resulting in hours of debugging or  
of trying to understand enigmatic compilers errors.


> I googled a little bit to see that, it seems to be a compiler  
> version issue:
> http://bytes.com/forum/thread451578.html
>
> For now, I fixed temporary this define in the file "debugdevice.h" :
> -line 116 : #define dbgStream  (filestream ? (*filestream) : cout)
> +line 116 : #define dbgStream cout

if it works, it's the solution. Anyway, the debugdevice.h is only  
present for your debug purpose.

>
> I don't know if you plan to support Visual Studio 2005 +, but it is  
> something to think.
>

you're probably right. But before that, I'd prefer to support gnu  
compiler (via mingw). I'll try to see what I can do in a near future.
Is 'debugdevice.h' error the only one when compiling with 2005?

--
dominique

[Guidolib-devel] Error C2512 building on VS2005

[M. L. <mat...@gm...>]

Hi,
I have a problem when I build from source (CVS) the GuidoEngineLib on Visual
Studio 2005. I got this error:

1>c:\libraries\guidolib\lib-score-engine-add\debugdevice.h(120) : error
C2512: 'std::basic_ostream<_Elem,_Traits>' : no appropriate default
constructor available
1>        with
1>        [
1>            _Elem=char,
1>            _Traits=std::char_traits<char>
1>        ]

I googled a little bit to see that, it seems to be a compiler version issue:
http://bytes.com/forum/thread451578.html

For now, I fixed temporary this define in the file "debugdevice.h" :
-line 116 : #define dbgStream  (filestream ? (*filestream) : cout)
+line 116 : #define dbgStream cout

I don't know if you plan to support Visual Studio 2005 +, but it is
something to think.

Sincerely,

Mathieu Labbé

[Guidolib-devel] The Guidolib project has moved to svn

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

Hi all,

The Guidolib project has moved to svn. This change has been the  
opportunity to restructure the source tree, thus the svn tree differs  
from the cvs tree to a great extend. This is also why the svn tree has  
been imported from scratch i.e. without conversion from the cvs tree,  
thus loosing the cvs history. For this reason and also because not all  
the files have been transfered to svn, the cvs repository will remain  
accessible but further developments will be made on svn.

All the best,
Dominique Fober