softwerk-dev

Re: [softwerk-dev] softwerk input

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

all I meant was that if I position the mouse over a value, then press a
key on my midi keyboard, the number will show up in the box, as if I had
typed it in. "absolute pitch" refers to the mode I'm usually in. 

How hard would it be to do this? I'd like to try this, if you think it
would be a decent thing for a beginner to do.  I know c++, but have no 
experience with any of the libraries of pbd, nor do I have much midi
experience. This seems like a good place to start!

reynald



>          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.
> 
> Point taken. I'll add them to the todo list.
> 
> >I would like to do the same thing for absolute pitch, say.
> 
> I don't quite understand what you mean here.

Re: [softwerk-dev] a few changes

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

>>         left: decrement by 1
>>         right: increment by 1
>>         shift-left or shift-right: dec. or inc. by 16

further clarification: the button is an automated "spinner" too: if
you just press and hold, it will keep changing in that
direction. right now, the rate of change is constant, but thats a 
less-than-one-line change to alter if people think its a good idea.

>Cool. I was just going to send an email of me complaining about how hard
>it is to set a step value. I guess now I can spare you that, and just
>checkout the CVS and then perhaps complain :)

you mean like this one ?

>I find the current way of changing note values to be a real pain. Perhaps
>I'm not doing things right, its really hard to control the value with the
>mouse though. I usually end up typing the values. Perhaps I should finally

:)

you continued:

>I wan't a nice sequencer program but there are some things that are
>bugging me about Softwerk. Its a great program, it just could be better :)

keep in mind that for the foreseeable future, this is always going to
be a loop/pattern program, not a general purpose sequencer. my love
affair is with the old sequencer hero days (ARP sequencers, Moog
stuff, etc; and these days, the Doepfer stuff). Other people will have
to write the piano-roll things (and they are) because SoftWerk is an
entirely different concept of what a sequencer is.

and yes, it could be better. thats why you're here :)

--p

Re: [softwerk-dev] a few changes

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

Josh Green wrote:

>
> Cool. I was just going to send an email of me complaining about how hard
> it is to set a step value. I guess now I can spare you that, and just
> checkout the CVS and then perhaps complain :)
>     Josh

Apparently I did already send the complaint message. Thought I still had
that compose window floating around. Guess not.
    Josh

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] a few changes

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

Paul Barton-Davis wrote:

> if you want to be able to see the end-point "click zones", edit
> softwerk_ui.rc, and find "TerminalMarker". look above it, and make the
> file look like this:
>
>      style "terminal_marker"
>      {
>         bg[ACTIVE] = { 0, 0.54, 0.97 }
>         bg[NORMAL] = { 0.42, 0.52, 0.45 }
>      }
>
> i've just committed changes to CVS that alter the step value adjuster
> button (no more stupid motion):
>
>         left: decrement by 1
>         right: increment by 1
>         shift-left or shift-right: dec. or inc. by 16
>
>         middle: go to middle of step range
>         shift-middle: toggle that step's enable status
>         ctl-middle: learn MIDI control (the step will automatically
>                      detect the next incoming CC message, and future
>                      messages of that type will control the row value.
>                      note on/off will work too, i think)
>

Cool. I was just going to send an email of me complaining about how hard
it is to set a step value. I guess now I can spare you that, and just
checkout the CVS and then perhaps complain :)
    Josh

Re: [softwerk-dev] softwerk input

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

Paul Barton-Davis wrote:

>   pre-ps: shimmer.mp3 is actually 4.7MB, not 610kB, so stream it :)
>
> >BTW it would be cool to not have to mentally convert notes into midi
> >values.
>
> Heh. So says the musician. I tend to feel quite the opposite! I tend
> to work math and music together and prefer the numbers to the names.
>
> Of course, the right thing is a filter to change the way they are
> displayed. Consider it on the todo list.
>

How about color coded?? I don't really care what the note # or name is
myself. I more care what the relative difference is between notes. I
wonder what it would look like if you spread a RGB spectrum over 128
notes. Could you tell the difference between two values? Hmm. Perhaps
display the note value as a tooltip to each entry. Just a thought. It
would be cool to select the note format though.
I find the current way of changing note values to be a real pain. Perhaps
I'm not doing things right, its really hard to control the value with the
mouse though. I usually end up typing the values. Perhaps I should finally
try to get into some C++ and look at your widgets to get a better
understand of how they work :) I've done a bit of GTK widget programming
with Smurf and might be able to help.
I wan't a nice sequencer program but there are some things that are
bugging me about Softwerk. Its a great program, it just could be better :)
I could say this about my program as well. It never ends..

Lates..
    Josh

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

[softwerk-dev] a few changes

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

if you want to be able to see the end-point "click zones", edit
softwerk_ui.rc, and find "TerminalMarker". look above it, and make the
file look like this:

     style "terminal_marker"
     {
	bg[ACTIVE] = { 0, 0.54, 0.97 }
	bg[NORMAL] = { 0.42, 0.52, 0.45 }
     }


i've just committed changes to CVS that alter the step value adjuster
button (no more stupid motion):

	left: decrement by 1
	right: increment by 1
	shift-left or shift-right: dec. or inc. by 16

	middle: go to middle of step range
	shift-middle: toggle that step's enable status
	ctl-middle: learn MIDI control (the step will automatically
	             detect the next incoming CC message, and future
		     messages of that type will control the row value.
		     note on/off will work too, i think)

note that even in version 1.99.2, ctrl-middle on a "raw midi row"
(including recorded midi) will pop up a MIDI byte editor (since MIDI
control is not possible for this kind of row).

finally, i've removed the unnecessary use of libtool to actually link
the program.

more later.

Re: [softwerk-dev] softwerk input

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

  pre-ps: shimmer.mp3 is actually 4.7MB, not 610kB, so stream it :)

>BTW it would be cool to not have to mentally convert notes into midi
>values. 

Heh. So says the musician. I tend to feel quite the opposite! I tend
to work math and music together and prefer the numbers to the names.

Of course, the right thing is a filter to change the way they are
displayed. Consider it on the todo list.

	 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.  

Point taken. I'll add them to the todo list.

>I would like to do the same thing for absolute pitch, say. 

I don't quite understand what you mean here.

--p

[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

[softwerk-dev] mp3 ...

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

ok, for some reason, even though i've never released any of my musical
experiments, the fact that somebody else made an mp3 available of a
softwerk-driven piece before me got under my skin (not in a bad way):

so, without further ado, 

    http://www.op.net/~pbd/shimmer.mp3 (128kb/sec, 600kB)

i would recommend the use of xmms and the openGL spectrum analyzer
while listening to this experiment in minimalism. its not finished,
but its nice little demonstration. softwerk was driving my kawai
K5000s synth, which was doing some heavily flanged echo fx as well. i
don't know what the download rate from op.net is like - probably best
to download then listen.

--p

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:

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:

> ...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!

[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!

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

Greetings:

  Okay, I ran ldd on the conftest binary and it reported that it
couldn't find libpbd. So I copied it into /usr/lib, and huzzah, gtkmmext
configuration reported a sane libpbd ! All libs compiled fine after
that.

  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.

  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.
I copied it from the SoftWerk top directory into the requested
directory, became root (I enabled the rtc), and fired up SoftWerk. Ecce
magnum opus !!!

  It looks beautiful, Paul. I'm going to spend some time playing with it
today, will report back to the list after spending some time with it...

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

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: Charles Mingus, "Goodbye Porkpie Hat"

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

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

Greetings:

  No joy. Exactly the same problem at exactly the same place. libtool is
evil... :(

  Josh, how did you get SoftWerk installed ? I can't believe this
problem is due to something Paul did or didn't do, it must be something
farked up on my system. Anyone have any hints about what I ought to be
looking for outside of the SoftWerk directories ?

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: Brian Eno, "Unfamiliar Wind (Leeks Hills)"

Re: [softwerk-dev] UI

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

> 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.

Well, the UI is already 1000 times easier with the addition of that manual
and your explanations. As an aside, I think that most of the
alsa-is-too-complicated naysayers would go away if there were some
documentation & simple sample code for that too. 

> 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.

The first thing I would do (if I knew any gtk) as a band-aid
would be to change the colour or otherwise demarcate the start/end points
from eachother.  I find there is some weird behaviour when then the start
point is ahead of the endpoint. Knowing which was which would help.  

If you are going to keep this behaviour, maybe you could at at least
shade the areas where it is possible to click. I guess I just have to get
the hang of it but I find myself having to repeat-click a lot to
finally change their locations.  

I don't know gtk very well, so maybe this is hard, but maybe clicking and
dragging the enpoints to their desired location would be more intuitive.  

these are just comments of a newbie user, so take them with a grain of
salt . .

anyways, back to looping!

reynald

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

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

Paul Barton-Davis wrote:

> I put a new tarball release (1.99.2) on sourceforge with fixes for
> that egregious bug in all the library version-sanity checking code,
> plus a smaller minimum window size.
>
> I also put in place a version of the docs from an older version of
> softwerk. they are not totally current, but they will help you to
> understand what the program can do. see the "manual" link from the
> home page.
>
> schlaf gut,
>

Killer, I just got the first peep out of Softwerk. And I'm happy to say
its also the first time I've had the Smurf Sound Font Editor and a
sequencer program working at the same time! I just recently added
ALSA sequencer support. Its rad I can set up a sequence in Softwerk and
then just change my patches on the fly while its playing! Cool. I
recorded my first pattern that I created and encoded it into MP3. Check
it out if you want:
http://resonance.org/~josh/softwerk_and_smurf.mp3

Its a little distorted and patch changes aren't the smoothest (patch
data gets uploaded each time I change it with Smurf, will change in
future). The patches are a sound font created by Smurf from various
generated samples (Smurf's sample generator) and a recording of a kazoo
(I will be releasing a sound font in the future, rather un-professional
though :).

I hope to compose music more now, program less :) Must read Softwerk
manual.. Lates..
    Josh

P.S. I got the virtual MIDI stuff working with my AWE 32 as was
discussed on ALSA devel (I used /dev/snd/midiC0D2 and alsa/raw). I was
getting a mysterious seg fault with softwerk on startup though. For some
reason the "mode" variable in the softwerkrc.scm won't accept "output",
so I set it to "duplex".

Re: [softwerk-dev] Troubles with Softwerk

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

Paul Barton-Davis wrote:

> >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.
>

I actually had the same experience.. When I took the output from the libpbd
test program (in config.log) and stuck it in a file and compiled it with the
same compile line configure did, it compiled fine.. I think its the return
value from this test program.. I posted it below. It appears that the
version comparison does a !=.. Since its checking for 1.1.0 wouldn't this be
wrong?
    Josh

#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!=$pbd_major_version ||
       pbd_minor_version!=$pbd_minor_version ||
       pbd_micro_version!=$pbd_micro_version)
     { printf("(%d.%d.%d) ",
         pbd_major_version,pbd_minor_version,pbd_micro_version);
       return 1;
     }
  }

[softwerk-dev] new release, plus "manual"

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

I put a new tarball release (1.99.2) on sourceforge with fixes for
that egregious bug in all the library version-sanity checking code,
plus a smaller minimum window size.

I also put in place a version of the docs from an older version of
softwerk. they are not totally current, but they will help you to
understand what the program can do. see the "manual" link from the
home page.

schlaf gut,

--p

Re: [softwerk-dev] Troubles with Softwerk

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

Greetings:

  Still no joy. At this point my head is approaching the consistency of
setting concrete. I'll try again tomorrow, gotta catch some zzzsss...

  Btw, when I ran conftest outside of the SoftWerk home directory I
received this message:

./conftest: error in loading shared libraries: libpbd-1-1-1.so: cannot
open shared object file: No such file or directory

   And 'ldd conftest' reported:

[dlphilp@localhost dlphilp]$ ldd conftest
        libpbd-1-1-1.so => not found
        libltdl.so.0 => /usr/lib/libltdl.so.0 (0x4001d000)
        libsigc-1.0.so.0 => /usr/local/lib/libsigc-1.0.so.0 (0x40021000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40030000)
        libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2
(0x40041000)
        libm.so.6 => /lib/libm.so.6 (0x40083000)
        libc.so.6 => /lib/libc.so.6 (0x4009f000)
        libdl.so.2 => /lib/libdl.so.2 (0x40193000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


   Note that I built conftest in /home/dlphilp. I added the complete
paths for the includes in conftest.C. I'm yawning now, been up too
long...

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: "Heliosphan" by Aphex Twin


Paul Barton-Davis wrote:
> 
> In message <3A2...@br...>you write:
> >Greetings:
> >
> >  It compiled fine, not one complaint. So what do you think is happening
> 
> i have an idea. a fairly good idea. and its a problem in every single
> library of mine. observe:
> 
> >> 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;
> >>      }
> >>   }
> 
> now, what do you suppose this program returns if the versions numbers
> *do* match ?
> 
> 10 extra points if you can say "its undefined".
> 
> once i hear from you the result of running it, i'll put together a new
> version of the tarball. you can either add:
> 
>         return 0;
> 
> as the final statement of main(), or get the new tarball, heh,
> heh. strictly speaking, all my libraries need this. i'll leave it to
> you whether to patch them by hand (for library "foo", its
> .../softwerk/libs/src/foo/foo.m4 that contains the relevant source code)
> 
> BTW, I got this program from some other GNU auto*-using program. I
> wonder how many other programs have this problem ? or was it just me
> forgetting to add the "return 0;" in place.
> 
> I hope this is really the problem - its a giant discovery for me, even
> if its not the problem. so thanks.
> 
> --p
> 
> ps. for CVS users, the changes have just been committed.
> 
> _______________________________________________
> Softwerk-dev mailing list
> Sof...@li...
> http://lists.sourceforge.net/mailman/listinfo/softwerk-dev

--

Re: [softwerk-dev] Troubles with Softwerk

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

In message <3A2...@br...>you write:
>Greetings:
>
>  It compiled fine, not one complaint. So what do you think is happening

i have an idea. a fairly good idea. and its a problem in every single
library of mine. observe:

>> 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;
>>      }
>>   }

now, what do you suppose this program returns if the versions numbers
*do* match ?

10 extra points if you can say "its undefined". 

once i hear from you the result of running it, i'll put together a new
version of the tarball. you can either add:

	return 0;

as the final statement of main(), or get the new tarball, heh,
heh. strictly speaking, all my libraries need this. i'll leave it to
you whether to patch them by hand (for library "foo", its
.../softwerk/libs/src/foo/foo.m4 that contains the relevant source code)

BTW, I got this program from some other GNU auto*-using program. I
wonder how many other programs have this problem ? or was it just me
forgetting to add the "return 0;" in place.

I hope this is really the problem - its a giant discovery for me, even
if its not the problem. so thanks.

--p

ps. for CVS users, the changes have just been committed.

Re: [softwerk-dev] Troubles with Softwerk

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

>  It compiled fine, not one complaint. So what do you think is happening

ok, so now run it and tell me what it prints out ...

Re: [softwerk-dev] Troubles with Softwerk

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

Greetings:

  It compiled fine, not one complaint. So what do you think is happening
?

  The extern came straight from the config.log file, no changes made
here.

Best regards,

== Dave Phillips


Paul Barton-Davis wrote:
> 
> 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 ?
> 
> _______________________________________________
> Softwerk-dev mailing list
> Sof...@li...
> http://lists.sourceforge.net/mailman/listinfo/softwerk-dev

--