softwerk-dev

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

>  However, when I configured SoftWerk it reported that gtkmmext,
>guileconfig, and libmidi were all un-sane, so I copied those libs into
>/usr/lib. Configure reported no errors after that.

ah. got it, maybe. sounds to me as though you don't have
LD_LIBRARY_PATH set in your normal environment. I try to set it in configure
so that we don't run into this problem BUT the way I do that assumes
that its already an environment variable (i.e. i do not specifically
set it as an environment variable). as a result, if you don't have it
already set that way, it ends up as a regular shell variable, and is
not exported to the subprocesses executed within configure ... does
this seem likely/possible ?

>  SoftWerk compiled perfectly then. However, trying to run it reported
>the error that it couldn't find the file
>/home/dlphilp/softwerk-1.99.2/libs/lib/guileconfig/scm/softwerk-variables.scm.

From README:

----------------------------------------------------------------------
An annoying last step, which will eventually be fixed is:

         make install-guileDATA
----------------------------------------------------------------------

>  Now I'm *very* excited about building Ardour ! (pbd shudders... :)

shudder-shake-shudder-shake - hey, lets loop it!

--p

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

>I think you're right. 'echo $LD_LIBRARY_PATH' yields nada, if that tells
>us anything useful.

tremendously useful. thats precisely the problem. the libraries are
installed "locally", so ldconfig doesn't help ld to find them. the
plan is for it to use LD_LIBRARY_PATH, which was set by configure, but
not exported. presto - it doesn't work.

>Yes, but I thought it applied only to a CVS build. My bad.

its there for both.
 
>I still haven't tested it, but it's on today's menu. I must say it looks
>*great*, quite an advance from the old XForms version (which I remember
>fondly).

heh. wait till you try to adjust the step values. i'll probably try
and fix this during the day today.

>Btw, can I safely assume that the libs from this build are usable if I
>decide to take another swipe at Ardour ? 

absolutely. but it won't be easy using them. you've installed the
libs themselves in /usr/lib, but not the rest of the stuff (the m4
files, in particular). 

so, here's what to do. below is a patch for the configure
script. apply this patch. then remove the libraries you copied to
/usr/lib. then try a rebuild. assuming this works (it should), you
will then have a set of libraries ready to use. you can do two things:

     1) link the libs dir of ardour to the libs dir of softwerk
     2) delete the ardour libs tree; copy the libs tree of softwerk to
            the ardour source tree

stay in touch,
--p

ps. this patch has been applied to CVS.

--- configure.in        2000/11/28 04:46:58     1.9
+++ configure.in        2000/11/28 16:04:40
@@ -55,6 +55,12 @@
 PATH=libs/bin:$PATH
 LD_LIBRARY_PATH=libs/lib:$LD_LIBRARY_PATH
 
+dnl some people don't have LD_LIBRARY_PATH set as an environment
+dnl variable, and so we must force this to be exported in order
+dnl that ld(1) can use it.
+
+export LD_LIBRARY_PATH
+
 LIBS="-Llibs/lib $LIBS"
 CXXFLAGS="-Ilibs/include $CXXFLAGS"
 

    

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

Paul Barton-Davis wrote:

> heh. wait till you try to adjust the step values. i'll probably try
> and fix this during the day today.

Well, I tried it out, and...it works !! Wow, what fun !

I did crash it once, but I wasn't paying attention to what I was doing
(accidental mouse button-press), perhaps it was the step value.
Otherwise it's "werking" well <groan>...
 
> so, here's what to do. below is a patch for the configure
> script. apply this patch. then remove the libraries you copied to
> /usr/lib. then try a rebuild. assuming this works (it should), you
> will then have a set of libraries ready to use. you can do two things:
> 
>      1) link the libs dir of ardour to the libs dir of softwerk
>      2) delete the ardour libs tree; copy the libs tree of softwerk to
>             the ardour source tree

Okay, will do. Unfortunately I go back to teaching today, so I may not
get to any of it until this evening. I will get to it though, I'm
excited about getting Ardour working here too.

Thanks for your patient assistance, Paul, it's greatly appreciated.

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:

[softwerk-dev] softwerk input

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

> heh. wait till you try to adjust the step values. i'll probably try
> and fix this during the day today.
> 

BTW it would be cool to not have to mentally convert notes into midi
values. Is it possible to input note values directly from a external
controller? I tried "Recorded MIDI", but it seems to take everything,
not just the note value. And it doesn't show the midi number so it can
be edited later.  I would like to do the same thing for absolute pitch,
say. 

thanks, 
Reynald

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

>Isn't ldconfig supposed to take care of this? I mean like add the
>path /usr/local/lib or wherever the libs are installed into the
>/etc/ld.so.conf fi le (thats where it is on my system), then re-run
>ldconfig each time new libraries are installed. I guess setting
>LD_LIBRARY_PATH might make sense from within "configure", but it
>can't control that variable after it exits. Perhaps I'm
>mis-understanding the problem.

ldconfig controls system-wide libraries. because so many people didn't
like or had problems installing the libraries system wide, my programs
now come in tarballs that do a local install of the libraries. it
would be absurd to go around adding appl-specific directories to
ldconfig (i think so, anyway).

no, LD_LIBRARY_PATH isn't set after configure has finished, but when
using a locally installed set of libraries, we use the -rpath option
of ld(1) to encode the library location into the executable.

if you *do* do a system wide install of the libraries, then sure,
ldconfig is the way to handle it. but think of it this way: suppose
you decide to try out ardour as well. are you comfortable overwriting
the libs that you installed for softwerk ? some people will say
yes. some will say no. the current scheme is an attempt to keep them
both happy.

--p

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

Paul Barton-Davis wrote:

>
> ldconfig controls system-wide libraries. because so many people didn't
> like or had problems installing the libraries system wide, my programs
> now come in tarballs that do a local install of the libraries. it
> would be absurd to go around adding appl-specific directories to
> ldconfig (i think so, anyway).
>

Okay, that makes more sense. When I get a lib that I don't want to
install system wide I usually install it in like ~/lib and add that to my
LD_LIBRARY_PATH. I can see that its a mess though, because configure
would still need to know the location of it to test if its there. This is
usually done via a configure script switch like --with-pbd=/home/josh/lib
or something though. How about statically linking the libs?
    Josh

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

>Okay, that makes more sense. When I get a lib that I don't want to
>install system wide I usually install it in like ~/lib and add that to my
>LD_LIBRARY_PATH. I can see that its a mess though, because configure
>would still need to know the location of it to test if its there. 

No, it doesn't. If a library exists in such a way that ld(1) can find
it, then configure will find it too (because it uses ld(1) to do so).

This doesn't apply to the non-library components of a package, and
this is how the "*-config --[libs|cflags]" convention has come into
being.

In the case of my tarball releases, what you build is intended to be
entirely local to the application and not for reuse by anything
else. if you don't like that, then use the CVS repositories, and do a
global install of the libraries. it will work either way.

--p

[softwerk-dev] note input

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

What is the procedure for typing in values rather than manipulating the
default 60 with the mouse? I type a number into the box, but nothing
seems to change except the number displayed. The note played is still
60. 

thanks,

reynald

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

Paul Barton-Davis wrote:

> ...sounds to me as though you don't have
> LD_LIBRARY_PATH set in your normal environment. I try to set it in configure
> so that we don't run into this problem BUT the way I do that assumes
> that its already an environment variable (i.e. i do not specifically
> set it as an environment variable). as a result, if you don't have it
> already set that way, it ends up as a regular shell variable, and is
> not exported to the subprocesses executed within configure ... does
> this seem likely/possible ?

I think you're right. 'echo $LD_LIBRARY_PATH' yields nada, if that tells
us anything useful.
 
> >From README:
> 
> ----------------------------------------------------------------------
> An annoying last step, which will eventually be fixed is:
> 
>          make install-guileDATA
> ----------------------------------------------------------------------

Yes, but I thought it applied only to a CVS build. My bad.
 
I still haven't tested it, but it's on today's menu. I must say it looks
*great*, quite an advance from the old XForms version (which I remember
fondly).

Btw, can I safely assume that the libs from this build are usable if I
decide to take another swipe at Ardour ? 

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: the sound of silence...

Re: [softwerk-dev] new release, plus "manual": SUCCESS!

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

Paul Barton-Davis wrote:

> >  However, when I configured SoftWerk it reported that gtkmmext,
> >guileconfig, and libmidi were all un-sane, so I copied those libs into
> >/usr/lib. Configure reported no errors after that.
>
> ah. got it, maybe. sounds to me as though you don't have
> LD_LIBRARY_PATH set in your normal environment. I try to set it in configure
> so that we don't run into this problem BUT the way I do that assumes
> that its already an environment variable (i.e. i do not specifically
> set it as an environment variable). as a result, if you don't have it
> already set that way, it ends up as a regular shell variable, and is
> not exported to the subprocesses executed within configure ... does
> this seem likely/possible ?
>

Isn't ldconfig supposed to take care of this? I mean like add the path
/usr/local/lib or wherever the libs are installed into the  /etc/ld.so.conf file
(thats where it is on my system), then re-run ldconfig each time new libraries are
installed. I guess setting LD_LIBRARY_PATH might make sense from within
"configure", but it can't control that variable after it exits. Perhaps I'm
mis-understanding the problem.
    Josh