softwerk-dev

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

So, when you put this into conftest.C:

----------------------------------------------------------------------
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int); // BTW - I want to know where this comes from!
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }
----------------------------------------------------------------------

and then try to compile it with :

----------------------------------------------------------------------
c++ -o conftest -g -O2 \
-I/home/dlphilp/softwerk-1.99.1/libs/include \
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C  \
-L/home/dlphil \
p/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lltdl -lsigc \
-lpthread 
----------------------------------------------------------------------

what happens ?

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> ok, so try "rm config.cache" again, then send me the results (both the
> screen output and config.log.

Okay, see below.

Btw, I downloaded, built, and installed the latest libtool package from
the GNU site (libtool-1.3.5). I cleared the old versions (or I think I
have), and ran ldconfig again. Softwerk configuration still dies at the
same point:

From the screen:

make[1]: Leaving directory
`/home/dlphilp/softwerk-1.99.1/libs/build/pbd'
if [ ! -f .configured_gtkmmext ] ; then \
        (cd build/gtkmmext; ../../src/gtkmmext/configure
--disable-static --prefix=/home/dlphilp/softwerk-1.99.1/libs);\
        fi
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking cached system tuple... ok
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for c++... c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... yes
checking whether c++ accepts -g... yes
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for ranlib... ranlib
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
updating cache ./config.cache
checking for object suffix... o
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for sigc-config... /usr/local/bin/sigc-config
checking for libsigc++ - version >= 0.8.0... 1.0.1
checking if libsigc++ sane... yes
checking for glib-config... /usr/local/bin/glib-config
checking for GLIB - version >= 1.0.0... yes
checking for gtk-config... /usr/local/bin/gtk-config
checking for GTK - version >= 1.0.0... yes
checking for gtkmm-config... /usr/local/bin/gtkmm-config
checking for GTK-- - version >= 1.2.0... yes
checking for pbd-config...
/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
checking for libpbd - version >= 1.1.0... 1.1.1
checking if libpbd sane... no
configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
appear to be installed
make: *** [.configured_gtkmmext] Error 1


From config.log:

configure:604: checking host system type
configure:652: checking host system type
configure:673: checking target system type
configure:691: checking build system type
configure:716: checking cached system tuple
configure:762: checking for a BSD compatible install
configure:815: checking whether build environment is sane
configure:872: checking whether make sets ${MAKE}
configure:918: checking for working aclocal
configure:931: checking for working autoconf
configure:944: checking for working automake
configure:957: checking for working autoheader
configure:970: checking for working makeinfo
configure:994: checking for c++
configure:1026: checking whether the C++ compiler (c++  ) works
configure:1042: c++ -o conftest    conftest.C  1>&5
configure:1068: checking whether the C++ compiler (c++  ) is a
cross-compiler
configure:1073: checking whether we are using GNU C++
configure:1082: c++ -E conftest.C
configure:1101: checking whether c++ accepts -g
configure:1139: checking for gcc
configure:1252: checking whether the C compiler (gcc  ) works
configure:1268: gcc -o conftest    conftest.c  1>&5
configure:1294: checking whether the C compiler (gcc  ) is a
cross-compiler
configure:1299: checking whether we are using GNU C
configure:1308: gcc -E conftest.c
configure:1327: checking whether gcc accepts -g
configure:1370: checking for ld used by GCC
configure:1433: checking if the linker (/usr/bin/ld) is GNU ld
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)
configure:1520: checking for ranlib
configure:1548: checking for BSD-compatible nm
configure:1585: checking whether ln -s works
ltconfig:590: checking for object suffix
ltconfig:591: gcc -c -g -O2  conftest.c 1>&5
ltconfig:721: checking if gcc PIC flag -fPIC works
ltconfig:722: gcc -c -g -O2 -fPIC -DPIC  conftest.c 1>&5
ltconfig:764: checking if gcc supports -c -o file.o
ltconfig:765: gcc -c -g -O2 -c -o conftest2.o  conftest.c 1>&5
ltconfig:792: checking if gcc supports -c -o file.lo
ltconfig:793: gcc -c -g -O2 -c -o conftest.lo  conftest.c 1>&5
ltconfig:844: checking if gcc supports -fno-rtti -fno-exceptions
ltconfig:845: gcc -c -g -O2 -fno-rtti -fno-exceptions -c conftest.c 
conftest.c 1>&5
ltconfig:888: checking if gcc static flag -static works
ltconfig:889: gcc -o conftest -g -O2   -static conftest.c  1>&5
GNU ld version 2.9.1 (with BFD 2.9.1.0.24)
ltconfig:1478: checking if global_symbol_pipe works
ltconfig:1479: gcc -c -g -O2  conftest.c 1>&5
ltconfig:1482: eval "/usr/bin/nm -B conftest.o | sed -n -e 's/^.*[     
]\([ABCDGISTW]\)[       ][      ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1
\2\3 \3/p' > conftest.nm"
ltconfig:1534: gcc -o conftest -g -O2 -fno-builtin -fno-rtti
-fno-exceptions   conftest.c conftstm.o 1>&5
configure:1963: checking for sigc-config
configure:1999: checking for libsigc++ - version >= 0.8.0
configure:2054: checking if libsigc++ sane
configure:2100: c++ -o conftest -g -O2 -I/usr/local/lib/sigc++/include
-I/usr/local/include   conftest.C  -L/usr/local/lib -lsigc -lpthread
1>&5
configure:2202: checking for glib-config
configure:2237: checking for GLIB - version >= 1.0.0
configure:2336: gcc -o conftest -g -O2 -I/usr/local/lib/glib/include
-I/usr/local/include   conftest.c -L/usr/local/lib -lglib  1>&5
configure:2472: checking for gtk-config
configure:2507: checking for GTK - version >= 1.0.0
configure:2608: gcc -o conftest -g -O2 -I/usr/local/lib/glib/include
-I/usr/local/include -I/usr/X11R6/include   conftest.c -L/usr/local/lib
-L/usr/X11R6/lib -lgtk -
lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm  1>&5
configure:2735: checking for gtkmm-config
configure:2771: checking for GTK-- - version >= 1.2.0
configure:2885: c++ -o conftest -g -O2 -I/usr/local/lib/gtkmm/include
-I/usr/local/include -I/usr/local/lib/glib/include -I/usr/X11R6/include
-I/usr/local/lib/sigc++
/include   conftest.C  -rdynamic -L/usr/local/lib -L/usr/X11R6/lib
-lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXext -lX11 -lm
-lsigc -lpthread 1>&5
In file included from /usr/include/g++-2/stl_alloc.h:57,
                 from /usr/include/g++-2/alloc.h:21,
                 from /usr/include/g++-2/std/bastring.h:39,
                 from /usr/include/g++-2/string:6,
                 from /usr/local/include/gtk--/base.h:28,
                 from /usr/local/include/gtk--.h:70,
                 from configure:2808:
/usr/include/stdlib.h:520: warning: declaration of `exit(int)' throws
different exceptions
configure:2805: warning: previous declaration here
configure:3020: checking for pbd-config
configure:3056: checking for libpbd - version >= 1.1.0
configure:3110: checking if libpbd sane
configure:3149: c++ -o conftest -g -O2
-I/home/dlphilp/softwerk-1.99.1/libs/include
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C 
-L/home/dlphil
p/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lltdl -lsigc
-lpthread 1>&5
configure: failed program was:
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }



Also this from /usr/local/lib:

[dlphilp@localhost lib]$ ls -l libltd*
-rw-r--r--   1 root     root        42742 Nov 27 15:17 libltdl.a
-rwxr-xr-x   1 root     root          647 Nov 27 15:17 libltdl.la
lrwxrwxrwx   1 root     root           16 Nov 27 15:17 libltdl.so ->
libltdl.so.0.1.2
lrwxrwxrwx   1 root     root           16 Nov 27 15:17 libltdl.so.0 ->
libltdl.so.0.1.2
-rwxr-xr-x   1 root     root        44631 Nov 27 15:17 libltdl.so.0.1.2



And from /usr/local/bin:

[dlphilp@localhost bin]$ ls -l libt*
-rwxr-xr-x   1 root     root       118871 Nov 27 15:17 libtool
-rwxr-xr-x   1 root     root         8117 Nov 27 15:17 libtoolize


Everything's been linked to /usr/lib and /usr/bin as well. The default
installation was to /usr/local, RH had the stuff in /usr. I also
uninstalled the original RH RPM.

Best regards,

== Dave Phillips

	The Book Of Linux Music & Sound (http://www.nostarch.com/lms.htm)
	The Linux Soundapps Site (http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Notjustmoreidlechatter" by Paul Lansky

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Wow. Well, before I got your reply I figured out that it was a libtool
>problem, and I just happened to have the needed RPMs handy. Now
>libltdl.a, libltdl.la, and libltdl.so.0.1.2 are all sitting in /usr/lib,
>and /sbin/ldconfig has been run. Still no joy, even after 'make clean'.
>Do I perhaps have an older or wrong version of libtool ? (The libs are
>dated Sept 2000).

ok, so try "rm config.cache" again, then send me the results (both the
screen output and config.log.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Greetings:

  Paul, I can compile the test prog now, even though the configuration
still fails. Getting closer...

Best regards,

== Dave Phillips

	The Book Of Linux Music & Sound (http://www.nostarch.com/lms.htm)
	The Linux Soundapps Site (http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Low Speed" by Otto Luening

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> first of all, do this:
> 
>       % locate libltdl
> 
> just so we can be sure that neither libltdl.so nor libltdl.la exist on
> your system. assuming that this is the case:
> 
> run, do not walk, to your local RPM server, and pick up a new version
> of libtool. after, before or during installing it, verify that it
> installed libltdl.la and libltdl.so, almost certainly in /usr/lib.

Wow. Well, before I got your reply I figured out that it was a libtool
problem, and I just happened to have the needed RPMs handy. Now
libltdl.a, libltdl.la, and libltdl.so.0.1.2 are all sitting in /usr/lib,
and /sbin/ldconfig has been run. Still no joy, even after 'make clean'.
Do I perhaps have an older or wrong version of libtool ? (The libs are
dated Sept 2000).
 
> You would not believe the pain that libtool has caused in my life,
> mostly around this issue of there being an installed library to go
> with it.

I'm sort of sensing some of that pain myself... ;)

Best regards,

== Dave Phillips

	author, The Book Of Linux Music & Sound
(http://www.nostarch.com/lms.htm)
	maintainer, The Linux Soundapps Site
(http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: Instrumental music by Folquet de Marseila...love
those troubadours...

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Ah, now we're getting somewhere. I was finding it in libs/src/gtkmmext,
>I'm an idiot, sorry... :(  

No you're not. Many people (not even me until several months back)
didn't know that you could use configure to do what used to be called
VPATH-builds (where the objects are created in a different directory
than the source). Just so you know, I do it this way to avoid
contaminating the source directory, which may be shared by multiple
programs (in the case of a symlink to a CVS-based directory).

ok, on with the show:

>So what is libltdl.la and where should I find it ?

therein lies a painful question :) 

libltdl is a library that is part of libtool, a tool for building a
using shared libraries. it contains a cross-platform API for handling
dynamically linked modules. sort of like g_module from glib, but it
works on many other platforms and believe it or not, even works on
systems that don't have dynamically linked modules at all!

well, you obviously have libtool installed. but my guess is that you
have libtool installed from an RPM that is dated before my convincing
RedHat that libtool is *not* architecture neutral. RedHat never to
used to bother supplying and installing the library that comes with
libtool, and so although you'd get the tools to build the software, if
a program decided to link against the library instead of building it
into itself, boom. I was amazed that this had not come up before. Oh
well, the bleeding edge.

first of all, do this:

      % locate libltdl

just so we can be sure that neither libltdl.so nor libltdl.la exist on
your system. assuming that this is the case:

run, do not walk, to your local RPM server, and pick up a new version
of libtool. after, before or during installing it, verify that it
installed libltdl.la and libltdl.so, almost certainly in /usr/lib.

alternatively, if you're version of it is current, then scream at me.

BTW, this would also have given rise to similar problems with ardour,
quasimodo etc. etc. actually, with any program that wanted to link
against libltdl.

You would not believe the pain that libtool has caused in my life,
mostly around this issue of there being an installed library to go
with it.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> i know you said you did this, and i apologize for having a hard time
> believing that the config.log you sent me corresponded to this
> sequence of events. the "sanity" test consists of a test program
> compilation, and when it fails, the autoconf system prints the program
> source out in config.log. Can you take another look (and send it to me ?)
> 
> it will be in libs/build/gtkmmext/config.log, which you might not know.

Ah, now we're getting somewhere. I was finding it in libs/src/gtkmmext,
I'm an idiot, sorry... :(  

Here's what that config.log reports:

configure:3020: checking for pbd-config
configure:3056: checking for libpbd - version >= 1.1.0
configure:3110: checking if libpbd sane
configure:3149: c++ -o conftest -g -O2
-I/home/dlphilp/softwerk-1.99.1/libs/include
-I/usr/local/lib/sigc++/include -I/usr/local/include   conftest.C 
/home/dlphilp/
softwerk-1.99.1/libs/lib/libltdl.la
-L/home/dlphilp/softwerk-1.99.1/libs/lib -L/usr/local/lib -lpbd -lsigc
-lpthread 1>&5
c++: /home/dlphilp/softwerk-1.99.1/libs/lib/libltdl.la: No such file or
directory
configure: failed program was:
#line 3121 "configure"
#include "confdefs.h"
#ifdef __cplusplus
extern "C" void exit(int);
#endif

#include <stdio.h>
#include <pbd/version.h>
#include <pbd/transmitter.h>

Transmitter error(Transmitter::Error);
Transmitter info(Transmitter::Info);
Transmitter warning(Transmitter::Warning);
Transmitter fatal(Transmitter::Fatal);

int main(int argc,char **argv)
  {
   if (pbd_major_version!=1 ||
       pbd_minor_version!=1 ||
       pbd_micro_version!=1)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }


So what is libltdl.la and where should I find it ?

Best regards,

== Dave Phillips

	author, The Book Of Linux Music & Sound
(http://www.nostarch.com/lms.htm)
	maintainer, The Linux Soundapps Site
(http://www.bright.net/~dlphilp/linuxsound/)

Currently listening to: "Lush Life" by Johnny Hartman and John
Coltrane...just too beautiful for words...

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>checking for pbd-config...
>/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
>checking for libpbd - version >= 1.1.0... 1.1.1
>checking if libpbd sane... no
>configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
>appear to be installed
>make: *** [.configured_gtkmmext] Error 1

i know you said you did this, and i apologize for having a hard time
believing that the config.log you sent me corresponded to this
sequence of events. the "sanity" test consists of a test program
compilation, and when it fails, the autoconf system prints the program
source out in config.log. Can you take another look (and send it to me ?)

it will be in libs/build/gtkmmext/config.log, which you might not know.

--p

Re: [softwerk-dev] windowsize

[Paul Barton-D. <pb...@op...>]

>Perfect.  I came up with 1000, 750. 

Sounds good. I'll paste them in.

>This program is so much fun. 

My feelings too. I'm glad I'm not alone. i sometimes wish softwerk had
the notion of a "song", so that i could group patterns together, but
hey, i'm a life-long fan of steve reich and one name for softwerk was
originally "reich-in-a-box".

>Is there a way to change the tempo per step, rather than globally? 

Yep. Though in my experience, it get very complex. But first, do you
really mean "per step" or "per sequence" ? For per-sequence, change
the gate-time for that sequence. (remember to generally keep note-time
below gate time unless you have a MIDI device with unlimited polyphony:)

OK, for the more complex case of per-step. This idea comes from
directly from the doepfer sequencers. Set up a row in "Gate Time" mode
(i.e. instead of "noteOn"). Assign it to control the row you want to
have per-step variation. Adjust the gate times for each step. Here's
the critical part (and i've never tested this with the Gtk-- version
of softwerk) - also set the gate time row to control itself. if you
don't do this, then the controlled row and the controlling row are not
in sync, and the result is effectively random gate times in the
controlled row.

>Also, I am having trouble figuring out just how to move the loop points.
>Clicking on the blue squares with my mouse buttons seems to work, but in
>a totally unpredictable manner. 

Yes, this whole thing sucks and I have not been able to figure out a
good UI design for it. The problem is that only the area that
eventually turns blue is actually sensitive to button presses. I
didn't want a whole bunch of "passive-i-am-NOT-the-endpoint"
markers. If you aim the cursor hotspot (typically a few pixels back
from the tip of the arrow cursor) right in the middle of where the
blue square will end up, it will always work.

you may not know that: right button: sets begin point, left button
sets end point. at one time, i used arrows for this, but i could find
no way to hide them properly in GTK. 

i will graciously accept any UI design suggestions for this.

Also, i went to bed last night thinking "gack! this version still has
the TERRIBLE UI design for adjusting the step values (mouse
motion)". Trust me, this will get better. The original XForms version
had a separate button to do this - click on the value display toggled
the step on and off, and clicks on the adjuster button adjusted the
value. but this added to much screen real estate, so i tried various
approaches to controlling step on/off status and step value from the
same visual element. the current one seemed inspired at one time, but
in real life, as you may have discovered, its horrible.

One general UI design note: in many of my applications, I try to use
the mouse as a pair of buttons that operate in opposite directions
when clicked on the same control element in the GUI. So for example,
the gate time and note time displays are actually "buttons" - right
mouse button decreases the value, left mouse button
increases. Additionally, I set up various modifiers to change the size
of the button-driven increment, so that you can get quickly from one
place to another with the value range. I find this a very powerful UI
control paradigm, but its not common in other software, so I thought I
would try to point it out explicitly here.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:
 
> Dave - yes, there are no clues there. can you send me the actual
> output from configure as it runs ?
> 
> just as one possible hint, after you send me that output, try "rm
> config.cache" before another run of configure and see if that helps.


Hi, Paul: Here's the configure output, with libpbd already compiled and
existing in libs/lib:

[dlphilp@localhost libs]$ make
echo srcs gtkmmext guileconfig midi++ pbd
srcs gtkmmext guileconfig midi++ pbd
mkdir -p build/gtkmmext build/guileconfig build/midi++ build/pbd
if [ ! -f .configured_pbd ] ; then \
        (cd build/pbd; ../../src/pbd/configure --disable-static
--prefix=/home/dlphilp/softwerk-1.99.1/libs); \
fi
touch .configured_pbd
if [ ! -f .configured_gtkmmext ] ; then \
        (cd build/gtkmmext; ../../src/gtkmmext/configure
--disable-static --prefix=/home/dlphilp/softwerk-1.99.1/libs);\
        fi
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking cached system tuple... ok
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for c++... (cached) c++
checking whether the C++ compiler (c++  ) works... yes
checking whether the C++ compiler (c++  ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking for gcc... (cached) gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for ranlib... (cached) ranlib
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
checking for object suffix... o
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions ... yes
checking if gcc static flag -static works... -static
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the linker (/usr/bin/ld) supports shared libraries...
yes
checking command to parse /usr/bin/nm -B output... ok
checking how to hardcode library paths into programs... immediate
checking for /usr/bin/ld option to reload object files... -r
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for objdir... .libs
creating libtool
loading cache ./config.cache
checking for sigc-config... /usr/local/bin/sigc-config
checking for libsigc++ - version >= 0.8.0... 1.0.1
checking if libsigc++ sane... yes
checking for glib-config... /usr/local/bin/glib-config
checking for GLIB - version >= 1.0.0... yes
checking for gtk-config... /usr/local/bin/gtk-config
checking for GTK - version >= 1.0.0... yes
checking for gtkmm-config... /usr/local/bin/gtkmm-config
checking for GTK-- - version >= 1.2.0... yes
checking for pbd-config...
/home/dlphilp/softwerk-1.99.1/libs/bin/pbd-config
checking for libpbd - version >= 1.1.0... 1.1.1
checking if libpbd sane... no
configure: error: *** libgtkmmext requires libpbd v1.1, but it doesn't
appear to be installed
make: *** [.configured_gtkmmext] Error 1


I had already tried removing the cache, but got no joy. Tried it again,
still no joy.

Just for clarity's sake: My system is a beefed-up RH 6.2, with
low-latency patch on kernel 2.4.0-test9 and XFree86 4.01, if that should
matter at all. I upgraded a number of things for the 2.4 instalation,
could there be a mismatch of utils somewhere ??

Best regards,

== Dave Phillips

	http://www.bright.net/~dlphilp/index.html
	http://www.bright.net/~dlphilp/linuxsound/

Currently listening to: "Mutations" by Jean-Claude Risset...ya gotta
love those Shepard tones...!

[softwerk-dev] windowsize

[Reynald H. <be...@op...>]

Perfect.  I came up with 1000, 750. 
This program is so much fun. 
Is there a way to change the tempo per step, rather than globally? 
Also, I am having trouble figuring out just how to move the loop points.
Clicking on the blue squares with my mouse buttons seems to work, but in
a totally unpredictable manner. 

Thanks,

Reynald

> go into ui.cc. search for this line:
> 
>         main_window.set_usize (1200, 800);
> 
> and comment it out. then use your WM to adjust the window size. then
> send me a size that seems to work for you, and i'll use that as the
> minimum size, OK ?

Online music composition (was Re: [softwerk-dev] Troubles with Softwerk)

[Josh G. <jg...@us...>]

Jaroslav Kysela wrote:

> On Sun, 26 Nov 2000, Paul Barton-Davis wrote:
>
> > >I'm not sure, if you know about the virtual midi devices which can be used
> > >like the ordinary rawmidi devices, but the midi stream is parsed to the
> > >sequencer events and versa vice. The virtual midi device behaves like a
> > >sequencer port, so you may connect it to other ports (like the wavetable
> > >sythesizers or midi uart drivers). So far, no changes are needed on your
> > >side. You must only use the ALSA rawmidi devices instead of OSS ones.
> >
> > Ah, I had a feeling that something like this existed. Very nice. Josh,
> > this is what you should use to use ALSA with your AWE. Set up a
> > virmidi device (ask on alsa-devel how to do this if you don't know),
> > then use aconnect to connect it to the AWE input sequencer port. then
> > use the relevant /dev/snd/midi... specification in the SoftWerk rc file.
>
> The EMU8000 and EMU10K1 synth devices creates virtual rawmidi devices
> (second and third rawmidi device) by default.
>

Awesome.. I'm always amazed at the flexibility of ALSA.
Anyone interested in starting an online music composition system?? The thought
occured to me recently that ALSA is very close to supporting such a system.
Imagine multiple musicians creating a "channel" on a server to connect arbitrary
sequencer clients to. Sample patches (sound fonts etc.) could be uploaded through
a web interface and cataloged in a database on the server. Each "channel" would
have a list of loaded patches. The MIDI stream would then be available for others
to connect to for listening (they would also need the correct sample patches). Or
streamed via MP3, Ogg Vorbis, etc. on the server with software based wavetable
emulators or re-sampled with a hardware wavetable card.
I'm sure latency issues would make this even more amusing when trying to jam with
multiple people :)
Anyone working on something like this?? Anyone want to?
    Josh Green

Re: [softwerk-dev] ERROR: Unknown # object: #\newline

[Paul Barton-D. <pb...@op...>]

>I notice that the softwerk window is un-resizable horizontally.  This is
>a bit sad for me, as I only have 17" monitor, and it doesn't quite all
>fit into the screen.

not intentional. i do *love* my 21" monitor, though :)

go into ui.cc. search for this line:

	main_window.set_usize (1200, 800);    

and comment it out. then use your WM to adjust the window size. then
send me a size that seems to work for you, and i'll use that as the
minimum size, OK ?

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

Dave - yes, there are no clues there. can you send me the actual
output from configure as it runs ? 

just as one possible hint, after you send me that output, try "rm
config.cache" before another run of configure and see if that helps.

--p

Re: [alsa-devel] Re: [softwerk-dev] Troubles with Softwerk

[Jaroslav K. <pe...@su...>]

On Sun, 26 Nov 2000, Paul Barton-Davis wrote:

> >I'm not sure, if you know about the virtual midi devices which can be used
> >like the ordinary rawmidi devices, but the midi stream is parsed to the
> >sequencer events and versa vice. The virtual midi device behaves like a
> >sequencer port, so you may connect it to other ports (like the wavetable
> >sythesizers or midi uart drivers). So far, no changes are needed on your
> >side. You must only use the ALSA rawmidi devices instead of OSS ones.
> 
> Ah, I had a feeling that something like this existed. Very nice. Josh,
> this is what you should use to use ALSA with your AWE. Set up a
> virmidi device (ask on alsa-devel how to do this if you don't know),
> then use aconnect to connect it to the AWE input sequencer port. then
> use the relevant /dev/snd/midi... specification in the SoftWerk rc file.

The EMU8000 and EMU10K1 synth devices creates virtual rawmidi devices
(second and third rawmidi device) by default.

> >Anyway, we can copy our MIDI parser code from the kernel to the user space
> >and create nice MIDI stream <-> ALSA sequencer converter. It's nothing
> >complicated for us and it seems that it helps a lot to you. It'll allow
> >use more features of the ALSA sequencer.
> 
> I started out writing an explanation of why this wouldn't help
> libmidi++, but as I did so, I realized that it definitely would.
> I could derive MIDI::AlsaSequencerPort from MIDI::Port that used the
> MIDI<->Sequencer code. Can somebody plan to do this ? 

Done. Please, look to 'Sequencer event <-> MIDI byte stream coder' section
in asoundlib.h. These routines are same as in the kernel code, so you may
look for examples there.

> libmidi++ already has complete MIDI parsers for both directions on a
> MIDI::Port, and its a little silly to be parsing the data multiple
> times. But this still happens with the virmidi method, just in the
> kernel.

In this case, it would be the best to create an application event <->
ALSA sequencer event conversion code, but I know, it requires much more
time.

						Jaroslav

-----
Jaroslav Kysela <pe...@su...>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Paul Barton-Davis wrote:

> At the end of the config.log file generated by configure is a short
> C++ program and the compile command (which spans several lines) (and a
> report that it failed) Copy the program to another file, then use the
> compile command on it, try to run it (if compilation works) and let me
> know the result. There is obviously some possibility for a systematic
> snafu here.

Paul, I've attached the entire config.log (it's not very long). I'm
missing what you're directing me towards, sorry I'm especially dense
today...

Best regards,

== Dave Phillips

	http://www.bright.net/~dlphilp/index.html
	http://www.bright.net/~dlphilp/linuxsound/

[softwerk-dev] ERROR: Unknown # object: #\newline

[Reynald H. <be...@op...>]

foolish me.  I was using the softwerk.rc instead of the softwerkrc.scm. 
Perhaps the name of the real configuration file should be mentioned in
the README, although it's pretty obvious that the first one is not a
scheme file. They both say "sample configuration file" though.

The main thing is, it works now!

I notice that the softwerk window is un-resizable horizontally.  This is
a bit sad for me, as I only have 17" monitor, and it doesn't quite all
fit into the screen.

Thanks,
Reynald



>I am using the sample config file, (modified for my soundcard) and I
>get:
>SoftWerk: [INFO]: guileconfig : found softwerk rc file in:
>         .softwerk.rc
>ERROR: In procedure read:
>ERROR: Unknown # object: #\newline
>
>Not being a guile expert, I have no idea what this means. Any
>suggestions?

>very good question. i don't know. can you send me (the list) your
>softwerk rc file so i can try it here ? also, which version of guile
>are you using ?

Re: [alsa-devel] Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>I'm not sure, if you know about the virtual midi devices which can be used
>like the ordinary rawmidi devices, but the midi stream is parsed to the
>sequencer events and versa vice. The virtual midi device behaves like a
>sequencer port, so you may connect it to other ports (like the wavetable
>sythesizers or midi uart drivers). So far, no changes are needed on your
>side. You must only use the ALSA rawmidi devices instead of OSS ones.

Ah, I had a feeling that something like this existed. Very nice. Josh,
this is what you should use to use ALSA with your AWE. Set up a
virmidi device (ask on alsa-devel how to do this if you don't know),
then use aconnect to connect it to the AWE input sequencer port. then
use the relevant /dev/snd/midi... specification in the SoftWerk rc file.

>Anyway, we can copy our MIDI parser code from the kernel to the user space
>and create nice MIDI stream <-> ALSA sequencer converter. It's nothing
>complicated for us and it seems that it helps a lot to you. It'll allow
>use more features of the ALSA sequencer.

I started out writing an explanation of why this wouldn't help
libmidi++, but as I did so, I realized that it definitely would.
I could derive MIDI::AlsaSequencerPort from MIDI::Port that used the
MIDI<->Sequencer code. Can somebody plan to do this ? 

libmidi++ already has complete MIDI parsers for both directions on a
MIDI::Port, and its a little silly to be parsing the data multiple
times. But this still happens with the virmidi method, just in the
kernel.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

>Alas, I have yet to get beyond this point. The sanity check for libpbd
>fails every time, no matter what I've tried. And yes, I've used *only*
>the directions given in the README, so I'm left wondering what in the
>world is wrong with my system. There are no legacy libs lying around
>from previous attempts at QM or Ardour, but for my life I can't figure
>out where things are going wrong. I'm using the tarball: perhaps I
>should try the CVS ? Josh, any suggestions ??

At the end of the config.log file generated by configure is a short
C++ program and the compile command (which spans several lines) (and a
report that it failed) Copy the program to another file, then use the
compile command on it, try to run it (if compilation works) and let me
know the result. There is obviously some possibility for a systematic
snafu here.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Dave P. <dl...@br...>]

Josh Green wrote:

> [snip]
> The configure script for the other libs still reported that my libpbd
> install wasn't sane. Though I noticed it listed the version (1.1.1)
> which satisfied the check (1.1.0). This problem is not occuring now,
> though I was messing with these macros. Not sure why it works now.

Alas, I have yet to get beyond this point. The sanity check for libpbd
fails every time, no matter what I've tried. And yes, I've used *only*
the directions given in the README, so I'm left wondering what in the
world is wrong with my system. There are no legacy libs lying around
from previous attempts at QM or Ardour, but for my life I can't figure
out where things are going wrong. I'm using the tarball: perhaps I
should try the CVS ? Josh, any suggestions ??

Best regards,

== Dave Phillips

	http://www.bright.net/~dlphilp/index.html
	http://www.bright.net/~dlphilp/linuxsound/

Re: [alsa-devel] Re: [softwerk-dev] Troubles with Softwerk

[Jaroslav K. <pe...@su...>]

On Sun, 26 Nov 2000, Paul Barton-Davis wrote:

> This is one of the main reasons for my dislike of the overall design
> of the sequencer: it doesn't encapsulate MIDI but requires recoding
> the messages as sequencer-API-specific events. This makes life hard
> for programs that want to use a common design that allows the
> sequencer and raw MIDI devices to be used as equivalent destinations
> for data. At least, it seems to.

I'm not sure, if you know about the virtual midi devices which can be used
like the ordinary rawmidi devices, but the midi stream is parsed to the
sequencer events and versa vice. The virtual midi device behaves like a
sequencer port, so you may connect it to other ports (like the wavetable
sythesizers or midi uart drivers). So far, no changes are needed on your
side. You must only use the ALSA rawmidi devices instead of OSS ones.

Anyway, we can copy our MIDI parser code from the kernel to the user space
and create nice MIDI stream <-> ALSA sequencer converter. It's nothing
complicated for us and it seems that it helps a lot to you. It'll allow
use more features of the ALSA sequencer.

						Jaroslav

-----
Jaroslav Kysela <pe...@su...>
SuSE Linux    http://www.suse.com
ALSA project  http://www.alsa-project.org

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

[ ALSA folks: Josh Green (Smurf sound font editor) was mildly
  contemplating adding the ALSA sequencer as an output destination
  for my MIDI pattern sequencer SoftWerk. I started thinking about
  why it was going to be hard, and it seemed of some relevance to
  this list. Some people may also have ideas about solutions.

  I've set reply-to to point to alsa-devel, because softwerk-dev 
  is member-only.
]

>don't usually offer to help develop a program, so I guess it has to
>start somewhere. Perhaps I'll look into adding sequencer support to
>Softwerk, just n eed to read up on the ++ part of C++ and check out
>the MIDI related code. 

That would be great. You won't really be adding sequencer support to
SoftWerk however, and its probably a bit more complex than it should
be. You'd really be adding the sequencer as a Port type to
libmidi++. And here's why its hard.

Everything that uses libmidi++ would be using the methods defined in
<midi++/channel.h> to deliver MIDI messages of defined types. And they
do. The problem is that by the time these messages get handed to the
underlying MIDI::Port object, they have been rendered as simple byte
streams. The ALSA sequencer (or any other similar system) would exist
as a MIDI::Port type, and so you're going to be handed type-free byte
streams, not typed MIDI messages. I think that the sequencer can be
used to handle this, but certainly not in the intended way unless you
re-parse the data streams so that you deliver typed messages. This
would be an abomination, I think.

This is one of the main reasons for my dislike of the overall design
of the sequencer: it doesn't encapsulate MIDI but requires recoding
the messages as sequencer-API-specific events. This makes life hard
for programs that want to use a common design that allows the
sequencer and raw MIDI devices to be used as equivalent destinations
for data. At least, it seems to.

Instead, it requires the sequencer destination to exist as a more
complex/capable object than a MIDI::Port or alternatively that
MIDI::Port must accept typed messages. The first one messes up a clean
object heirarchy (in essence, the sequencer destination exists in
between the abstraction of a MIDI channel and a MIDI port), and the
second forces a model of what a Port is that doesn't match the reality
of actual devices.

So, as I said, this could be trickier than you (or I) would like :) If
you can see a good re-design of libmidi++ that would solve this
cleanly, I'd be happy to consider doing that. ALSA sequencer support
*is* important.

--p

Re: [softwerk-dev] Troubles with Softwerk

[Paul Barton-D. <pb...@op...>]

><DREAMING BUT NOT FAR OFF>

Of course, you could just sign up for RocketNetwork. But they don't
give you the source code :)

>I noticed you're the author of at least three programs (ardour,
>softwerk, and quasimodo). I'm the author of one program of
>significance (Smurf Sound Font Editor) and I find it hard enough to
>keep up on it as much as I would like. Ho w much success have you had
>in getting other programmers to help out? 

Very little. Stephane Conversey was one person who made *major*
contributions to Quasimodo. Bill Gribble added libguileconfig to
Quasimodo which was then reused by the others. A couple of people have
contributed small-N-line patches and ideas. And thats about
it. Luckily, I am able to work on these programs more or less as a
full time job (sometimes way more than fulltime!), and I'm glad to be
one of those programmers whose productivity tends to be way up there
(at least when i get enough sleep to actually think about what i'm
doing). But yes, I know what you mean, and it would be much nicer if
there really was a group of people working on any one of "my"
projects. There are lots of rough edges in them that come from me
being the primary user and developer, and thus not exercising certain
code paths that others would do quite naturally. Other people would
both tend to find them, and then hopefully fix them.

[ another reply coming up separately because i want to Cc: it to alsa-devel]

>Keep up the good work!

I'll do what I can :)

--p

Re: [softwerk-dev] nit picks

[Paul Barton-D. <pb...@op...>]

>First of all, I can't seem to get to the archives of this list.  All i
>get is a Geocrawler page that says error - list not found.

sourceforge sets this up automatically, and i honestly know nothing
about it. however, note that until about 2 days ago, there had never
been a message to the list, so this may explain it.

>1)there is no libs dir in the CVS version I downloaded

oops. my mistake. i was catching up with the ardour-way-of-things and
omitted this part. i'll fix it in the next couple of days.

>2) autogen.sh looks for the directory libs/share and exits if it doesn't
>find it. 
>3)ACLOCAL_FLAGS adds the def'n in libs/share/aclocal, which weren't
>there. 

double oops. thanks for being the first person to try this code path
out :) i'll fix this stuff too. i am currently doing all my builds
using the application-local approach. i plan to try to switch back
sometime soon, now that softwerk is "live" again (as is my ICubeX editor).

>Now my real problem:
>I am using the sample config file, (modified for my soundcard) and I
>get:
>SoftWerk: [INFO]: guileconfig : found softwerk rc file in:
>         .softwerk.rc
>ERROR: In procedure read:
>ERROR: Unknown # object: #\newline
>
>Not being a guile expert, I have no idea what this means. Any
>suggestions?

very good question. i don't know. can you send me (the list) your
softwerk rc file so i can try it here ? also, which version of guile
are you using ?

--p

Re: [softwerk-dev] Troubles with Softwerk

[Josh G. <jg...@us...>]

Paul Barton-Davis wrote:

> >Right. Guess I should follow the README. I originally was using the libraries
> >from Quasimodo as thats where the links point to off of the requirements web
> >page. If I had followed the README I'm sure I wouldn't have had such a hard
> >time :)
>
> Sorry for the confusion. The old "separate libraries installed by
> themselves" seemed to be a huge hassle for a lot of people. I still
> don't have all the kinks worked out, but hopefully the new system is a
> little easier.
>

No problem. I know what its like to handle the burden of keeping a program easy
for the common user.

>
> >> You can't. If you want to write the code, feel free. I have little or
> >> no use for the sequencer, and I've never written any code to deal with it.
> >>
> >
> >Hmm.. Okay.
>
> And sorry if I sound somewhat arrogant about this.

Its hard to guess the context of a phrase in an email :) It did come off a little
that way..

<DREAMING BUT NOT FAR OFF>
I'm having this flash on what it would be like to have an online music
composition system. ALSA pretty much already has this capability it seems
(aseqnet). Basically it would be a server that would receive ALSA sequencer
streams from other users and mix them into listenable "channels" that others can
listen to. These channels could either be listened to by an ALSA user client or
perhaps render it with a software MIDI wavetable program and stream via MP3 or
some other online audio format. When native ALSA patch loading becomes available,
a patch loader could be used like any other ALSA client, allowing users to upload
their own patches.
Imagine multiple people composing music from across the world, one person playing
a track, another modifying an effect on the same channel, another playing another
part on a different channel.. All of them trying to cope with the massive latency
:( Ohh well, someday..
</DREAMING BUT NOT FAR OFF>

I noticed you're the author of at least three programs (ardour, softwerk, and
quasimodo). I'm the author of one program of significance (Smurf Sound Font
Editor) and I find it hard enough to keep up on it as much as I would like. How
much success have you had in getting other programmers to help out? I would like
to work on Smurf with others but I haven't gotten that many offers. I myself
don't usually offer to help develop a program, so I guess it has to start
somewhere. Perhaps I'll look into adding sequencer support to Softwerk, just need
to read up on the ++ part of C++ and check out the MIDI related code. Keep up the
good work!
    Josh Green