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

Re: [Guidolib-devel] problems on Quartz intel?

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

Hi Josh,

Sorry for the delay to reply, I'm just back from the ICMC... and  
welcome to the Guidolib!


Le 20 août 08 à 19:43, Josh Parmenter a écrit :

> Hi all,
>
> I am interested in developing some tools based on the GUIDO lib  
> (specifically, a command line tool for converting a gmn file into an  
> image file). I was very impressed to see that this is pretty  
> straight forward to do with the lib! I compiled the GUIDOEngine  
> framework, and have a basic program working, but the output for any  
> file format is just a black square.
>
> I also found out that the same thing happens if you try to export an  
> image file from the sample GuidoQuartzViewer. I built a native intel  
> version, and all that comes out are black squares. BUT - with the  
> PPC version that is floating around on the net, export works fine.  
> So it seems like this may be an architecture issue. Has anyone else  
> seen this before (or know of a solution) before I start digging?

This is not an architecture issue. Actually, the export features of  
the GuidoQuartzViewer need to be restored. The mac os graphic api has  
evolved a lot since the viewer initial design and the export features  
have not been properly maintained. On Mac OS 10.5, there is also now  
whole bunch warnings due to obsolete api... :-(
Note that the library now supports Qt and that we're currently trying  
to save time in maintaining cross platform developments. However, any  
fix to the GuidoQuartzViewer issues will be welcome.
Note also that a switch of the repository to svn is currently in  
progress (with significant code restructuration) but not yet available.

> And - here is a little more info on my background / project in case  
> anyone is interested. I've been using NoteAbility Pro for a few  
> years now, and developed an interface for the SuperCollider sound  
> synthesis language for algorithmically generating GUIDO scores. This  
> already works pretty well, and I am planning on extending the  
> library so SuperCollider can also display choices so a composer can  
> make decisions based on a displayed score. If anyone is interested  
> in seeing the basic SuperCollider interface, please let me know. I'd  
> be more then happy to share some basic examples.

Very interesting. I'd like to see some examples.

Regards,
Dominique


>
> Hope all is well.
>
> Thanks,
>
> Josh
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> “Every composer – at all times and in all cases – gives his own  
> interpretation of how modern society is structured: whether actively  
> or passively, consciously or unconsciously, he makes choices in this  
> regard. He may be conservative or he may subject himself to  
> continual renewal; or he may strive for a revolutionary, historical  
> or social palingenesis." - Luigi Nono
> */
>
> -------------------------------------------------------------------------
> 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] problems on Quartz intel?

[Josh P. <jo...@re...>]

On Sep 2, 2008, at 8:25 AM, Dominique Fober wrote:

> Hi Josh,
>
> Sorry for the delay to reply, I'm just back from the ICMC... and  
> welcome to the Guidolib!
>
thanks! and no problem :) How was the conference? Sorry to miss it  
this year (there was quite a but going on that looked good).
>
> Le 20 août 08 à 19:43, Josh Parmenter a écrit :
>> Hi all,
>>
>> I am interested in developing some tools based on the GUIDO lib  
>> (specifically, a command line tool for converting a gmn file into  
>> an image file). I was very impressed to see that this is pretty  
>> straight forward to do with the lib! I compiled the GUIDOEngine  
>> framework, and have a basic program working, but the output for any  
>> file format is just a black square.
>>
>> I also found out that the same thing happens if you try to export  
>> an image file from the sample GuidoQuartzViewer. I built a native  
>> intel version, and all that comes out are black squares. BUT - with  
>> the PPC version that is floating around on the net, export works  
>> fine. So it seems like this may be an architecture issue. Has  
>> anyone else seen this before (or know of a solution) before I start  
>> digging?
>
> This is not an architecture issue. Actually, the export features of  
> the GuidoQuartzViewer need to be restored. The mac os graphic api  
> has evolved a lot since the viewer initial design and the export  
> features have not been properly maintained. On Mac OS 10.5, there is  
> also now whole bunch warnings due to obsolete api... :-(
> Note that the library now supports Qt and that we're currently  
> trying to save time in maintaining cross platform developments.  
> However, any fix to the GuidoQuartzViewer issues will be welcome.
> Note also that a switch of the repository to svn is currently in  
> progress (with significant code restructuration) but not yet  
> available.

I noticed the API warnings and as I looked through more of the code, I  
was starting to wonder if those were the problem (since I imagined any  
architecture / endianness things would be taken care of by the  
compiler???). I'll take a little more of a look later. I actually  
don't need any GUI at all for the project I am working on, and the  
move to QT makes quite a bit of sense.

I'll write with questions later. I was thinking about just trying to  
use one of the more generic C/C++ graphics libraries to export simply  
to jpeg, gif or tiff (and avoiding the whole OSX only libraries), but  
didn't get too far with that when other matters became a little more  
pressing!
>
>> And - here is a little more info on my background / project in case  
>> anyone is interested. I've been using NoteAbility Pro for a few  
>> years now, and developed an interface for the SuperCollider sound  
>> synthesis language for algorithmically generating GUIDO scores.  
>> This already works pretty well, and I am planning on extending the  
>> library so SuperCollider can also display choices so a composer can  
>> make decisions based on a displayed score. If anyone is interested  
>> in seeing the basic SuperCollider interface, please let me know.  
>> I'd be more then happy to share some basic examples.
>
> Very interesting. I'd like to see some examples.

Are you familiar with SuperCollider? If you are (or if you have it  
installed), let me know and I can send you some sample code. A number  
of pieces on my website were done by generating GUIDO algorithmically  
from SuperCollider -> NoteAbility, then tweaking graphics. If you  
would like to see some of those, they are here:

http://www.realizedsound.net/josh/Music/Music.html

Both Anacrusis and Palimpsest were GUIDO generated. There will be a  
couple more posted there later this week (the site needs updating!)

Thanks for the reply.

best,

Josh

>
> Regards,
> Dominique
>
>
>>
>> Hope all is well.
>>
>> Thanks,
>>
>> Josh
>>
>> ******************************************
>> /* Joshua D. Parmenter
>> http://www.realizedsound.net/josh/
>>
>> “Every composer – at all times and in all cases – gives his own  
>> interpretation of how modern society is structured: whether  
>> actively or passively, consciously or unconsciously, he makes  
>> choices in this regard. He may be conservative or he may subject  
>> himself to continual renewal; or he may strive for a revolutionary,  
>> historical or social palingenesis." - Luigi Nono
>> */
>>
>> -------------------------------------------------------------------------
>> 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
>

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

[Guidolib-devel] problems on Quartz intel?

[Josh P. <jo...@re...>]

Hi all,

I am interested in developing some tools based on the GUIDO lib  
(specifically, a command line tool for converting a gmn file into an  
image file). I was very impressed to see that this is pretty straight  
forward to do with the lib! I compiled the GUIDOEngine framework, and  
have a basic program working, but the output for any file format is  
just a black square.

I also found out that the same thing happens if you try to export an  
image file from the sample GuidoQuartzViewer. I built a native intel  
version, and all that comes out are black squares. BUT - with the PPC  
version that is floating around on the net, export works fine. So it  
seems like this may be an architecture issue. Has anyone else seen  
this before (or know of a solution) before I start digging?

And - here is a little more info on my background / project in case  
anyone is interested. I've been using NoteAbility Pro for a few years  
now, and developed an interface for the SuperCollider sound synthesis  
language for algorithmically generating GUIDO scores. This already  
works pretty well, and I am planning on extending the library so  
SuperCollider can also display choices so a composer can make  
decisions based on a displayed score. If anyone is interested in  
seeing the basic SuperCollider interface, please let me know. I'd be  
more then happy to share some basic examples.

Hope all is well.

Thanks,

Josh

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

[Guidolib-devel] New SDKs, Qt support and new applications

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

Hi all,

The Guido Engine Library SDKs have been updated to the version 1.34 on  
the sourceforge download section.
In addition, Qt is now supported via a specific SDK, also available to  
download (requires Qt 4.4).
Guido Qt applications have also been published in binary form for  
MacOS and Windows (linux is supported but not in binary form): it  
includes a guido viewer and a guido scores composer.

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

Best,
--
Dominique Fober


----------------------------------------------------------------
Version 1.3.4 change log
- parser rewritten (no syntax changes)
   not supported any more:
	empty tag parameters list:	\tag<>
	unknown note name:		i j ... z
	unknown tag name
	incorrect sequence specification: { [ c d e ] ] } or { [ [ c d e ] }
   behavior change:
	escape char in strings:	 '\' was used to encode "  -> \" it is now  
stripped by he parser
- new GuidoParseString API
- incorrect slice list corrected with repeat sections.

[Guidolib-devel] Guidolib development kit v1.33

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

Hi all,

The Guido Engine Library SDKs have been updated to the version 1.33 of  
the Guido engine on the sourceforge download section. See at: http://sourceforge.net/project/showfiles.php?group_id=68683
Note also that a binary SDK is now available for GNU Linux, but it  
doesn't include graphic devices. See the sdk readme.txt file for more  
information.

Best regards,
---
Dominique Fober

[Guidolib-devel] cvs repository is back

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

Hi all,

The guidolib cvs repository is finally back (it took more time than  
expected).
The tarball restoration has also been the opportunity to move the  
root of the repository to the standard 'project-name' directory.  
Therefore the main guidolib module is now 'guidolib' instead of 'src'  
for the previous cvs tree. Consequently you'll have to refresh your  
local copy of the repository and to issue a new cvs checkout.
To summarize:
anonymous cvs root is    	:pserver:ano...@cv...:/ 
cvsroot/guidolib	[unchanged]
main module is            	 
guidolib                                                							 
[ changed ]

Best,
Dominique

Re: [Guidolib-devel] Using GDeviceWx in GuidoLib Development Kit

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

Sorry, but I can't reproduce the problem here: I don't have wxWidgets =20=

installed, nor Dev-Cpp.
Could you provide a project that reproduces the problem without =20
requiring wx ?
Dom

Le 23 mars 06 =E0 09:58, Tristan Peralta a =E9crit :

> here is my complete code. i have already include GUIDOEngine.lib in =20=

> my project but still i got a linker error. I use Dev-Cpp and =20
> wxWidgets.
>
> I also tried using GDeviceWin32, but still i have a linker error.
>
> Dominique Fober <fo...@gr...> wrote:
> Hi Tristan,
>
> The context of the error is not clear to me: it seems that you're
> trying to use the wxWindows device (GDeviceWx) but your code refers
> to GDeviceWin32.
> Concerning the wxWindows device, you have to know that it's not
> maintained any more (for a couple of years). Compiling this device is
> likely to fail, but adapting the code to the current wx library is
> probably a lightweight task.
>
> But looking at your source code, it seems that you're using the
> GDeviceWin32 from the win32 dev kit 1.3.2 (is it right?).
> I've tried to reproduce the problem, but without success. First, the
> 'SelectW32Object' (line 196) problem is just a warning due to the
> inconsistency between inline and dllimport, you can safely ignore the
> warning.
>
> Concerning the linker error: do you include the 'GUIDOEngine.lib'
> file into your project ? (the GDeviceWin32 is actually included in
> the GUIDEngine.dll)
>
> best,
> Dominique
>
>
> Le 17 mars 06 =E0 19:07, Tristan Peralta a =E9crit :
>
> > Hi, I am developing an application using GuidoLib DevKit and
> > wxWidgets. My problem is I can't configure my GDeviceWx in Guido
> > Devkit. I tried an alternative using a nativeDC in GDeviceWin32 but
> > no luck. It has a linker error. Here is my code:
> >
> > #include "../gdevices/GDeviceWin32.h"
> >
> > GRHandler gr;
> > HDC__* hdc;
> > GDeviceWin32 gdc(hdc, 800, 100);
> > GuidoOnDrawDesc desc;
> > desc.handle =3D gr;
> > desc.hdc =3D gdc;
> >
> > here is the error.
> > 196 C:\projects\guidolib-devkit-v1-3-2\gdevices\GDeviceWin32.h
> > [Warning] 'void* GDeviceWin32::SelectW32Object(const void*) const'
> > defined locally after being referenced with dllimport linkage
> >
> > [Linker error] undefined reference to `import stub for
> > _ZN12GDeviceWin32C1EP5HDC(int, int)'
> >
> > What do you think is the problem? Thanks
> >

Re: [Guidolib-devel] Using GDeviceWx in GuidoLib Development Kit

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

Hi Tristan,

The context of the error is not clear to me: it seems that you're =20
trying to use the wxWindows device (GDeviceWx) but your code refers =20
to GDeviceWin32.
Concerning the wxWindows device, you have to know that it's not =20
maintained any more (for a couple of years). Compiling this device is =20=

likely to fail, but adapting the code to the current wx library is =20
probably a lightweight task.

But looking at your source code, it seems that you're using the =20
GDeviceWin32 from the win32 dev kit 1.3.2 (is it right?).
I've tried to reproduce the problem, but without success. First, the =20
'SelectW32Object' (line 196) problem is just a warning due to the =20
inconsistency between inline and dllimport, you can safely ignore the =20=

warning.

Concerning the linker error: do you include the 'GUIDOEngine.lib' =20
file into your project ? (the GDeviceWin32 is actually included in =20
the GUIDEngine.dll)

best,
Dominique


Le 17 mars 06 =E0 19:07, Tristan Peralta a =E9crit :

> Hi, I am developing an application using GuidoLib DevKit and =20
> wxWidgets. My problem is I can't configure my GDeviceWx in Guido =20
> Devkit. I tried an alternative using a nativeDC in GDeviceWin32 but =20=

> no luck. It has a linker error. Here is my code:
>
> #include "../gdevices/GDeviceWin32.h"
>
> GRHandler gr;
> HDC__* hdc;
> GDeviceWin32 gdc(hdc, 800, 100);
> GuidoOnDrawDesc desc;
> desc.handle =3D gr;
> desc.hdc =3D gdc;
>
> here is the error.
> 196 C:\projects\guidolib-devkit-v1-3-2\gdevices\GDeviceWin32.h =20
> [Warning] 'void* GDeviceWin32::SelectW32Object(const void*) const' =20
> defined locally after being referenced with dllimport linkage
>
>   [Linker error] undefined reference to `import stub for =20
> _ZN12GDeviceWin32C1EP5HDC(int, int)'
>
> What do you think is the problem? Thanks
>
>
>
> Get Firefox, much better than IE!
>
> Do you Yahoo!?
> Try the new Yahoo! Philippines Front Page!

[Guidolib-devel] Using GDeviceWx in GuidoLib Development Kit

[Tristan P. <tri...@ya...>]

Hi, I am developing an application using GuidoLib DevKit and wxWidgets. My problem is I can't configure my GDeviceWx in Guido Devkit. I tried an alternative using a nativeDC in GDeviceWin32 but no luck. It has a linker error. Here is my code:

#include "../gdevices/GDeviceWin32.h"

GRHandler gr;
HDC__* hdc;
GDeviceWin32 gdc(hdc, 800, 100);
GuidoOnDrawDesc desc;
desc.handle = gr;
desc.hdc = gdc;

here is the error.
196 C:\projects\guidolib-devkit-v1-3-2\gdevices\GDeviceWin32.h [Warning] 'void* GDeviceWin32::SelectW32Object(const void*) const' defined locally after being referenced with dllimport linkage 

  [Linker error] undefined reference to `import stub for _ZN12GDeviceWin32C1EP5HDC(int, int)' 

What do you think is the problem? Thanks



Get Firefox, much better than IE! 
		
---------------------------------
Do you Yahoo!?
Try the new Yahoo! Philippines Front Page!

[Guidolib-devel] cvs tarball restoration in progress

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

Hi all,

Due to some erroneous cvs commands, a cvs tarball restoration (based  
on the nightly tarball dated march 15) is currently in progress. As  
you might know, a tarball import cannot be directly done, you have to  
post a support request to the sourceforge team. This is why the  
restoration is still pending. I hope it'll be effective very soon. In  
the meantime, don't commit anything to cvs. I'll post a message as  
soon as the situation is back to the normal.

best
Dominique

[Guidolib-devel] midi2gmn.dll update

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

The midi2gmn.dll which handles the import midi and midi to GUIDO 
functions of the GUIDOLib applications has been updated in the dvl and 
main branch of the GUIDOLib CVS repository.
A detailed description  of the implementation and its parameters 
(defined in fermata.ini) can be found in
http://www.noteserver.org/kilian/diss-jfk-final.pdf

It should be possible to replace the midi2gmn.dll of an existing 
Noteviewer installation by the new version without re-compiling other 
parts of the system.



Regards

Juergen F. Kilian

[Guidolib-devel] Guidolib development kits

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

Hi all,

Binary versions of the Guido engine library have been published under 
the form of development kits for the windows and Mac os X platforms. 
See at http://sourceforge.net/projects/guidolib
These development kits include:
- the full documentation in html and pdf format,
- binary libraries version 1.3.2,
- header files,
- available graphic devices source code on a per-platform basis.

Best regards,
---
Dominique Fober

Re: [Guidolib-devel] WinCE GUIDO

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

Hi,

iostream is not necessary for the engine operations. They are mainly=20
used for printing information and for debugging purpose. It should be=20
similar for sstream.
Concerning the stl libraries, maybe your problem comes more from the=20
compiler than from the libraries themselves. In fact, the=20
GUIDOEngine.dll only depends on kernel32.dll, user32.dll adn gdi32.dll:=20=

could you consider compiling on another platform (xp or 2000) and=20
running on WinCE ?
best,
---
Dominique Fober

ps: below you'll find a summary of the C++ specific libraries used=20
within the project.
ps: update your version of the source code, I've committed some changes=20=

on the cvs dev branch, they concern these include files issues.

Le 14 f=E9vr. 05, =E0 16:41, Jorge Alberto Cervantes Montiel a =E9crit :

> Ups. The first big problem is that there is not support available for
> STL within embedded visual c++. I have tried with stl_evc and stlport
> (without good results), but there is no support for iostream too...
>
> I'm supposed that I'm must cut many parts of the code. Or to base in
> GUIDOLib to write a version for WinCe.
>
> what do you think?
>
>
> regards
>

C++ specific libraries summary
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
#include <cassert>		could probably be replaced by "assert.h"
#include <cfloat>		probably only used to define constants =
like DBL_MIN=20
etc...
					could probably be replaced by =
"float.h"
#include <climits>		see cfloat, could probably be replaced =
by "limits.h"
#include <cmath>		could probably be replaced by "limits.h"
#include <cstdio>		could probably be replaced by "stdio.h"
#include <cstdlib>		could probably be replaced by "stdlib.h"
#include <ctype.h>		could probably be replaced by "stdlib.h"

#include <fstream>		these are used for printing info and =
debugging=20
purpose
#include <iosfwd>		could be replaced by std io functions =
(stdio)
#include <iostream>	...

#include <sstream>		this could be a little bit more =
problematic because=20
they are
#include <strstream>	generally used in place of iostreams

#include <typeinfo>	must be available for RTTI but should be =
available=20
if your
					compiler supports RTTI =
(required)

and here are the real stl library dependencies: string, map and vector=20=

require probably
a more significant effort to be replaced but their use is quite limited.
#include <string>
#include <map>
#include <vector>

[Guidolib-devel] WinCE GUIDO

[Jorge A. C. M. <ac...@gm...>]

Ups. The first big problem is that there is not support available for
STL within embedded visual c++. I have tried with stl_evc and stlport
(without good results), but there is no support for iostream too...

I'm supposed that I'm must cut many parts of the code. Or to base in
GUIDOLib to write a version for WinCe.

what do you think?


regards

Re: [Guidolib-devel] WinCE

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

Le 10 f=E9vr. 05, =E0 19:41, Jorge Alberto Cervantes Montiel a =E9crit :

> I'm gonna try to make a port for WindowsCE of the GUIDO library. I
> want to know if there a list of files to port. I'm understand that I
> must extend VGDevice (maybe in GDeviceWinCE3).
>
> There is a checklist of another files to be modified for get a
> runnable copy of the library in another platform?

Actually, only the VGDevice class (which is an abstract class) has to=20
be implemented for the target platform. I don't know what are exactly=20
the differences between WindowsCE and XP/2000, but I suppose that you=20
can start from the existing GDeviceWin32 (located in win32/src), maybe=20=

it works as is.
Please, keep us informed.
Best regards,
---
Dominique Fober

[Guidolib-devel] WinCE

[Jorge A. C. M. <ac...@gm...>]

I'm gonna try to make a port for WindowsCE of the GUIDO library. I
want to know if there a list of files to port. I'm understand that I
must extend VGDevice (maybe in GDeviceWinCE3).

There is a checklist of another files to be modified for get a
runnable copy of the library in another platform?

Regards.

----

Re: [Guidolib-devel] Flex, Bison

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

Le 9 f=E9vr. 05, =E0 19:58, Jorge Alberto Cervantes Montiel a =E9crit :

> Hello.
>
> =BFWhere in the CVS are the files to generate the lexer and the parser
> for GUIDO language?
>
> Regards
>

They are not in the repository, only C output of these files is=20
included.

---
Dominique Fober

[Guidolib-devel] Flex, Bison

[Jorge A. C. M. <ac...@gm...>]

Hello.

=BFWhere in the CVS are the files to generate the lexer and the parser
for GUIDO language?

Regards

[Guidolib-devel] src code package 1.3.2

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

Hi to all,

The guidolib is available as a src code package on sourceforge ( 
http://sourceforge.net/projects/guidolib ). It includes the latest 
version 1.3.2 of the library as well as the developer documentation 
(html and pdf formats).
Best regards,
---
Dominique Fober

Re: [Guidolib-devel] NSGuidoView??

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

Dear Matthew,

Building an NSView should be a matter of a few lines of code using the=20=

Guido Engine API. However, I don't use and don't know Objective C but I=20=

guess it supports calls to external C frameworks.
See the sample code that goes along with the guido engine documentation=20=

(and with the src code).
Best,
---
Dominique Fober


Le 12 d=E9c. 04, =E0 16:24, Matthew Johnson a =E9crit :

> I'm wondering if you've thought about making the notation rendering=20
> engine available as an NSView that can be used by Cocoa developers?  I=20=

> have an application that needs to render music notation but I can't=20
> find a good notation view available and don't really want to write one=20=

> at the moment...
>
> Regards,
> Matthew
>

[Guidolib-devel] NSGuidoView??

[Matthew J. <mus...@ma...>]

I'm wondering if you've thought about making the notation rendering 
engine available as an NSView that can be used by Cocoa developers?  I 
have an application that needs to render music notation but I can't 
find a good notation view available and don't really want to write one 
at the moment...

Regards,
Matthew

[Guidolib-devel] GUIDOLib v.1.3.2

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

Hi to all,

The GUIDOLib dev branch has been merged to the main branch. The 
corresponding version number is 1.3.2 and the main branch has been 
tagged with this version number (v1-3-2).

Main changes concern new tags implementation:
	\daCapo
	\daCapoAlFine
	\dalSegno
	\dalSegnoAlFine
	\daCoda
	\fine
	\coda
	\segno
	\volta

New releases of the binary viewers for windows and macos x have also 
been uploaded to the source forge file release system (see at 
http://sourceforge.net/projects/guidolib/ ).

Best,

---
Dominique Fober

[Guidolib-devel] GUIDOLib v.1.3.0

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

Hi to all,

The GUIDOLib dev branch has been merged to the main branch. The 
corresponding version number is 1.3.0 and the main branch has been 
tagged with this version number (v1-3-0).

A lot of changes and improvements have been made to the library. It 
includes support of specified but not yet implemented tags (like 
breath-mark), improvement of the automatic layout, bugs correction,... 
see the changelog.txt file for all the details.

But the most important change concerns the GUIDOLib API which has been 
completely redesigned and extended to support graphic mappings and 
dynamic build of music via the GUIDO Factory API.
Along with these changes, an important effort has also be made on the 
documentation for the developers.

Best,
---
Dominique Fober

Re: [Guidolib-devel] Guido Graphic Stream

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

Hi Scott,

Le 1 juin 04, =E0 04:56, J. Scott Amort a =E9crit :

> Hi All,
>
> I have been doing quite a bit of work with the GGS implementation over
> the past few months, and I think it is almost ready to go.  I have

That's a good news. We're to meet Holger at the end of the week.
He should present us the GGS implementation.

> synced up the ggs branch with the dev branch as of yesterday (05/30)=20=

> and
> committed all of my work to this point.  There are three main=20
> additions:
>
> (1) The implementation of GGS within the engine as a series of=20
> OnDrawGGS
> routines that parallel the OnDraw functions.  These functions are
> marshaled by a GuidoGGSFactory object which can then stream the output
> to a standard C++ iostream.  Still to be implemented is GGS input to=20=

> the
> factory object;
>
> (2) A GGS parser implemented as a mixed C/C++ flex/bison library; and
>
> (3) Two applications: guido2ggs, which converts a GMN file to GGS; and
> ggs2ps, which contrary to it's name is actually a general purpose GGS=20=

> to

why not renaming it to ggs2img ?

> image file converter.  It takes a GGS file and creates programmatic
> PostScript or EPS output, which can then also be converted to any of a
> variety of image formats (currently jpeg, bmp, gif, tiff, png, pict)
> with the help of the ImageMagick library.  Other formats are also
> available, but I've limited it to the above for now.
>
> Overall, the main problems still to be completed are scaled output =
(I'm
> waiting on Holger to decide on how he wants the GGS to address that),
> text placement and implementation of complex music elements such as
> tuplets.  There are also some spacing issues I've come across -
> collisions of articulations come to mind, plus some other musical
> problems (e.g. barlines that don't extend through systems), but I =
think
> it's looking pretty good.
>
> At any rate, after spending a few days syncing the latest dev branch
> into the ggs branch, I wanted to address the possibility of merging =
the
> two branches.  There really is only one issue that stands in the way =
of

Please wait a little before merging to the dev branch. We're currently
working on the library API and major changes are in progress. We would=20=

like
to publish rapidly a GUIDOLib SDK based on this new API and therefore,=20=

these
changes are to be merged soon to the main branch. Since we've also=20
strong
deadlines with our GUIDOLib based project (IMUTUS), we would preferably=20=

integrate
the GGS stuff after having release our IMUTUS prototypes.

You could have a look at the new API and make some comments. The best=20
way is
probably to make the documentation using doxygen. Note also that the=20
old APIs
have been preserved but to use them, you need to define a specific=20
label.


> this - the GuidoInitDesc and its dependence on a VGDevice.  In the GGS
> branch, I have changed this and created a device-independent
> GFontManager class that offers all of the font management routines
> needed by the GuidoInitDesc and ultimately, the
> gGlobalSettings.gDevice.  This GFontManager can also be used as a base
> class for a device-dependent derivation that can be attached to the
> VGDevice object if the user wants to use that mechanism, or left alone
> if GGS is the only required output.  However, this will necessitate a
> rewrite of all of the VGDevices (essentially, a GFontManagerXX will=20
> need
> to be subclassed for each VGDevice implementation and the font =
routines
> will be transferred to that object).  I sent an email to this list a
> while back detailing this, but didn't get any feedback on that
> strategy.  I'll assume that this means it wasn't enthusiastically
> received :-)  So, I'll suggest three options:
>
> (1) Go with my initial suggestion, and rewrite a bunch of the VGDevice
> code.  The VGDevice.h and VGDevice.cpp are actually already done in =
the
> GGS branch (they now require an embedded GFontManager), however all of
> the device specific classes will have to be redone to work with this=20=

> new
> implementation.  I did a GFontManagerPS and GDevicePostscript for
> testing, but all of the other platforms will have to be done as well.
> The strength of this suggestion is that the somewhat strange situation
> of having two VGDevices (one in the GuidoInitDesc and one in the

yes you're right!

> GuidoOnDrawDesc) which may or may not be the same, will be resolved,=20=

> and
> the font data will be device-independent (thus the engine can be
> compiled with or without a VGDevice, as seen fit by the user);
>
> (2) Use a series of preprocessor directives to allow for either a GGS=20=

> or
> a VGDevice implementation choice at compile time; or
>
> (3) Redo the GFontManager to be derived from VGDevice, but do not
> properly implement anything except the font routines.  It can then be
> used as the VGDevice required by GuidoInitDesc.  This won't require =
any
> code rewrites of the dev branch, but I'll have to change a number of
> things on the ggs side, and the OnDraw routines will be broken (unless=20=

> a
> second VGDevice is used for the GuidoOnDrawDesc, but that will get=20
> messy
> pretty quickly, I think).
>
> Option (2) seems to be the middle ground, while the other two will
> require a pretty major design change on one of our parts to get it
> going.  (1) or (3) will allow for both the VGDevice and GGS to be
> implemented within the same engine, but I think (3) will be a
> problematic implementation of this option.  Finally, (2) is an=20
> either/or
> choice - you won't be able to have both GGS and VGDevice.  What does
> everyone think?
>

We've also consider these issues while designing the new API and the=20
conclusion
was that a GFontManager was the best solution. The problem is that we=20
can't
work on it right now. We can plan to do it in July.

Again, since we're to meet Holger and Juergen soon, we'll discuss all=20
these points.

--dom

[Guidolib-devel] Guido Graphic Stream

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

Hi All,

I have been doing quite a bit of work with the GGS implementation over
the past few months, and I think it is almost ready to go.  I have
synced up the ggs branch with the dev branch as of yesterday (05/30) and
committed all of my work to this point.  There are three main additions:

(1) The implementation of GGS within the engine as a series of OnDrawGGS
routines that parallel the OnDraw functions.  These functions are
marshaled by a GuidoGGSFactory object which can then stream the output
to a standard C++ iostream.  Still to be implemented is GGS input to the
factory object;

(2) A GGS parser implemented as a mixed C/C++ flex/bison library; and

(3) Two applications: guido2ggs, which converts a GMN file to GGS; and
ggs2ps, which contrary to it's name is actually a general purpose GGS to
image file converter.  It takes a GGS file and creates programmatic
PostScript or EPS output, which can then also be converted to any of a
variety of image formats (currently jpeg, bmp, gif, tiff, png, pict)
with the help of the ImageMagick library.  Other formats are also
available, but I've limited it to the above for now.

Overall, the main problems still to be completed are scaled output (I'm
waiting on Holger to decide on how he wants the GGS to address that),
text placement and implementation of complex music elements such as
tuplets.  There are also some spacing issues I've come across -
collisions of articulations come to mind, plus some other musical
problems (e.g. barlines that don't extend through systems), but I think
it's looking pretty good.

At any rate, after spending a few days syncing the latest dev branch
into the ggs branch, I wanted to address the possibility of merging the
two branches.  There really is only one issue that stands in the way of
this - the GuidoInitDesc and its dependence on a VGDevice.  In the GGS
branch, I have changed this and created a device-independent 
GFontManager class that offers all of the font management routines
needed by the GuidoInitDesc and ultimately, the
gGlobalSettings.gDevice.  This GFontManager can also be used as a base
class for a device-dependent derivation that can be attached to the
VGDevice object if the user wants to use that mechanism, or left alone
if GGS is the only required output.  However, this will necessitate a
rewrite of all of the VGDevices (essentially, a GFontManagerXX will need
to be subclassed for each VGDevice implementation and the font routines
will be transferred to that object).  I sent an email to this list a
while back detailing this, but didn't get any feedback on that
strategy.  I'll assume that this means it wasn't enthusiastically
received :-)  So, I'll suggest three options:

(1) Go with my initial suggestion, and rewrite a bunch of the VGDevice
code.  The VGDevice.h and VGDevice.cpp are actually already done in the
GGS branch (they now require an embedded GFontManager), however all of
the device specific classes will have to be redone to work with this new
implementation.  I did a GFontManagerPS and GDevicePostscript for
testing, but all of the other platforms will have to be done as well. 
The strength of this suggestion is that the somewhat strange situation
of having two VGDevices (one in the GuidoInitDesc and one in the
GuidoOnDrawDesc) which may or may not be the same, will be resolved, and
the font data will be device-independent (thus the engine can be
compiled with or without a VGDevice, as seen fit by the user);

(2) Use a series of preprocessor directives to allow for either a GGS or
a VGDevice implementation choice at compile time; or

(3) Redo the GFontManager to be derived from VGDevice, but do not
properly implement anything except the font routines.  It can then be
used as the VGDevice required by GuidoInitDesc.  This won't require any
code rewrites of the dev branch, but I'll have to change a number of
things on the ggs side, and the OnDraw routines will be broken (unless a
second VGDevice is used for the GuidoOnDrawDesc, but that will get messy
pretty quickly, I think).

Option (2) seems to be the middle ground, while the other two will
require a pretty major design change on one of our parts to get it
going.  (1) or (3) will allow for both the VGDevice and GGS to be
implemented within the same engine, but I think (3) will be a
problematic implementation of this option.  Finally, (2) is an either/or
choice - you won't be able to have both GGS and VGDevice.  What does
everyone think?

Best,
Scott