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

[Guidolib-devel] GUIDO Music Notation newsletter

[Jerome B. <be...@gr...>]

====================================================
     G U I D O  Music Notation news
     January 19, 2004

     <http://sourceforge.net/projects/guidolib/>
====================================================


* New version 1.2 of the Guido Engine library has been released.
   This version fixes some bugs, compiles faster, includes new entry
points and is fully cross-platform. Sources are cleaner and documented
using doxygen.


* Binary viewer applications have been released on sourceforge. They
embed the new version of the Guido Engine library.


     - (MacOS-X) GuidoViewer 0.1.1: supports multiple documents and
        printing. It uses Quartz to render musical scores.


     - (Windows) GuidoNoteViewer 0.91: minor changes, updated gif
         export.


* Linux branch of the Guido Engine library now use the standard
     auto* tools (GNU build system).


* The CVS dev branch has been merged to the main branch.

[Guidolib-devel] Linux Support

[J. S. A. <js...@sh...>]

Hello All,

As you may have already received notice by email, I will be working with
Holger and Keith here at UBC on some GUIDO programming projects.  As an
initial contribution to GUIDOLib, I can update the linux branch of the
lib-score-engine to use the standard auto* tools (GNU build system).  It
will involve checking in several files, and having the current makefile
removed.  *nix users (with autoconf, automake and libtools installed)
will then be able to run the supplied autogen.sh script, followed by the
standard ./configure, make and make install to build the GUIDO Score
Engine Library (either as a static or shared library).  Additionally, a
standard tar.gz file of the engine distribution can easily be made with
a make dist command from these files.  Everything has been reasonably
tested on my system here, and is only awaiting approval before checkin. 
The only bits of information I will need is a package and library name
and a version number.  Following standard naming schemes, I propose that
the library name be libscoreengine, or a more descriptive
libguidoscoreengine, or (a slightly easier to read version)
libguidoengine.  The package would then be named guidoengine-lib. 
Finally, a version number would be appended.  What is the current
version of the score engine?

I look forward to working with everyone,

Scott

[Guidolib-devel] guido engine flaws

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

Hi all,

I've discovered some flaws into the guido graphic engine. They have 
been submitted in the bug section of the source forge repository. 
Please, have a look at the list and feel free to take any (or all :-) 
of them in charge.

best,
Dom

Re: [Guidolib-devel] Implementation of tempo indications

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

Le lundi, 1 d=E9c 2003, =E0 12:26 Europe/Paris, J=FCrgen Kilian a =E9crit =
:

> Hi
>
> Stephane Letz wrote:
>
>>
>> Actually dotted note are handled but not with the "." syntax. You can=20=

>> use
>> 3/8 to represent a dotted quarter note for example.
>>
> ok, I see.
>
>> We started with the Basic guido specification that says for tempo tag=20=

>> :
>>
>> \tempo<s,s2> where s2 of the form "x/y=3Dn", thus i just forgot the =
"."
>> syntax. Do you think it it absolutely necessay to support the "."=20
>> syntax?
>>
> Because it's already possible to specify dotted notes by their=20
> duration, it would be only some kind of "nice" feature. But it's not=20=

> absolutely necessarily needed.
>
> I guess there are more important things at the moment. We should add a=20=

> remark into the GUIDO spec "dotted notes can be represented by a=20
> duration without dots....".

Not really: there isn't any ambiguity in case of tempo marking, but on=20=

the score it's different to write c/4. and c*3/8: the former is to be=20
written with a dot while the latter may be written using a tie and=20
therefore the 2 notation forms are not equivalent.

Dominique

Re: [Guidolib-devel] Implementation of tempo indications

[<ki...@no...>]

Hi

Stephane Letz wrote:

>
>Actually dotted note are handled but not with the "." syntax. You can use
>3/8 to represent a dotted quarter note for example.
>  
>
ok, I see.

>We started with the Basic guido specification that says for tempo tag :
>
>\tempo<s,s2> where s2 of the form "x/y=n", thus i just forgot the "."
>syntax. Do you think it it absolutely necessay to support the "." syntax?
>  
>
Because it's already possible to specify dotted notes by their duration, 
it would be only some kind of "nice" feature. But it's not absolutely 
necessarily needed.

I guess there are more important things at the moment. We should add a 
remark into the GUIDO spec "dotted notes can be represented by a 
duration without dots....".


Juergen

Re: [Guidolib-devel] Implementation of tempo indications

[Stephane L. <le...@gr...>]

>Hi Jerome and Stephane,
>
>thanks for implementing this feature, I really missed it already.
>
>We might need also dotted notes for things like 1/4. =3D 120 or 1/4. =3D 1/=
4
>
>
>


Hi Juergen,

Actually dotted note are handled but not with the "." syntax. You can use
3/8 to represent a dotted quarter note for example.

We started with the Basic guido specification that says for tempo tag :

\tempo<s,s2> where s2 of the form "x/y=3Dn", thus i just forgot the "."
syntax. Do you think it it absolutely necessay to support the "." syntax?


Stephane


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
=46ax: 04-72-07-37-01
Web: www.grame.fr

Re: [Guidolib-devel] Implementation of tempo indications

[<ki...@no...>]

Hi Jerome and Stephane,

thanks for implementing this feature, I really missed it already.

We might need also dotted notes for things like 1/4. = 120 or 1/4. = 1/4



CU

Juergen


Stéphane LETZ wrote:

> ----------------------------------------------------------------
> 2003-11-26 Jerome Berthet & Stephane Letz
>
> Implement tempo indications. They can be of 3 types :
>
>     - Textual only like \tempo<"Allegro"> . It will be displayed as a 
> string.
>
>     - BPM like \tempo<"Allegro", "1/4=120">. The string is displayed 
> followed
>     by a note and the bpm value.
>
>     - Note equivalence like \tempo<"Allegro", "1/4=1/8">.
>     The string is displayed followed by a note = another note.
>
> Modified files : ARTempo.h, cpp, GRTempo.h,cpp
>
>
> Stephane
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Guidolib-devel mailing list
> Gui...@li...
> https://lists.sourceforge.net/lists/listinfo/guidolib-devel
>

[Guidolib-devel] Implementation of tempo indications

[<le...@rd...>]

----------------------------------------------------------------
2003-11-26 Jerome Berthet & Stephane Letz

Implement tempo indications. They can be of 3 types :

	- Textual only like \tempo<"Allegro"> . It will be displayed as a 
string.

	- BPM like \tempo<"Allegro", "1/4=120">. The string is displayed 
followed
	by a note and the bpm value.

	- Note equivalence like \tempo<"Allegro", "1/4=1/8">.
	The string is displayed followed by a note = another note.

Modified files : ARTempo.h, cpp, GRTempo.h,cpp


Stephane 

[Guidolib-devel] Problems with .gif size

[<ki...@it...>]

Hi,

there is a problem with correct default picture size in the=20
lib-score-engine. When opening a .gmn file with the old noteviewer the=20=

default scaling (with zoom=3D1) was chosen (optimised?) so, that the=20
score fit to the screen.
Currently the start size seems much larger than that. When using the=20
standalone viewers this is not a problem, just a few mouse-clicks=20
(zoom-out) and it's ok.
I tried to use the new guido2gif and there this is a major problem! The=20=

size of the .gif can't be adjusted correctly at the moment (when=20
adjustPagesize (=3Dcrop) is set to off).

I tried some changes in
GRPage::setMapping

like
	....
	if( vsizex <=3D 0 || vsizey <=3D 0 )		// set to =
default scaling, apply the=20
zoom.
	{
		// why 3 / 4 ?
		/* jk: I think Kai wanted to display at least 3/4 of the =
score on=20
full screen, if
		  possible, keep it for compatibility reasons. It looks =
nice :-)
		*/ 								=
=09
		/*
		maxWidth =3D hdc.MaxWidth();	// =
::GetDeviceCaps(hdc,HORZRES) * 3/ 4;
		maxHeight =3D hdc.MaxHeight();	// =
::GetDeviceCaps(hdc,VERTRES) * 3/ 4;
		*/
		// try it with some default
		// new
		maxWidth =3D 1280;
		maxHeight =3D 1024;

		const float scaleConv =3D 1; // UNCONST; //  * 3 / 4 / =
12.0; // why 12 ?

	//	vsizex =3D int(maxWidth * zoom);// * sizex * scaleConv);
	//	vsizey =3D int(maxHeight * zoom); // * sizey * =
scaleConv);

		vsizex =3D sizex * zoom; // TEST
		vsizey =3D sizey * zoom; // TEST
	}

//	hdc.SetViewportExt( vsizex, vsizey );
	/* this seems to be equal to zoom?
	float newScaleX =3D float(vsizex) / sizex;
	float newScaleY =3D float(vsizey) / sizey;
	*/
	// new
	float newScaleX =3D float(vsizex) / maxWidth;
	float newScaleY =3D float(vsizey) / maxWidth;
	....
---------------------------------
With these hacks and correct parameters it worked very well on the=20
native Windows version and the guido2gif BUT on the wxWindows version=20
the functionality of zoom-in and zoom-out were twisted!

Has anybody (Jerome) a clean solution? Until this is not fixed I can't=20=

use the GUIDOlib-guido2gif.exe on the noteserver.



Thanks

J=FCrgen

PS: Holger has now contact to a good programmer at UBC who'd like to=20
join GUIDOlib development in next future.

[Guidolib-devel] Linux roadmap

[Michael B. <mb...@al...>]

Hi!

I really like your Guido. But I am linux user -
www.altlinux.com. I got cvs code, went into
src/linux/lib-score-engine and type "make". And now I have
guido-engine.lib. Great. 

When are you planning other Guido's program will be ready
for Linux? 

--

Regards, 

М.

[Guidolib-devel] dev branch merged to main branch

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

Hi all,

The dev branch has been merged to the main branch. The corresponding 
GUIDOLib version has been updated from 1.0.0.5 to 1.1.0.0
As a lot of conflicts occurred, I've also committed the corresponding 
changes to the dev branch. Keep in mind to update your local source 
tree if you don't want to deal with future conflicts.

The result of the merge has been checked on MacOSX but not on the other 
platforms. You're invited to report (and possibly correct) any problem 
due to the merge.

When we'll be sure that everything compile correctly on all the 
platforms, I propose to publish a first official release.

best,
Dominique Fober

[Guidolib-devel] Doxygen based documentation for lib-score-engine files

[Stephane L. <le...@gr...>]

Doxygen based documentation of lib-score-engine abstract and graphic
classes has been added.
A new Score_Engine_Doxyfile (in lib-score-engine folder) can be used to
generate a documentation in HTML format.

Doxygen can be found here : http://www.stack.nl/~dimitri/doxygen/ and must
be installed.
Then doing the following command : doxygen Score_Engine_Doxyfile will
generate a html folder containing all documentation.

Please add any new documentation of the source code in the Doxygen format.


Stephane Letz


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr

Re: [Guidolib-devel] Guido and Renaissance music

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

>Dear GuidoLib developers,
>I write as a simple Guido user. First of all let me state that I appeciate=
 your work infinitely. I believe that Guido is almost perfect a tool for=
 encoding and printing of Renaissance music (my field of research at Bologna=
 University, Italy), were it not for the following points:
> 
>1) it would be needed a proper graphic symbol for violin clef transposed at=
 octave lower
> 
>2) it would be nice if bars could be automatically numbered
> 
>3) it would be needed a proper graphic symbol for longa notes (i. e. notes=
 2/1 long)
> 
>4) it wouldn't be bad if the meter graphic symbol coulb be kept distinct=
 from effective barring; this because in Renaissance music the sign "C\"=
 often means barlines every two semibreve (i. e. \meter<"4/2">, but I would=
 like if the sign "C\" were displayed instead!)
> 
>5) we would need optional diamond and square shape for \noteFormat tag=
 (I've seen that the attributes were planned in Guido Advanced Format=
 Specification Draft, so why do not implement them?)
> 
>6) one would like to be able to decide over accolades appearance and shape=
 (ex. "none", "straight brackets", ecc.)
> 
>7) it would be needed to have square brackets over groups of notes to=
 represent ancient "ligaturae" signs
> 
>8) it would be needed a \ficta tag to put accidental over notes (wich means=
 that the accidental was not in the original source, but has been added by=
 the editor)
> 
>9) about the \lyrics tag, it would be better if a series of underscore (i.=
 e. prolongation of last sillable over more than one note) would be=
 displayed as a single unbroken dash.
> 
> 
>I apologize for resembling too much pretending. Actually, all I want to=
 know is if you think you can tackle with the over stated issues, and how=
 long it could take to implement the first two points at least (the most=
 urgent to me!).
>I'm not expert about mailing lists, and I hope I didn't use this one in a=
 wrong way. I that case, I beg your pardon once more.
>Best regards,
>Cristiano Vaval=88

Thanks for your feedback. In fact, the GuidoLib project is running only for=
 a couple of months as an open source project. It means that we're actually=
 busy with tasks such as project management, documentation, fixing a stable=
 API, portability... However your remarks are welcome and we'll take account=
 of them.
Now, giving a delay to implement the first two points (and the others) isn't=
 possible at this stage (Juergen, Kai, what do you think about the issue?).
Please, keep in touch, things could evolve rapidly.

Best regards,
Dominique Fober

[Guidolib-devel] Guido and Renaissance music

[<bas...@ti...>]

Dear GuidoLib developers,
I write as a simple Guido user. First of all let me state that I =
appeciate your work infinitely. I believe that Guido is almost perfect a =
tool for encoding and printing of Renaissance music (my field of =
research at Bologna University, Italy), were it not for the following =
points:

1) it would be needed a proper graphic symbol for violin clef transposed =
at octave lower

2) it would be nice if bars could be automatically numbered

3) it would be needed a proper graphic symbol for longa notes (i. e. =
notes 2/1 long)

4) it wouldn't be bad if the meter graphic symbol coulb be kept distinct =
from effective barring; this because in Renaissance music the sign "C\" =
often means barlines every two semibreve (i. e. \meter<"4/2">, but I =
would like if the sign "C\" were displayed instead!)

5) we would need optional diamond and square shape for \noteFormat tag =
(I've seen that the attributes were planned in Guido Advanced Format =
Specification Draft, so why do not implement them?)

6) one would like to be able to decide over accolades appearance and =
shape (ex. "none", "straight brackets", ecc.)

7) it would be needed to have square brackets over groups of notes to =
represent ancient "ligaturae" signs

8) it would be needed a \ficta tag to put accidental over notes (wich =
means that the accidental was not in the original source, but has been =
added by the editor)

9) about the \lyrics tag, it would be better if a series of underscore =
(i. e. prolongation of last sillable over more than one note) would be =
displayed as a single unbroken dash.


I apologize for resembling too much pretending. Actually, all I want to =
know is if you think you can tackle with the over stated issues, and how =
long it could take to implement the first two points at least (the most =
urgent to me!).
I'm not expert about mailing lists, and I hope I didn't use this one in =
a wrong way. I that case, I beg your pardon once more.
Best regards,
Cristiano Vaval=E0

[Guidolib-devel] Source code documentation

[Stephane L. <le...@gr...>]

There is a very interesting tool called Doxygen that allows to document C++
classes hierarchies. Look at :
http://www.stack.nl/~dimitri/doxygen/index.html

I propose to use it to document the GUIDOLib.


Stephane


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr

[Guidolib-devel] Implementing Musical Time Pos to Graphical Pos mapping

[Stephane L. <le...@gr...>]

Hi Kai,


Juergen told me that you may have more time to answer some Guido
questions (: 


For the Imutus prototype I implemented a MusicalPos to GraphicalPos
mapping by directly hacking the OnDraw method of some graphic classes.
It was made the following way:


- patch the GRSingleNote and GRSingleREst methods to keep the pair
(Musical Time Pos and Graphical Pos [ x, y values]) in a list.


- for chords I find out that all notes in the chord do not have the
correct Musical Time value, i had to keep the value of the preceding
"empty" object and associate it to all notes of the chord.


- after this step, the (MusicalTimePos, GraphicalPos) list is scanned,
and the YMix,YMax values for all notes inside a system is computed.
This (YMix,YMax) value is then associated to all notes of the
corresponding system.


- a GuidoMusiclPos2GraphicalPos function  allow to retrieve the
GraphicalPos corresponding to a given  MusicalPos in the form (X, YMin,
YMax). This allows to later display a cursor at the right x position
with a correct y dimension.


During the coding i found several problems:


- it seems that there is a problem in the [system, page] data
structure.  The last system of a page does not point to its containing
page but to the next page.  Is this the expected behavior? it seems
like a bug but i was not able to find at which step it could occur.

This problem does no occur in an explicit \newPage tag is used.


It seems that this problem also explains the strange behavior of the
GuidoGetPageRTP function.


- the GuidoGetPageNum(int num, int denom) returns -1 when the given
(num, denom) values do not correspond to existing musical symbols in
the structure. 



Could you help me found the last system pointer bug? Do you have any
advice on when and how this mapping structure could be built in a
cleaner way?



Thanks in advance


Stephane 







Grame: Centre National de creation musicale

9, Rue du Garet

69001 Lyon

Tel: 04-72-07-37-00

Fax: 04-72-07-37-01

Web: www.grame.fr

[Guidolib-devel] GUIDOLib API proposal change

[Jerome B. <be...@gr...>]

Hi

I'm currently implementing a wxWindows version of the GuidoLib. In order to 
make it cross-platform, and to resolve some dependencies, such as fonts and 
graphics, I propose to add an initialization function to the Guido API:

int GuidoInit( GuidoInitDesc * desc );

GuidoInitDesc is defined as follow:
typedef struct
{
	GDevice	*	graphicDevice;		// NULL: use default device
	GuidoFeedback * 	feedback;		// NULL: no feedback
} GuidoInitDesc;

This function initialize the GuidoLib engine with the resources necessary 
to provide feedback at user level (but in charge of the client application) 
and to access the graphical device and fonts. Implementation of the 
corresponding objects is platform dependent. It ensures the engine portability.

Actually, this function should be called before any graphic layout, but as 
this layout is interleaved within parsing methods, it is better to 
recommend calling this function at initialization time.

Jerome Berthet
Grame: Centre National de creation musicale
www.grame.fr

[Guidolib-devel] New change log file in CVS

[Stephane L. <le...@gr...>]

A changelog file has been added in CVS. Please use it to summarize any
significant change made on CVS.

Stephane


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr

[Guidolib-devel] Parser source code cleanup

[Stephane L. <le...@gr...>]

The parser code has be cleanup up in the following way:

- library specific part of the guido.cpp file have been removed and moved
in new files in the corresponding libraries (GUIDOEngine and Guido2Midi).
The guido.cpp file should now contain only common code.

- new gd_imp_init and gd_imp_exit entry points have been added in the
guido.h file. Their purpose in to allow library implementation of the
parser API to have  specific initialization and cleanup code.
gd_imp_init and gd_imp_exit functions are called in the parser global
gd_init and gd_exit entry points.

- new files GUIDOEngineParser.cpp (GUIDOEngine library) and
Gmn2MidiParser.cpp (Gmn2Midi library) have been added.


Stephane


Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72-07-37-00
Fax: 04-72-07-37-01
Web: www.grame.fr

[Guidolib-devel] note server change: midifile import

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

Hi,

I've committed a behavior change for the note server on cvs: it concerns the midifile import. It allows to associate a .ini file with a .mid file.

When importing a file named xxx.mid, previous version was making use of the fermata.ini file. The new version looks first for a xxx.ini file at the same location than the xxx.mid file: it uses the xxx.ini file when it exists or revert to the default behavior when it doesn't exist.

dom

[Guidolib-devel] Added lyric support for finale-plugin

[<ki...@it...>]

Hi,

I just added a lyrics support to the GUIDO Export finale plugin.

All lyrics of a finale file can now be exported as \lyrics tags to .gmn 
file. It is also possible to specify a fontsize and a dy inside the 
f2guido dialog box.

All types of finale lyrics (verse, chorus, etc. ) will be exported the 
same way.

I needed to add eeddata.h from the finale sdk to our repository.


Regards
Juergen Kilian

[Guidolib-devel] guido2gif changes

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

Hi,

I've made some changes to the G2GIFCreatePicture API: it takes now an additional parameter like below:
Guido2GIF_API int G2GIFCreatePicture(int handle,
					 double zoom,
					 int sizex,
					 int sizey,
					 int adjustpagesize,
					 int pagenum,
					 int dops,
					 const char * psname,
					 const char * outname,
					 const char * idstr)

This idstr parameter points to a string which is to be added to the gif picture at the left bottom corner. This string was previously automatically added and its content wasn't available to client applications.

The guido2gif tool has been consequently modified: the G2GIFCreatePicture call has an IDSTR additional argument which actually points to NULL:
const char * IDSTR = 0;

dom

Re: [Guidolib-devel] duplicate definitions

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

Hi Juergen,

>Hi Dominique,
>
>I noticed that warnings also.
>The original definitions are in guido.h (= part of the parser kit).
>The problem is that Kai did some unauthorised :-) changes to the parser
>kit, including (for some strange reason) the copy of that definitions.
>
>So if it is possible to keep the defs in guido.h and remove the
>definitions in grdefine.h. That would be compatible to the current
>parser kit.
>
>A new guidodefs.h is also ok (maybe even better) but we should keep
>that change in mind when using an updated parser kit. I'll ask Holger
>to include it in an updated version, but I'm not sure when it will
>happen :-)

you can include it directly within the yacc & lex code


>
>In both cases:
>Because some of the definitions in guido.h are different from those in
>grdefines. h (REST, EMPTY) we need to check if the noteviewer and
>gmn2midi work correct with the guido.h defs.
>
at first glance it should not be a problem

We'll make the modification (creating a guidodefs.h file).

Next I've added an additional preprocessor directive named USEDIALOGS to the lib-score-engine project. It is used to control the score engine behavior in regard of feedback: when you want to display progress dialogs, you have to define this new macro.
In fact, this is a temporary solution, I think the best thing to do is to move the progress information display to the client part. To do so, we could modify the API of the functions that currently use dialog boxes and add a callback parameter. This callback should be called by the engine accordingly to the processing progress and the client could display (or not) the corresponding information.
This is a proposal but I can't implement it now (due to lack of time - it supposes also to modify the note viewer). And that's why I've committed the new macro version.

Another problem is due to the resource file within the noteviewer project: in fact, the gmnview32.rc file isn't automatically compiled when you build the project; you have to select the file individually and to force the compilation manually (otherwise the resources are not included and the application can't run).
Do you have an idea of the solution? is it due to bad project settings?

dom

[Guidolib-devel] duplicate definitions

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

Hi,

When compiling the score-engine lib, a lot of warning are issued concerning redefined macros. These are mainly the NOTE_* macros defined in ../parser/guido.h and redefined in graphics/GRDefine.h.
In fact, it seems that the appropriate location for these definitions is the parser folder. I think that these definitions could be put in a separate file (parser/guidodefs.h for example), removed from graphics/GRDefine.h and guido.h.
Next, the source files using these definitions could use guidodefs.h.
What do you think about it ?

Dom