This is from the news file at http://www.op.net/~pbd/quasimodo/. I've
been away a lot, and busy, and miserable, and divorced. But I'm back,
my daughter Hannah is back in school, and I'm programming like a
crazed weasel again :)

--p

  September 16th
          Its been a long summer.

          Well, I'm back from a summer of travelling and getting a
          divorce. Its time to get started again, and as a start, several
          major new items:

          + the UI is now not even linked at compile time - Quasimodo
            dynamically loads the libraries you specify in the config
            file, and then looks for a function called "ui_init" within
            them to create the user interface. Switch UI's at run time
            from GTK+ to GNU readline (command line) and even (at some
            point) to Stephane's Python interface for Quasimodo!
          + new internal API to allow patching to be carried out from
            such things as a command line UI
          + XML in use for preset files; support for XML module
            definitions is almost complete, thanks to Stephane. We now
            use gnome-xml, instead of expat.
          + Quasimodo is itself now a library! Quasimodo the program is
            very simple, something roughly like this:

                main (int argc, char *argv[])
                {
                     Quasimodo q (&argc, argv);

                     if (q.ok())
                         q.start ();

                }
            This new structure will now allow Quasimodo to be used as an
            audio engine from other programs, using the new API when
            necessary to load/unload modules, set up patches and control
            parameters.
          + Basic support for machines with > 2 processors is now in
            place. You will soon be able to run each "cabinet" on its own
            processor. If anyone has the cash for a 4-CPU Xeon machine,
            it would be a nice contender for the Pulsar, except that the
            Pulsar costs less than the motherboard+1 Xeon!

          Work to be done in the immediate future include some
          considerable effort on the appearance of the UI, making the
          modules more interesting and useful, and getting input to work
          smoothly and efficiently. None of these are trivial. But expect
          lots of work on this stuff, soon!.
                                            

This sounds good...!

-----Original Message-----
From: Paul Barton-Davis [mailto:pbd@Op.Net]
Sent: Thursday, September 16, 1999 12:12 AM
To: csound@maths.ex.ac.uk; csound-unix-dev@ilogic.com.au
Subject: [Quasimodo] news after the long, hot summer


This is from the news file at http://www.op.net/~pbd/quasimodo/. I've
been away a lot, and busy, and miserable, and divorced. But I'm back,
my daughter Hannah is back in school, and I'm programming like a
crazed weasel again :)

--p

  September 16th
          Its been a long summer.

          Well, I'm back from a summer of travelling and getting a
          divorce. Its time to get started again, and as a start, several
          major new items:

          + the UI is now not even linked at compile time - Quasimodo
            dynamically loads the libraries you specify in the config
            file, and then looks for a function called "ui_init" within
            them to create the user interface. Switch UI's at run time
            from GTK+ to GNU readline (command line) and even (at some
            point) to Stephane's Python interface for Quasimodo!
          + new internal API to allow patching to be carried out from
            such things as a command line UI
          + XML in use for preset files; support for XML module
            definitions is almost complete, thanks to Stephane. We now
            use gnome-xml, instead of expat.
          + Quasimodo is itself now a library! Quasimodo the program is
            very simple, something roughly like this:

                main (int argc, char *argv[])
                {
                     Quasimodo q (&argc, argv);

                     if (q.ok())
                         q.start ();

                }
            This new structure will now allow Quasimodo to be used as an
            audio engine from other programs, using the new API when
            necessary to load/unload modules, set up patches and control
            parameters.
          + Basic support for machines with > 2 processors is now in
            place. You will soon be able to run each "cabinet" on its own
            processor. If anyone has the cash for a 4-CPU Xeon machine,
            it would be a nice contender for the Pulsar, except that the
            Pulsar costs less than the motherboard+1 Xeon!

          Work to be done in the immediate future include some
          considerable effort on the appearance of the UI, making the
          modules more interesting and useful, and getting input to work
          smoothly and efficiently. None of these are trivial. But expect
          lots of work on this stuff, soon!.

just a quick heads up on what's been going on with Quasimodo.

prompted by several people and several things, Quasimodo has now been
completely split into completely independent pieces:

	   * libpbd:    a C++ library of utility functions and classes
	   * libmidi++: a C++ library that uses libsigc++ to provide
			rather nice access to a MIDI device
	   * libsoundfile: a C++ rendering of the best ideas from
			   Bill Schottstaedt's sndlib
           * libaudiohw: a C++ library abstracting away audio hardware
           * libquasimodo: the core DSP engine of Quasimodo
	   
	   * opcodes-gpl: Csound opcodes that were released under the GPL
			  or permission was granted to me to do so
           * opcodes-non-gpl: Csound opcodes still under the MIT license
	   
	   * gtk-quasimodo: a GTK user interface to a quasimodo engine
	   * server-quasimodo: a TCP/IP server interface to a quasimodo engine

each of these pieces now comes with its own GNU autoconf/automake
files so that it can be built on any platform supporting the basic
functionality that that piece requires from the compiler, standard
libraries, operating system and hardware. Those requirements are:

	   * libsigc++ ported (true for most mainstream and semi-mainstream
			       platforms)
           * C++ compiler that can handle namespaces, exceptions, and
			       a few other minor modern features
           * pthreads (POSIX P.1003 standard)

if your system has these, then implementing the required classes to
port libmidi and libaudiohw should take about 1 hour each.
	   
currently, this is all only in CVS: no tarballs have been constructed,
and it will be little while before they are.

--p
--