softwerk-dev

Re: [softwerk-dev] tarball 2.0.1 compile error / binary please??

[Paul D. <pa...@li...>]

On Thu, 2007-08-30 at 15:03 +0200, pl...@gm... wrote:
> Hello folks, (hope this list is still alive)
> 
> i've been interested in softwerk for a long time, and finally took the effort to try to get it compiled on my (fresh) Ubuntu 7.04 (aka feisty)system.
> 
> i'm using the 2.0.1 tarball,

there's a much newer version that i haven't released. i worked on it
about 8 months ago. it runs, but the build system really doesn't a good
job of installing it, meaning that typically first time usage fails and
you have to figure out what is wrong.

you can find it here: http://ardour.org/files/softwerk-3.0.tar.bz2

it uses GTK+ 2 and scons now (like ardour), and has a few other
improvements.

--p

[softwerk-dev] tarball 2.0.1 compile error / binary please??

[<pl...@gm...>]

Hello folks, (hope this list is still alive)

i've been interested in softwerk for a long time, and finally took the effort to try to get it compiled on my (fresh) Ubuntu 7.04 (aka feisty)system.

i'm using the 2.0.1 tarball, and besides having to install some additional (developer) packages from the official Ubuntu-distro repository (.deb's) i only needed to change the 'gtk > 1.4' references in ./configure and ./configure.ac to 'gtk+ > 1.2' to get the ./configure script to finish without errors.
(The story about the '+' has been dealt with before, and i decided to change '1.4' into '1.2' since the README file mentions only gtk 1.2, and i found out that gtk+ 1.4 not really exists anyway, kind of, since 1.3 was directly followed up by 2.0, or so they say.)

But the problem i run into is the following: when running a 'make', (whether it is the 'big one' in the main 'softwerk' directory or the separate one in the ./libs/pbd directory) i get the following output:

====start 'make'-output============================

Making all in pbd
make[2]: Entering directory `/home/anti/softwerk-2.0.1/libs/pbd'
make  all-recursive
make[3]: Entering directory `/home/anti/softwerk-2.0.1/libs/pbd'
Making all in pbd
make[4]: Entering directory `/home/anti/softwerk-2.0.1/libs/pbd/pbd'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/home/anti/softwerk-2.0.1/libs/pbd/pbd'
make[4]: Entering directory `/home/anti/softwerk-2.0.1/libs/pbd'
if g++ -DHAVE_CONFIG_H -I. -I. -I.     -g -D_REENTRANT -Wall -fno-merge-constants -I/home/anti/softwerk-2.0.1/src -I/home/anti/softwerk-2.0.1/libs -I/home/anti/softwerk-2.0.1/libs/sigc++ -I/home/anti/softwerk-2.0.1/libs/sigc++/sigc++/config -I/home/anti/softwerk-2.0.1/libs/pbd -I/home/anti/softwerk-2.0.1/libs/midi++ -I/home/anti/softwerk-2.0.1/libs/gtkmmext -I/home/anti/softwerk-2.0.1/libs/gtkmm/gdk-- -I/home/anti/softwerk-2.0.1/libs/gtkmm/src -I/home/anti/softwerk-2.0.1/libs/gtkmm -I/usr/include/libxml2   -MT pathscanner.o -MD -MP -MF ".deps/pathscanner.Tpo" \
          -c -o pathscanner.o `test -f 'pathscanner.cc' || echo './'`pathscanner.cc; \
        then mv -f ".deps/pathscanner.Tpo" ".deps/pathscanner.Po"; \
        else rm -f ".deps/pathscanner.Tpo"; exit 1; \
        fi
pathscanner.cc: In member function 'std::string* PathScanner::find_first(const std::string&, const std::string&, bool, bool)':
pathscanner.cc:171: error: 'vector_delete' was not declared in this scope
pathscanner.cc: In member function 'std::string* PathScanner::find_first(const std::string&, bool (*)(const std::string&, void*), void*, bool, bool)':
pathscanner.cc:198: error: 'vector_delete' was not declared in this scope
make[4]: *** [pathscanner.o] Error 1
make[4]: Leaving directory `/home/anti/softwerk-2.0.1/libs/pbd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/anti/softwerk-2.0.1/libs/pbd'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/anti/softwerk-2.0.1/libs/pbd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/anti/softwerk-2.0.1/libs'
make: *** [all-recursive] Error 1

=========end 'make'-ouput======================

i've been trying around a bit with putting: "using namespace std;" and 'include' lines, but no succes, the problem stays the same.
The 'stl_delete.h' file is also included properly in this 'pathscanner.cc' source, so i don't know how this 'not declared'-stuff can pop up. (i have some minor experience with c++-coding, but not with such big multi-file projects like these..)

Can this be an issue of not using the right gtk+ version (i have the (developer)versions 1.2 and 2.0 installed)?? Or does anybody know how to cure this kind of problem in another way?

Besides that i would like to be able to 'roll-my-own' SoftWerk, i'm also really really interested in the binary version. Since i can hardly wait to start using Softwerk on a laptop in combination with my WaveIdea BitstreamPro MIDI controller as a step/loop-sequencer in a live setting. (I've got a long way trying to make something similar myself with PureData, but since somebody already did something very close to what i was creating i thought it would make more sense to not invent the wheel over and over again.)

cheers, hope i can contribute a little to this project in a way.

--peter.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

[softwerk-dev] bugging you again

[Brian D. <job...@ya...>]

wow you must be bussy.  You told that dude in feb 2004
to bug you again about compile issues... I've having
the same issues so i'm doing his job for him.
consitter yourself bugged, because i really want to
try this thing out.
God Bless
Brian

Re: [softwerk-dev] softwerk compiler error

[Paul D. <pa...@li...>]

>Hello, is there anybody out there - ok i know, i'm a little bit outdated .
>three years after the last release - but maybe someone can help me with 
>this little problem. it a compiler error.
>i have tried to compile the libs directory - as described in the readme 
>file

i need to build a new version of softwerk that includes a newer set of
the libraries from the ardour project.

meanwhile, add

  using namespace std;

somewhere toward the top of the file transmitter.h.

there may be other problems like this, all related to the greater C++
compliance of newer g++ compilers. i don't have time right now to test
out compilation with a new g++ - i suspect there will be other issues
like this - all simple to fix in exactly the same way.

bug me again about this in a few weeks and i will try to do a new
release.

--p

[softwerk-dev] softwerk compiler error

[<con...@gm...>]

Hello, is there anybody out there - ok i know, i'm a little bit outdated .
three years after the last release - but maybe someone can help me with 
this little problem. it a compiler error.
i have tried to compile the libs directory - as described in the readme 
file

thanks c~

------------------------   schnipp

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=/tmp/so
ftwerk-1.99.2/libs); \
fi
touch .configured_pbd
(cd build/pbd; make)
make[1]: Entering directory `/tmp/softwerk-1.99.2/libs/build/pbd'
make  all-recursive
make[2]: Entering directory `/tmp/softwerk-1.99.2/libs/build/pbd'
Making all in pbd
make[3]: Entering directory `/tmp/softwerk-1.99.2/libs/build/pbd/pbd'
make[3]: Für das Ziel »all« ist nichts zu tun.
make[3]: Leaving directory `/tmp/softwerk-1.99.2/libs/build/pbd/pbd'
make[3]: Entering directory `/tmp/softwerk-1.99.2/libs/build/pbd'
/bin/sh ./libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I../../src/pbd -I.
  -g -O2 -I/usr/lib/sigc++-1.0/include -I/usr/include/sigc++-1.0 -c 
../../src/pbd
/language_guru.cc
c++ -DHAVE_CONFIG_H -I. -I../../src/pbd -I. -g -O2 
-I/usr/lib/sigc++-1.0/include
  -I/usr/include/sigc++-1.0 -Wp,-MD,.deps/language_guru.pp -c  -fPIC 
-DPIC ../../
src/pbd/language_guru.cc -o language_guru.lo
In file included from /usr/include/g++/backward/strstream:51,
                  from ../../src/pbd/pbd/transmitter.h:24,
                  from ../../src/pbd/pbd/error.h:23,
                  from ../../src/pbd/language_guru.cc:24:
/usr/include/g++/backward/backward_warning.h:32:2: warning: #warning 
This file i
ncludes at least one deprecated or antiquated header. Please consider 
using one
of the 32 headers found in section 17.4.1.2 of the C++ standard. 
Examples includ
e substituting the <X> header for the <X.h> header for C++ includes, or 
<sstream
 > instead of the deprecated header <strstream.h>. To disable this 
warning use -W
no-deprecated.
In file included from ../../src/pbd/pbd/error.h:23,
                  from ../../src/pbd/language_guru.cc:24:
../../src/pbd/pbd/transmitter.h: In function `std::ostream&
    endmsg(std::ostream&)':
../../src/pbd/pbd/transmitter.h:83: error: `cout' undeclared (first use this
    function)
../../src/pbd/pbd/transmitter.h:83: error: (Each undeclared identifier is
    reported only once for each function it appears in.)
In file included from ../../src/pbd/language_guru.cc:25:
../../src/pbd/pbd/parser.h: At global scope:
../../src/pbd/pbd/parser.h:55: error: use of `istream' is ambiguous
../../src/pbd/pbd/parser.h:30: error:   first declared as `struct 
istream' here
/usr/include/g++/iosfwd:138: error:   also declared as `typedef struct
    std::basic_istream<char, std::char_traits<char> > std::istream' here
../../src/pbd/pbd/parser.h:55: error: `istream' denotes an ambiguous type
../../src/pbd/pbd/parser.h:30: error:   first type here
/usr/include/g++/iosfwd:61: error:   other type here
../../src/pbd/pbd/parser.h:55: error: `in' was not declared in this scope
../../src/pbd/pbd/parser.h:55: error: use of `ostream' is ambiguous
../../src/pbd/pbd/parser.h:31: error:   first declared as `struct 
ostream' here
/usr/include/g++/iosfwd:139: error:   also declared as `typedef struct
    std::basic_ostream<char, std::char_traits<char> > std::ostream' here
../../src/pbd/pbd/parser.h:55: error: `ostream' denotes an ambiguous type
../../src/pbd/pbd/parser.h:31: error:   first type here
/usr/include/g++/iosfwd:64: error:   other type here
../../src/pbd/pbd/parser.h:55: error: `out' was not declared in this scope
../../src/pbd/pbd/parser.h:55: error: invalid data member initialization
../../src/pbd/pbd/parser.h:55: error: (use `=' to initialize static data
    members)
../../src/pbd/pbd/parser.h:55: error: variable or field `switch_streams'
    declared void
make[3]: *** [language_guru.lo] Fehler 1
make[3]: Leaving directory `/tmp/softwerk-1.99.2/libs/build/pbd'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/tmp/softwerk-1.99.2/libs/build/pbd'
make[1]: *** [all-recursive-am] Fehler 2
make[1]: Leaving directory `/tmp/softwerk-1.99.2/libs/build/pbd'
make: *** [build/pbd/.libs/libpbd.la] Fehler 2
conrad@linux:/tmp/softwerk-1.99.2/libs>

Re: [softwerk-dev] Compiling from CVS... no go.

[Paul W. <sli...@ya...>]

I wrote:

> But in the process I noticed some things in the softwerk README that
> could use updating...  new version attached, use it if it's useful.

Well, this time it's actually attached.

-- 
................    paul winkler   ................
 custom calendars:   http://www.calendargalaxy.com
   A member of ARMS:   http://www.reacharms.com
        home page:  http://www.slinkp.com

[softwerk-dev] Compiling from CVS... no go.

[Paul W. <sli...@ya...>]

Hi there,

Now writing to the list like a good boy... sorry for the personal
mail, PD.

I have concluded that cvs softwerk is way out of date with pbd's other
cvs libs. No compile for me. Oh well.

But in the process I noticed some things in the softwerk README that
could use updating...  new version attached, use it if it's useful.

I'm now trying the softwerk tarball with the included libs.
No joy there either. It fails at this point:

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 found the log in libs/gtkmmext/config.log:


configure: failed program was:
#line 3156 "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;
     }
  }



-- 
................    paul winkler   ................
 custom calendars:   http://www.calendargalaxy.com
   A member of ARMS:   http://www.reacharms.com
        home page:  http://www.slinkp.com

Re: [softwerk-dev] CVS compile

[Paul D. <pb...@Op...>]

>And it mentions not to compile those libs first(?) but I've
>just got ardour almost compiled... so might there be a
>better strategy to get the lot compiled for the first time ?

use the exact same strategy as for ardour on the softwerk instances of the
"quasimodo libs" OR use the strategy for a "global install" described
in the ARDOUR README.

sorry its not clearer. i haven't paid anywhere near as much attention
to the docs on building SoftWerk as the ones for Ardour, but the
theory in both cases is (or should be) identical.

--p

[softwerk-dev] CVS compile

[Mark C. <ma...@re...>]

Sorry to be boring but just trying to compile, well, all
your audio tools seeing I just discovered them.

In the softwerk README it says...

         cd .../softwerk/libs/src
         ln -s $QM/libs/{pbd,midi++,guileconfig,gtkmmext} .
         make

but there was no softwerk/libs/src directory in the CVS checkout,
so I made it and as per instructions and I now have...

/usr/src/softwerk/libs/src# ls -l
... gtkmmext -> /usr/src/quasimodo/libs/gtkmmext/
... guileconfig -> /usr/src/quasimodo/libs/guileconfig/
... midi++ -> /usr/src/quasimodo/libs/midi++/
... pbd -> /usr/src/quasimodo/libs/pbd/

but there is no Makefile in sight for make to do it's thing ?

And it mentions not to compile those libs first(?) but I've
just got ardour almost compiled... so might there be a
better strategy to get the lot compiled for the first time ?

Obviously once I see this stuff working I'll have a much
better idea how it fits together but that does not help me
at this stage.

--markc

Re: [softwerk-dev] softwerk newbie

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

>./configure as well as make in the /libs dir gives this
>error....probably common...
>
>libgtkmmext requires Gtk--, but it doesn't appear to be installed.

send me the complete set of steps you executed, as well as the
config.log file. i don't understand what you mean by "./configure in
/libs" since there is no such script there.

>I'm running redhat 7 respin with gtk version 1.2.8 and gnome-libs 1.2.4

very bad idea. redhat 7 sounds like the biggest pain the neck this
side of windows right now :)

--p

[softwerk-dev] softwerk newbie

[mezcor y. <me...@be...>]

./configure as well as make in the /libs dir gives this
error....probably common...

libgtkmmext requires Gtk--, but it doesn't appear to be installed.

Hmmmm..

I'm running redhat 7 respin with gtk version 1.2.8 and gnome-libs 1.2.4

Any advice????


tia,
Chad

Re: [softwerk-dev] patch for direct text entry

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

man, there is a bit of delay between when I send my messages and when
they are posted that really makes me look foolish.  I'll keep trying to
figure out the code and what is possible before opening my mouth again. 
But what you say here makes sense to me from what I have figured out so
far. 

reynald

Paul Barton-Davis wrote:

> 
> BTW, the reason its more complex than I said last time is that you
> have to either get both note-on and note-off events, or create a new
> mode which is just like absolute pitch but grabs note-on values
> only. keep looking, but its probably something i'll need to handle.

Re: [softwerk-dev] patch for direct text entry

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

>For instance, to change any.connect, I have to know what this line
>means:
>
>any_connection = input_port->input()->any.connect 
>		(slot (*this, &Sequence::handle_midimsg));
>
>input_port is of type MIDI::Port, which in turn is defined in the
                                                    ^^^^^^^
						    declared
					    
>addition to the MIDI namespace in trigger.h (i think).   But where is
>Port defined? 

   libs/src/midi++/midi++/port.h

BTW, the reason its more complex than I said last time is that you
have to either get both note-on and note-off events, or create a new
mode which is just like absolute pitch but grabs note-on values
only. keep looking, but its probably something i'll need to handle.

--p

Re: [softwerk-dev] patch for direct text entry

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

>  But where is Port defined?

never mind, I've found it. 

reynald

Re: [softwerk-dev] patch for direct text entry

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

> reynald - did you bother to try
> to hack up the "recorded MIDI is notes on/off only" ? it just occured
> to me that its a little more complex than i first suggested ... :)

I'm still going over your code trying to figure out what's going on.  

For instance, to change any.connect, I have to know what this line
means:

any_connection = input_port->input()->any.connect 
		(slot (*this, &Sequence::handle_midimsg));

input_port is of type MIDI::Port, which in turn is defined in the
addition to the MIDI namespace in trigger.h (i think).   But where is
Port defined? 

thanks,
reynald

Re: [softwerk-dev] note input

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

Paul Barton-Davis wrote:

> which version do you have ? the RETURN stuff was added relatively
> recently. do you still have to move the mouse to change the values of
> the steps ?

I just synched with cvs and now keyboard changes work fine. thanks.
Mouse input is much better too now. 

> the patch i sent picks up the change immediately. if you're in the
> middle of editing when the step is executed, you'll get the value on
> display at that time (0 if the value is not a number or the entry is 
> blank).

ok, I'll try this out. but it works much better right now anyway.  right
now, if I change the note without pressing "enter", when the note is
played, the visual display turns back to the last entered note, so
eventually the display will reflect what is being played.  But I'll try
out the patch too, and see which way I like better. 

About the patch, I can't seem to get it to work.  I'm not much of a
patch expert. 

thanks,
reynald



Here's what I get:
  patch -p0 <p.diff 
patching file sequence_ui.cc
Hunk #1 FAILED at 578.
1 out of 1 hunk FAILED -- saving rejects to file sequence_ui.cc.rej
patching file softwerk_ui.rc
Hunk #1 FAILED at 157.
1 out of 1 hunk FAILED -- saving rejects to file softwerk_ui.rc.rej
patching file step_ui.cc
Hunk #1 FAILED at 52.
Hunk #2 FAILED at 167.
2 out of 2 hunks FAILED -- saving rejects to file step_ui.cc.rej
patching file step_ui.h
Hunk #1 FAILED at 18.
1 out of 1 hunk FAILED -- saving rejects to file step_ui.h.rej

Re: [softwerk-dev] note input

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

>RETURN doesn't seem to work for me. the played value doesn't change. 

which version do you have ? the RETURN stuff was added relatively
recently. do you still have to move the mouse to change the values of
the steps ?

>1) when the user goes on to a different field, the value is not
>persistant.  it reverts to the value played value when the user goes
>onto something else. Then the note played will always be the number
>shown, unless you are in the act of editing it. 

dat's hard.

>2) or a "mode change" as "out of band"  --> when the cursor is no longer
>blinking in that square, note input is triggered, which syncs the number
>on the screen with what is played. 

dat's easy, but:

the patch i sent picks up the change immediately. if you're in the
middle of editing when the step is executed, you'll get the value on
display at that time (0 if the value is not a number or the entry is blank).

this seems fine for now.

--p

Re: [softwerk-dev] note input

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

> 
> in the most recent version of things, you need to press RETURN to
> "activate" the new value. 

RETURN doesn't seem to work for me. the played value doesn't change. 

the natural way for me would be either return or tab, which would also
automatically go on to the next field.  

As for partly-typed values, I can see two choices after the user has
typed something in:

1) when the user goes on to a different field, the value is not
persistant.  it reverts to the value played value when the user goes
onto something else. Then the note played will always be the number
shown, unless you are in the act of editing it. 

2) or a "mode change" as "out of band"  --> when the cursor is no longer
blinking in that square, note input is triggered, which syncs the number
on the screen with what is played. 

in both cases, the number on the screen matches what is played unless
you are actively editing it. that's the important part to me. 

reynald

> i am still thinking about the best way
> around this. the problem is that i don't want to use a partly-typed
> number, at least i think i don't, so you need some "out of band"
> operation to say "i'm done". or perhaps it really is OK to use the
> partly typed number. let me know what you think.

[softwerk-dev] patch for direct text entry

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

If you really want instant-text-update of step values, here's a patch.
It also correct the step value display entry box being editable when
the sequence contains raw midi values. reynald - did you bother to try
to hack up the "recorded MIDI is notes on/off only" ? it just occured
to me that its a little more complex than i first suggested ... :)

--p

Index: sequence_ui.cc
===================================================================
RCS file: /cvsroot/softwerk/softwerk/sequence_ui.cc,v
retrieving revision 1.10
diff -c -u -r1.10 sequence_ui.cc
--- sequence_ui.cc	2000/05/05 14:10:05	1.10
+++ sequence_ui.cc	2000/12/05 02:38:35
@@ -578,6 +578,16 @@
 		noteBox.hide ();
 	}
 
+	if (_sequence.is_raw_midi()) {
+		for (step = steps.begin(); step != steps.end(); step++) {
+			(*step)->set_editable (false);
+		}
+	} else {
+		for (step = steps.begin(); step != steps.end(); step++) {
+			(*step)->set_editable (true);
+		}
+	}
+
 	for (step = steps.begin(); step != steps.end(); step++) {
 		(*step)->map_state ();
 	}
Index: softwerk_ui.rc
===================================================================
RCS file: /cvsroot/softwerk/softwerk/softwerk_ui.rc,v
retrieving revision 1.5
diff -c -u -r1.5 softwerk_ui.rc
--- softwerk_ui.rc	2000/11/28 20:07:48	1.5
+++ softwerk_ui.rc	2000/12/05 02:38:35
@@ -157,7 +157,6 @@
 
 style "terminal_marker"
 {
-#	bg[ACTIVE] = { 0.44, 0.41, 0.54 }
 	bg[ACTIVE] = { 0, 0.54, 0.97 }
 	bg[NORMAL] = { 0.42, 0.52, 0.45 }
 }
Index: step_ui.cc
===================================================================
RCS file: /cvsroot/softwerk/softwerk/step_ui.cc,v
retrieving revision 1.8
diff -c -u -r1.8 step_ui.cc
--- step_ui.cc	2000/11/28 20:07:48	1.8
+++ step_ui.cc	2000/12/05 02:38:36
@@ -52,7 +52,7 @@
 	valueDisplay.add_events (GDK_BUTTON_PRESS_MASK|GDK_BUTTON_RELEASE_MASK);
 	valueDisplay.button_press_event.connect (slot (this,&StepUI::value_display_button_press));
 	valueDisplay.button_release_event.connect (slot (this,&StepUI::value_display_button_release));
-	valueDisplay.activate.connect (slot (this, &StepUI::value_entered));
+	valueDisplay.changed.connect (slot (this, &StepUI::value_changed));
 
 	terminalButton.set_usize (10, 10);
 	terminalButton.set_name ("TerminalMarker");
@@ -167,15 +167,15 @@
 	ui_is_terminal = !step.is_terminal ();
 	ui_is_enabled = !step.is_enabled ();
 	queue_touch ();
-
 	touch ();
 }
 
 void
-StepUI::value_entered ()
+StepUI::value_changed ()
 
 {
-	int val = atoi (valueDisplay.get_text().c_str());
+	int val;
+	val = atoi (valueDisplay.get_text().c_str());
 	step.set (val);
 }
 
Index: step_ui.h
===================================================================
RCS file: /cvsroot/softwerk/softwerk/step_ui.h,v
retrieving revision 1.7
diff -c -u -r1.7 step_ui.h
--- step_ui.h	2000/11/28 20:07:48	1.7
+++ step_ui.h	2000/12/05 02:38:36
@@ -18,6 +18,9 @@
 	void map_state ();  /* called after substantive changes, eg.
 			       after a pattern load.
 			    */
+	void set_editable (bool yn) {
+		valueDisplay.set_editable (yn);
+	}
 	
 	friend class SequenceUI;
 

Re: [softwerk-dev] note input

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

>What is the procedure for typing in values rather than manipulating the
>default 60 with the mouse? 

you write the programmer :)

>I type a number into the box, but nothing
>seems to change except the number displayed. The note played is still
>60. 

in the most recent version of things, you need to press RETURN to
"activate" the new value. i am still thinking about the best way
around this. the problem is that i don't want to use a partly-typed
number, at least i think i don't, so you need some "out of band"
operation to say "i'm done". or perhaps it really is OK to use the
partly typed number. let me know what you think.

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

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

Paul Barton-Davis wrote:

> 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):

He he..

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

Checked it out.. Sounds like eerie zylophone music played in caverns
filled with pools of water.. I like it :) It reminds me a lot of some of
the sounds they used in the City of Lost Children sound track. Maybe we
should post more stuff. Its neat hearing what other people compose. It
would be cool to have a web site of Linux composed music. Or maybe a site
with links to various composed (and decomposed) pieces. Some scraps and
bits of stuff. Lates..
    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

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] softwerk input

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

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

should be fairly easy, and i agree with the design goals.

in sequence.cc, there is a method called start_midi_grab(). this
connects another method called "handle_midimsg()" to the "any" signal
of the MIDI input parser for the sequence's input port. every message
that is received is used to set the next step until all steps are set,
and then we remove the connection to the "any" signal.

so instead of doing that, connect to the "note_on" signal, and extract
the note number while in handle_midimsg, using it to set the step
value. most of the logic will stay exactly as it is now.

have fun!

--p