Discussion:
[Jamin] CVS commit
Steve Harris
2003-04-14 17:24:51 UTC
Permalink
Added input meter and trim fader work, made EQ sliders controllable via
keyboard.

Loading Image...

I have to click on the faders before they will accept keyboard events, I
dont know if thats a wackyness of my window manager or GTK. You can tab
through them though.

The meter is just a progress bar at the moment, which is pretty useless,
I guess it will have to be replaced by a custom widget at some point so we
can colourcode it and add a peak marker and scale, but it will do for now.

Now everything obove the compressors now works to some extent.

User question: what range should the EQ have? currently its -70 - +24, but
it occureed to me that if you need to drop 70dBs in the mastering stage
then something has gone horribly wrong!

Whats a more useful/normal range for mastering tools?

- Steve
Jan Depner
2003-04-14 20:37:31 UTC
Permalink
I downloaded and built. I have no idea what a good range is. What I
want to know is how you get the look that you have in that png.

Jan
Post by Steve Harris
Added input meter and trim fader work, made EQ sliders controllable via
keyboard.
http://www.ecs.soton.ac.uk/~swh/jamss.png
I have to click on the faders before they will accept keyboard events, I
dont know if thats a wackyness of my window manager or GTK. You can tab
through them though.
The meter is just a progress bar at the moment, which is pretty useless,
I guess it will have to be replaced by a custom widget at some point so we
can colourcode it and add a peak marker and scale, but it will do for now.
Now everything obove the compressors now works to some extent.
User question: what range should the EQ have? currently its -70 - +24, but
it occureed to me that if you need to drop 70dBs in the mastering stage
then something has gone horribly wrong!
Whats a more useful/normal range for mastering tools?
- Steve
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
Patrick Shirkey
2003-04-15 02:22:31 UTC
Permalink
Post by Jan Depner
I downloaded and built. I have no idea what a good range is. What I
want to know is how you get the look that you have in that png.
Jan
Post by Steve Harris
Added input meter and trim fader work, made EQ sliders controllable via
keyboard.
http://www.ecs.soton.ac.uk/~swh/jamss.png
I have to click on the faders before they will accept keyboard events, I
dont know if thats a wackyness of my window manager or GTK. You can tab
through them though.
Looks like wackyness at your end as I can now use the mouse wheel
without clicking on them
Post by Jan Depner
Post by Steve Harris
The meter is just a progress bar at the moment, which is pretty useless,
I guess it will have to be replaced by a custom widget at some point so we
can colourcode it and add a peak marker and scale, but it will do for now.
Now everything obove the compressors now works to some extent.
User question: what range should the EQ have? currently its -70 - +24, but
it occureed to me that if you need to drop 70dBs in the mastering stage
then something has gone horribly wrong!
Whats a more useful/normal range for mastering tools?
What about making it user adjustable with another fader or an option
setting?
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Jan Depner
2003-04-15 02:48:09 UTC
Permalink
I still want to know how Steve got it to look like that. Mine doesn't
look anywhere near that good.

Jan
Post by Patrick Shirkey
Post by Jan Depner
I downloaded and built. I have no idea what a good range is. What I
want to know is how you get the look that you have in that png.
Jan
Post by Steve Harris
Added input meter and trim fader work, made EQ sliders controllable via
keyboard.
http://www.ecs.soton.ac.uk/~swh/jamss.png
I have to click on the faders before they will accept keyboard events, I
dont know if thats a wackyness of my window manager or GTK. You can tab
through them though.
Looks like wackyness at your end as I can now use the mouse wheel
without clicking on them
Post by Jan Depner
Post by Steve Harris
The meter is just a progress bar at the moment, which is pretty useless,
I guess it will have to be replaced by a custom widget at some point so we
can colourcode it and add a peak marker and scale, but it will do for now.
Now everything obove the compressors now works to some extent.
User question: what range should the EQ have? currently its -70 - +24, but
it occureed to me that if you need to drop 70dBs in the mastering stage
then something has gone horribly wrong!
Whats a more useful/normal range for mastering tools?
What about making it user adjustable with another fader or an option
setting?
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
Patrick Shirkey
2003-04-15 03:08:18 UTC
Permalink
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine doesn't
look anywhere near that good.
I think that is the default gnome theme these days.

I would like to see a nicer background though. ATM it's bland as fuck.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-15 11:21:52 UTC
Permalink
Post by Patrick Shirkey
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine doesn't
look anywhere near that good.
I think that is the default gnome theme these days.
I would like to see a nicer background though. ATM it's bland as fuck.
Any ideas? Do you just provide an image and it will tile it onto the bg?

I think you can provide per-app GTK themes, so we could make a jam theme
if we wanted.

- Steve
Patrick Shirkey
2003-04-15 12:29:45 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine doesn't
look anywhere near that good.
I think that is the default gnome theme these days.
I would like to see a nicer background though. ATM it's bland as fuck.
Any ideas? Do you just provide an image and it will tile it onto the bg?
I think you can provide per-app GTK themes, so we could make a jam theme
if we wanted.
Seems to be all about the rc file. I'm looking into it now.

I have also made some additions to the notebook. I can check them in now
if you want.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-15 12:46:50 UTC
Permalink
Post by Patrick Shirkey
Seems to be all about the rc file. I'm looking into it now.
K
Post by Patrick Shirkey
I have also made some additions to the notebook. I can check them in now
if you want.
Sure, I'm trying not to work on it today.

- Steve
Alexandre Prokoudine
2003-04-15 08:37:26 UTC
Permalink
On Tue, 15 Apr 2003 12:08:18 +0900
Post by Patrick Shirkey
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine
doesn't look anywhere near that good.
I think that is the default gnome theme these days.
I would like to see a nicer background though. ATM it's bland as fuck.
Easy, tiger :-)

Appearance of Gtk+(2) applications can be easily and
precisely customizable. Didn't you see Ardour? :-)
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: ***@altlinux.org
Patrick Shirkey
2003-04-15 15:26:54 UTC
Permalink
Post by Alexandre Prokoudine
On Tue, 15 Apr 2003 12:08:18 +0900
Post by Patrick Shirkey
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine
doesn't look anywhere near that good.
I think that is the default gnome theme these days.
I would like to see a nicer background though. ATM it's bland as fuck.
Easy, tiger :-)
Appearance of Gtk+(2) applications can be easily and
precisely customizable. Didn't you see Ardour? :-)
Yep, For three years now.

I'm currently devouring the gtk docs esp regards to the rc files.
However if you can whip something up which uses xml then please do.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-15 11:20:21 UTC
Permalink
Post by Patrick Shirkey
Post by Steve Harris
I have to click on the faders before they will accept keyboard events, I
dont know if thats a wackyness of my window manager or GTK. You can tab
through them though.
Looks like wackyness at your end as I can now use the mouse wheel
without clicking on them
I dont have a mouse wheel, so I can't compare that. I guess making them
take focus on entry would fix it, but will it have unwanted side effects?
I could try it, its only a few lines of code.
Post by Patrick Shirkey
What about making it user adjustable with another fader or an option
setting?
Seems reasonable, we should try to keep the UI as simple as we cna though,
its allready a bit overwhelming :) I tried adding a vertical button bar to
the right, but it takes up too much realestate (I'm thinking of your
800x600 requirement), how about a context menu? It could have reset to
flat, and some range options, eg. +/-6, +/-12 +/-24 +24/-48 +24/-96.

I think we just have to mangle the lower/upper values in the adjustments
in geqa[] in geq.c and call gtk_adjustment_clamp_page() +
gtk_adjustment_changed() on them. I've no idea how to create a context
menu though.

- Steve
Steve Harris
2003-04-15 09:58:55 UTC
Permalink
Post by Jan Depner
I downloaded and built. I have no idea what a good range is. What I
want to know is how you get the look that you have in that png.
It's the default RH8/9 GTK theme.

- Steve
Alexandre Prokoudine
2003-04-16 07:08:35 UTC
Permalink
On Tue, 15 Apr 2003 10:58:55 +0100
Post by Steve Harris
It's the default RH8/9 GTK theme.
BlueCurve -- for those hunting for it in th Net :-)
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: ***@altlinux.org
e***@cableone.net
2003-04-15 12:20:48 UTC
Permalink
Steve,

A cool background would be kinda nice (wait, wasn''t I the one bitching about eye candy in T-RackS ;)

Speaking of eye candy, you had mentioned something about making a special widget for the gain meters. Won't this break our glade use? I'm kinda getting used to it ;) How about just using a rectangular drawing area and painting in the meter level with blend from blue to red?

Jan



-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Tue, 15 Apr 2003 12:21:52 +0100
To: "JAMin mailing list" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by Patrick Shirkey
Post by Jan Depner
I still want to know how Steve got it to look like that. Mine doesn't
look anywhere near that good.
I think that is the default gnome theme these days.
I would like to see a nicer background though. ATM it's bland as fuck.
Any ideas? Do you just provide an image and it will tile it onto the bg?

I think you can provide per-app GTK themes, so we could make a jam theme
if we wanted.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Steve Harris
2003-04-15 13:00:20 UTC
Permalink
Post by e***@cableone.net
Steve,
A cool background would be kinda nice (wait, wasn''t I the one bitching about eye candy in T-RackS ;)
Speaking of eye candy, you had mentioned something about making a special widget for the gain meters. Won't this break our glade use? I'm kinda getting used to it ;) How about just using a rectangular drawing area and painting in the meter level with blend from blue to red?
Well, under the hood it will probably just be a drawing area, but there
are a bunch of meters, so it probably makes more sense to make a
subclassed widget. A friend also needs one for another GTK2 project, so I
can get help.

Glade has a custom widget option (gtk additional, at the bottom a blue C),
it has all the normal glade control, plus you can specify some creation
arguments.

Drawing the meter itsself is easy enough, but the scale is a bit trickier
to draw. If we make all the meters the same size we can just use a bitmap,
like I did in SDL, but if they are scalable its trickier.

- Steve
e***@cableone.net
2003-04-15 13:15:56 UTC
Permalink
Here's another idea - I've seen some meters like this - a rectangular drawing area with rectangular subareas. Each subarea can be a filled rectangle with an assigned color from blue to red (or whatever). You just paint the subareas either their assigned color or the background color depending on the level. It shouldn't be hard to scale this and it's a lot easier than using a bitmap. For something like this you'd need size, orientation, min value, max value, number of subareas, start color, and end color. I have some code that generates colors given starting and ending HSV values. I think it came out of the old SRGP stuff.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Tue, 15 Apr 2003 14:00:20 +0100
To: "JAMin mailing list" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by e***@cableone.net
Steve,
A cool background would be kinda nice (wait, wasn''t I the one bitching about eye candy in T-RackS ;)
Speaking of eye candy, you had mentioned something about making a special widget for the gain meters. Won't this break our glade use? I'm kinda getting used to it ;) How about just using a rectangular drawing area and painting in the meter level with blend from blue to red?
Well, under the hood it will probably just be a drawing area, but there
are a bunch of meters, so it probably makes more sense to make a
subclassed widget. A friend also needs one for another GTK2 project, so I
can get help.

Glade has a custom widget option (gtk additional, at the bottom a blue C),
it has all the normal glade control, plus you can specify some creation
arguments.

Drawing the meter itsself is easy enough, but the scale is a bit trickier
to draw. If we make all the meters the same size we can just use a bitmap,
like I did in SDL, but if they are scalable its trickier.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Steve Harris
2003-04-15 13:45:05 UTC
Permalink
Post by e***@cableone.net
Here's another idea - I've seen some meters like this - a rectangular drawing area with rectangular subareas. Each subarea can be a filled rectangle with an assigned color from blue to red (or whatever). You just paint the subareas either their assigned color or the background color depending on the level. It shouldn't be hard to scale this and it's a lot easier than using a bitmap. For something like this you'd need size, orientation, min value, max value, number of subareas, start color, and end color. I have some code that generates colors given starting and ending HSV values. I think it came out of the old SRGP stuff.
The only colours you need are green, yellow (maybe) and red. and the
borders are fixed, so I was just planning to draw the difference between the
last meter state and the current one for each frame. It will come down to
drawing a small black rectangle or 1-03 coloured onces, but generally the
change is only a few pixels.

- Steve
Steve Harris
2003-04-16 07:39:39 UTC
Permalink
* Added missing EQ band at 2k5
* Added EQ band at 20k
* Calcualte EQ tooltip values from band maths (but dont remove the tooltips
from glade, thier still needed).
* Now using base10 band maths, instead of base2 and we have all 30 bands so
we are nearly BS EN ISO 266 compliant :)
* Refactored the backend init code, Mark you shouldn't be seeing those
random segfaults anymore.

I had to comment out the gtk_rc_parse() line in main.c to get it to run.
I'm still ot sure why it wasn't working for me. Does it need someting more
than an empty file?

- Steve
Patrick Shirkey
2003-04-16 12:03:38 UTC
Permalink
Post by Steve Harris
I had to comment out the gtk_rc_parse() line in main.c to get it to run.
I'm still ot sure why it wasn't working for me. Does it need someting more
than an empty file?
I'll look into this tonight.

While I was working on it yesterday I got the impression that if you
don't have the rc file it just wouldn't customise the gui.

I guess the solution is the one Jack provided using prefix.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-16 13:07:58 UTC
Permalink
Post by Patrick Shirkey
Post by Steve Harris
I had to comment out the gtk_rc_parse() line in main.c to get it to run.
I'm still ot sure why it wasn't working for me. Does it need someting more
than an empty file?
I'll look into this tonight.
While I was working on it yesterday I got the impression that if you
don't have the rc file it just wouldn't customise the gui.
I tried adding your provided .jamrc file and changing the code in main
slightly:

snprintf(rcfile, 255, "%s/%s", getenv("HOME"), ".jamrc");
if ((fd = open(rcfile, O_RDONLY))) {
close(fd);
printf("Using jamrc file: %s\n", rcfile);
gtk_rc_parse("/root/.jamrc");
}

It appears to be happy now, but I odnt get any customisations, I guess its
cos I dont have the bitmaps? Did you post them?

- Steve
Patrick Shirkey
2003-04-16 13:08:16 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
Post by Steve Harris
I had to comment out the gtk_rc_parse() line in main.c to get it to run.
I'm still ot sure why it wasn't working for me. Does it need someting more
than an empty file?
I'll look into this tonight.
While I was working on it yesterday I got the impression that if you
don't have the rc file it just wouldn't customise the gui.
I tried adding your provided .jamrc file and changing the code in main
snprintf(rcfile, 255, "%s/%s", getenv("HOME"), ".jamrc");
if ((fd = open(rcfile, O_RDONLY))) {
close(fd);
printf("Using jamrc file: %s\n", rcfile);
gtk_rc_parse("/root/.jamrc");
}
It appears to be happy now, but I odnt get any customisations, I guess its
cos I dont have the bitmaps? Did you post them?
I added them to cvs yesterday.

You may need to change the path in the .jamrc file.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-16 13:44:54 UTC
Permalink
Post by Patrick Shirkey
I added them to cvs yesterday.
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
Post by Patrick Shirkey
You may need to change the path in the .jamrc file.
Yup, done that. We should be able to set the path using auto*.

PS I'm just about to check in a couple of changes that make it more
800x600 safe and removed some brokeness that happened when you scaled the
window small.

- Steve
Patrick Shirkey
2003-04-16 13:56:04 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
I added them to cvs yesterday.
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
Not afaik. It could be using the /root/ dir with capabilties. Maybe you
could change the line in main.c to point to your home dir. I will look
into getting it to scan the real home dir.
Post by Steve Harris
Post by Patrick Shirkey
You may need to change the path in the .jamrc file.
Yup, done that. We should be able to set the path using auto*.
PS I'm just about to check in a couple of changes that make it more
800x600 safe and removed some brokeness that happened when you scaled the
window small.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Jack O'Quin
2003-04-16 15:15:36 UTC
Permalink
Post by Patrick Shirkey
Not afaik. It could be using the /root/ dir with capabilties. Maybe
you could change the line in main.c to point to your home dir. I will
look into getting it to scan the real home dir.
I tried that last night, it didn't help for me.

I am astonished at the interface to gtk_rc_parse(). Why accept a file
name argument, but segfault if it doesn't exist? That's absurd!
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-16 16:11:16 UTC
Permalink
Post by Patrick Shirkey
Post by Steve Harris
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
Not afaik. It could be using the /root/ dir with capabilties. Maybe you
could change the line in main.c to point to your home dir. I will look
into getting it to scan the real home dir.
Current cvs looks in $HOME/.jamrc, its finding the right file for me.

- Steve
Jack O'Quin
2003-04-16 18:39:46 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
Post by Steve Harris
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
Not afaik. It could be using the /root/ dir with capabilties. Maybe you
could change the line in main.c to point to your home dir. I will look
into getting it to scan the real home dir.
Current cvs looks in $HOME/.jamrc, its finding the right file for me.
I found some bugs in this code. A patch to fix them is attached.

But, it's still not working for me. I still get segfaults all over
the place. They're all in gtk+ somewhere, it's hard to debug. :-(

I'm beginning to worry that my Debian stable package for libgtk2.0-0
2.0.2-5woody1 is somehow badly broken. What versions are y'all using?
The configure.in requires gtk+-2.0 >= 1.3.13. My system passes that
test.

If I have to run the 2.2.1-4 package from unstable, I think I may be
in trouble. I may have to upgrade my whole system to meet its
dependencies. I can't even install the build-dependencies to compile
it from source. I sure hope I'm wrong about this.
--
Jack O'Quin
Austin, Texas, USA
Patrick Shirkey
2003-04-16 18:45:32 UTC
Permalink
Post by Jack O'Quin
Post by Steve Harris
Post by Patrick Shirkey
Post by Steve Harris
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
Not afaik. It could be using the /root/ dir with capabilties. Maybe you
could change the line in main.c to point to your home dir. I will look
into getting it to scan the real home dir.
Current cvs looks in $HOME/.jamrc, its finding the right file for me.
I found some bugs in this code. A patch to fix them is attached.
But, it's still not working for me. I still get segfaults all over
the place. They're all in gtk+ somewhere, it's hard to debug. :-(
I'm beginning to worry that my Debian stable package for libgtk2.0-0
2.0.2-5woody1 is somehow badly broken. What versions are y'all using?
The configure.in requires gtk+-2.0 >= 1.3.13. My system passes that
test.
If I have to run the 2.2.1-4 package from unstable, I think I may be
in trouble. I may have to upgrade my whole system to meet its
dependencies. I can't even install the build-dependencies to compile
it from source. I sure hope I'm wrong about this.
I'm using 2.2.1 from source. It was a very painless install but if you
are reliant on debpkg to run your system then I guess you will have to
wait for them to fix it :/
Post by Jack O'Quin
@@ -21,6 +21,7 @@
#include "geq.h"
#include "intrim.h"
#include "process.h"
+#include "limits.h"
^^^^^^^^^^^^^^^^^^^

Huh??? I don't even have this file in my cvs and everything works for me.

Those changes you made work like a charm BTW.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Jack O'Quin
2003-04-16 23:47:43 UTC
Permalink
Post by Patrick Shirkey
I'm using 2.2.1 from source. It was a very painless install but if you
are reliant on debpkg to run your system then I guess you will have to
wait for them to fix it :/
Post by Jack O'Quin
@@ -21,6 +21,7 @@
#include "geq.h"
#include "intrim.h"
#include "process.h"
+#include "limits.h"
^^^^^^^^^^^^^^^^^^^
Huh??? I don't even have this file in my cvs and everything works for me.
Hrmm. It doesn't seem to be needed. I wanted /usr/include/limits.h
for the definition of PATH_MAX, because I didn't like declaring
rcfile[256]. Then, I forgot to use angle brackets on the include.
Quotes still work, but they have the wrong connotation.

Yet, it turns out PATH_MAX is already defined somewhere in the
compilation of main.c, although I still can't see where. Perhaps
there's some GCC magic involved.

Probably the right thing to do is to change that include to...

#include <limits.h>

That should be POSIX-compliant, I believe.
Post by Patrick Shirkey
Those changes you made work like a charm BTW.
Good. I tested them as best I could, but since it's still not working
there was room for doubt. :-)
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-17 08:01:42 UTC
Permalink
Post by Jack O'Quin
Hrmm. It doesn't seem to be needed. I wanted /usr/include/limits.h
for the definition of PATH_MAX, because I didn't like declaring
rcfile[256].
Uh, yeah sorry. Bad habbits.

- Steve
Steve Harris
2003-04-16 20:08:59 UTC
Permalink
Post by Jack O'Quin
Post by Steve Harris
Current cvs looks in $HOME/.jamrc, its finding the right file for me.
I found some bugs in this code. A patch to fix them is attached.
Uh, thanks, I guess that explains why it wasn't doing anything for me ;)
Post by Jack O'Quin
I'm beginning to worry that my Debian stable package for libgtk2.0-0
2.0.2-5woody1 is somehow badly broken. What versions are y'all using?
The configure.in requires gtk+-2.0 >= 1.3.13. My system passes that
test.
I'm using Redhat's gtk2-2.0.6-8 and whatever comes with RH9. Appears to work
with both. I'm having problems syncing with cvs though.

- Steve
Patrick Shirkey
2003-04-16 14:06:08 UTC
Permalink
Post by Steve Harris
Post by Patrick Shirkey
I added them to cvs yesterday.
Duh, sorry, I forgot to update -dP, got em now. They dont seem to have
changed anything though, do I have to set anu options or flags?
I am now looking at a nice brushed steel version using the png from the
PressGang folder.

The good thing is that it is very easy to change the bg color now. Just
need a new style with the main pixmap and call it in the widget classes
at the bottom of the file.
Post by Steve Harris
Post by Patrick Shirkey
You may need to change the path in the .jamrc file.
Yup, done that. We should be able to set the path using auto*.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Alexandre Prokoudine
2003-04-16 13:30:12 UTC
Permalink
On Wed, 16 Apr 2003 23:06:08 +0900
Post by Patrick Shirkey
I am now looking at a nice brushed steel version using the png
from the PressGang folder.
BTW, shall we find a little place for a jar of JAM in the main
window? :-)
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: ***@altlinux.org
Mark Knecht
2003-04-16 15:57:04 UTC
Permalink
Post by Steve Harris
* Refactored the backend init code, Mark you shouldn't be seeing those
random segfaults anymore.
I'll build and look this evening. Thanks!
Mark Knecht
2003-04-16 23:16:15 UTC
Permalink
Post by Steve Harris
* Refactored the backend init code, Mark you shouldn't be seeing those
random segfaults anymore.
Steve,
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.

You're very much on the right track, I think.

Is there some way I can run this to give you more info? Of is the
following enough for you to look for any issues?

Cheers,
Mark

FROM THE JAM TERMINAL

(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed

(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed

(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4814
(gtk_widget_set_size_request): assertion `height >= -1' failed
Segmentation fault
[***@Wizard mark]$

FROM THE JACK TERMINAL

load = 7.0666 max usecs: 31.000, spare = 2871.000
load = 3.9640 max usecs: 25.000, spare = 2877.000
load = 2.3611 max usecs: 22.000, spare = 2880.000
new client: jam, id = 3 type 2 @ 0x402e1000 fd = 0
gave capabilities to process 4043
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
delivering event 5 to client alsa_pcm
client jam: start_fd=7, execution_order=0.
delivering event 5 to client jam
client jam: wait_fd=11, execution_order=1 (last client).
-- jack_rechain_graph()
port jam:in_L has mixdown = 0x4002b782
registered port jam:in_L, offset = 0
port jam:in_R has mixdown = 0x4002b782
registered port jam:in_R, offset = 0
port jam:out_L has mixdown = 0x4002b782
registered port jam:out_L, offset = 13824
subgraph starting at jam timed out (subgraph_wait_fd=11, status =
134637144, state = Running)
at 36355765013 client waiting on 11 took 2133 usecs, status = 1 sig =
36355762869 awa = 36355762888 fin = 0 dur=18446744037353788747
restart
client jam error: awake_at = 36355762888 state = 2 timed_out = 0
zombifying failed client jam state = Running errors = 1
senor jam - you are a zombie
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
delivering event 5 to client alsa_pcm
-- jack_rechain_graph()
removing failed client jam state = Not triggered errors = 10000000
adios senor jam
++ jack_rechain_graph():
client alsa_pcm: internal client, execution_order=0.
delivering event 5 to client alsa_pcm
-- jack_rechain_graph()
load = 1.6630 max usecs: 28.000, spare = 2874.000
load = 1.2967 max usecs: 27.000, spare = 2875.000
load = 1.2686 max usecs: 36.000, spare = 2866.000
load = 1.1512 max usecs: 30.000, spare = 2872.000
jackd: signal 2 received
jack main caught signal 2
[***@Wizard mark]$ uring shutd
Jack O'Quin
2003-04-16 23:49:44 UTC
Permalink
Post by Mark Knecht
FROM THE JAM TERMINAL
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4814
(gtk_widget_set_size_request): assertion `height >= -1' failed
Segmentation fault
Mark, I'm seeing that one, too. What version of GTK+2.0 are you
using?
--
Jack O'Quin
Austin, Texas, USA
Mark Knecht
2003-04-16 23:59:59 UTC
Permalink
Post by Jack O'Quin
Post by Mark Knecht
FROM THE JAM TERMINAL
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4814
(gtk_widget_set_size_request): assertion `height >= -1' failed
Segmentation fault
Mark, I'm seeing that one, too. What version of GTK+2.0 are you
using?
--
Jack,
Well, I think it's 2.0.6-8, but synaptic says it's gtk2 and
gtk2-devel, not gtk+2. I have a gtk+, and then gtk2, but no gtk+2.0.
There's also something called gtk2-engines installed that appears to be
version 1.9.0-4, so there's a bit more revision confusion.

Mark
Jack O'Quin
2003-04-17 00:35:59 UTC
Permalink
Post by Mark Knecht
Post by Jack O'Quin
Post by Mark Knecht
FROM THE JAM TERMINAL
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4813
(gtk_widget_set_size_request): assertion `width >= -1' failed
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4814
(gtk_widget_set_size_request): assertion `height >= -1' failed
Segmentation fault
Mark, I'm seeing that one, too. What version of GTK+2.0 are you
using?
--
Jack,
Well, I think it's 2.0.6-8, but synaptic says it's gtk2 and
gtk2-devel, not gtk+2. I have a gtk+, and then gtk2, but no gtk+2.0.
There's also something called gtk2-engines installed that appears to be
version 1.9.0-4, so there's a bit more revision confusion.
My Debian package is called libgtk2.0-0/stable, version 2.0.2-5woody1.
It sounds like nearly the same version you've got, if we ignore the
difference in package names between Debian and Red Hat.

People running 2.2.x versions don't seem to be seeing these segfaults.
It appears that some failed assertion within the gtk2 library is
printing these messages. When the segfault occurs, the call/return
stack is hosed...

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1504)]
0x32003836 in ?? ()
(gdb) bt
#0 0x32003836 in ?? ()
Cannot access memory at address 0x31202d20

So far, I haven't been able to find or build a gtk+ 2.2.x library that
works with my distribution, or I would use it to test the hypothesis
that this problem goes away with the latest version.

Does someone have a way to test JAM with *both* gtk+ versions?
--
Jack O'Quin
Austin, Texas, USA
Mark Knecht
2003-04-17 02:04:32 UTC
Permalink
Post by Jack O'Quin
People running 2.2.x versions don't seem to be seeing these segfaults.
It appears that some failed assertion within the gtk2 library is
printing these messages. When the segfault occurs, the call/return
stack is hosed...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1504)]
0x32003836 in ?? ()
(gdb) bt
#0 0x32003836 in ?? ()
Cannot access memory at address 0x31202d20
So far, I haven't been able to find or build a gtk+ 2.2.x library that
works with my distribution, or I would use it to test the hypothesis
that this problem goes away with the latest version.
I'm sort of stuck, as the Planet is RPM based, so unless I find an RPM
there isn't much I can do. The build instructions for 2.2.1 look pretty
benign, but looks can be deceiving. ;-)

I have a brand new RH 9.0 installation I did last night. I am
considering trying, finally, to have a machine where I build everything,
but I'm hesitant to invest the effort as I expect it would take weeks
away from my lifespan.

At least this isn't a critical failure, and this isn't the only program
that does this stuff. The version of apt that comes form Planet CCRMA
does the same sort of things. (Although much better with the most recent
release.)
Steve Harris
2003-04-17 08:02:30 UTC
Permalink
Post by Mark Knecht
I'm sort of stuck, as the Planet is RPM based, so unless I find an RPM
there isn't much I can do. The build instructions for 2.2.1 look pretty
benign, but looks can be deceiving. ;-)
RH9 is gtk 2.2, but it dousn't seem to help anyway.

- Steve
Steve Harris
2003-04-17 07:42:00 UTC
Permalink
Post by Jack O'Quin
People running 2.2.x versions don't seem to be seeing these segfaults.
It appears that some failed assertion within the gtk2 library is
printing these messages. When the segfault occurs, the call/return
stack is hosed...
I'm running 2.2 on my laptop and I was seeing them there. Unless they are
different segfaults. I think there jack related, they went away at larger
block siszes for me we I fixed the jack code ordering.

- Steve
Steve Harris
2003-04-17 07:26:54 UTC
Permalink
Post by Jack O'Quin
Post by Mark Knecht
(jam:4043): Gtk-CRITICAL **: file gtkwidget.c: line 4814
(gtk_widget_set_size_request): assertion `height >= -1' failed
Segmentation fault
Mark, I'm seeing that one, too. What version of GTK+2.0 are you
using?
I get tons of those, but I can't think where there coming from.

There not related to Marks crash AFAIK. The high number of crashes before
was caused by me doing too much work after I'd started jack, around the
time it was trying to warm over all the buffers and FFT code.

If you have a small number of samples/buffer I tyhink its possible for
jack to never execrsie the meat of the code. I'l manually run the FFT
stuff.

- Steve
Steve Harris
2003-04-17 07:24:18 UTC
Permalink
Post by e***@cableone.net
Post by Steve Harris
* Refactored the backend init code, Mark you shouldn't be seeing those
random segfaults anymore.
Steve,
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.
I think jam is just highly alergic to being zombied by jack, but I'm not
sure why.

Unfortunatly, due to the way jam works at the moment it will be very hard
to get it working at low samples/block settings. There are a few more
things I can do to help trivially, but the real solution is a major
reworking of the block handling code. Is it stable once it gets started?

Long term I'm planning to move to the same distribution scheme that
brutefir uses, but its a bit contraversial and it might not play well with
capabilities, which I would be very unhappy about.

- Steve
Mark Knecht
2003-04-17 11:54:47 UTC
Permalink
Post by Steve Harris
Post by e***@cableone.net
Post by Steve Harris
* Refactored the backend init code, Mark you shouldn't be seeing those
random segfaults anymore.
Steve,
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.
I think jam is just highly alergic to being zombied by jack, but I'm not
sure why.
Unfortunatly, due to the way jam works at the moment it will be very hard
to get it working at low samples/block settings. There are a few more
things I can do to help trivially, but the real solution is a major
reworking of the block handling code. Is it stable once it gets started?
Seems to be. I don't mean to make this sound too much like a problem for
me. I don't run at a block size of 64 anyway. Leave it alone for now.

Thanks!
Post by Steve Harris
Long term I'm planning to move to the same distribution scheme that
brutefir uses, but its a bit contraversial and it might not play well with
capabilities, which I would be very unhappy about.
- Steve
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
Jack O'Quin
2003-04-17 15:01:30 UTC
Permalink
Post by Steve Harris
Post by Mark Knecht
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.
I am seeing segfaults at -p 1024. I don't consider that a small block
size.
Post by Steve Harris
I think jam is just highly alergic to being zombied by jack, but I'm not
sure why.
Unfortunatly, due to the way jam works at the moment it will be very hard
to get it working at low samples/block settings. There are a few more
things I can do to help trivially, but the real solution is a major
reworking of the block handling code. Is it stable once it gets started?
Long term I'm planning to move to the same distribution scheme that
brutefir uses, but its a bit contraversial and it might not play well with
capabilities, which I would be very unhappy about.
Ouch! There was a long, fruitless discussion on jack-devel about
brutefir. I became convinced that the developer of brutefir has no
understanding of or interest in realtime programming, so I gave up on
him.

I agree with you (and him) that there are situations where it's
cleaner, easier and more efficient to run algorithms like FFT on
larger block sizes in a separate thread. But, screwing around with
thread priorities as he does is a hopeless kludge. The tradeoff boils
down to a very flakey and probably unreliable implementation that
saves *one* buffer period of latency compared to the obvious, clean
and reliable implementation using ring queues.

I would be glad to implement ring queue scheduling for JAM, if you
like. One extra period will make no difference in JAM anyway. But,
flakey I/O handling will be a disaster.

I'd like to work on this project, and that's something I know how to
do, whereas I know little about GTK or about DSP.

Regards,
--
Jack O'Quin
Austin, Texas, USA
Mark Knecht
2003-04-17 16:00:14 UTC
Permalink
Post by Jack O'Quin
Post by Mark Knecht
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.
I am seeing segfaults at -p 1024. I don't consider that a small block
size.
Humm....might be a relative speed thing between your machine and mine.
This one is an Athlon XP 2600+. What's yours?

My thought is that Jam probably links up to jack, as it's getting
started, but it still has a few jobs to do. Those jobs have to get done
before the first Jack period expires and it just doesn't make it? In my
case the machine is pretty fast, so it doesn't die as often as I might
expect a slower machine to die.

Is that a fair guess how how this stuff works? (I know nothing of JAck
programming.

I could test this at different sample rates (32KHz up to 96KHz) and see
if it's true. I would presume that 96KHz at -p 256 is the same as 48KHz
at 128?

BTW - I only see seg faults when starting the program. I have not seen
one yet when the program is running. Same for you?
Jack O'Quin
2003-04-17 16:30:19 UTC
Permalink
Post by Mark Knecht
Humm....might be a relative speed thing between your machine and mine.
This one is an Athlon XP 2600+. What's yours?
Mine is an XP 1800+. Certainly adequate for this purpose.
Post by Mark Knecht
My thought is that Jam probably links up to jack, as it's getting
started, but it still has a few jobs to do. Those jobs have to get done
before the first Jack period expires and it just doesn't make it?
I had the same suspicion, but now I don't think so. When I run jam
without gdb, I get the "adios senior jam" message from jackd (with -v)
after the segfault. But, when I run "gdb /usr/local/bin/jam", the
segfault is caught by the debugger. JACK never complains in that
case, and his "max usecs" messages remain very low.

So, I don't think this is a JACK timing problem. I think it's failing
in the GUI code. The error messages are coming out of the
create_window1() function (generated by glade), and the segfault
happens when gtk_widget_show is called. JACK only gets upset *after*
the segfault.
Post by Mark Knecht
BTW - I only see seg faults when starting the program. I have not seen
one yet when the program is running. Same for you?
For me it *never* gets past that point.

The GDB log is appended...
--
Jack O'Quin
Austin, Texas, USA
Mark Knecht
2003-04-17 16:54:39 UTC
Permalink
Post by Jack O'Quin
Post by Mark Knecht
Humm....might be a relative speed thing between your machine and mine.
This one is an Athlon XP 2600+. What's yours?
Mine is an XP 1800+. Certainly adequate for this purpose.
Absolutely.
Post by Jack O'Quin
Post by Mark Knecht
My thought is that Jam probably links up to jack, as it's getting
started, but it still has a few jobs to do. Those jobs have to get done
before the first Jack period expires and it just doesn't make it?
I had the same suspicion, but now I don't think so. When I run jam
without gdb, I get the "adios senior jam" message from jackd (with -v)
after the segfault. But, when I run "gdb /usr/local/bin/jam", the
segfault is caught by the debugger. JACK never complains in that
case, and his "max usecs" messages remain very low.
So, I don't think this is a JACK timing problem. I think it's failing
in the GUI code. The error messages are coming out of the
create_window1() function (generated by glade), and the segfault
happens when gtk_widget_show is called. JACK only gets upset *after*
the segfault.
So you're saying the seg fault is just a complete GUI problem where the
GUI code seg faults? Interesting. I wonder why, in my case, it is
related to the frame size? I can see why you're would not be...

I have no clue how this stuff gets done technically. My life designing
Ethernet & SCSI controllers, chipsets for PCs, and now 1394 controllers
affords me true multi-tasking. It's easy for me to make circuits that
truly run in parallel. On the software side, despite all efforts to
obscure the fact, really only one thing runs at a time. I do not
understand (rhetorically) how code gets structured to allow for high and
low priority threads.

Do you have to compile jam specifically to use gdb? I tried following
your example but get messages about no symbol table being loaded.
Post by Jack O'Quin
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) br main
Jack O'Quin
2003-04-17 17:32:24 UTC
Permalink
Post by Mark Knecht
Post by Jack O'Quin
So, I don't think this is a JACK timing problem. I think it's
failing in the GUI code. The error messages are coming out of the
create_window1() function (generated by glade), and the segfault
happens when gtk_widget_show is called. JACK only gets upset
*after* the segfault.
So you're saying the seg fault is just a complete GUI problem where the
GUI code seg faults? Interesting. I wonder why, in my case, it is
related to the frame size? I can see why you're would not be...
Doesn't make sense to me, either. Actually, none of this is making
sense right now. It would help a lot if we could get a single stable
copy of JAM that worked for everyone to use as a starting point for
further development.
Post by Mark Knecht
Do you have to compile jam specifically to use gdb? I tried
following your example but get messages about no symbol table being
loaded.
Actually, I was compiling with "make CFLAGS=-g". But, it looks like
src/Makefile.am is setting

jam_CFLAGS = -Wall -O6 -g -ffast-math

So, that should not have been necessary.

But, I did notice the same message earlier, which is why I started
explicitly passing the -g to make. I dunno, another mystery... :-)

I'm having a lot of trouble getting anywhere with JAM lately. Early
CVS versions worked reliably. But ever since those .jamrc changes
were committed I've had no luck whatsoever.

This is frustrating. For other people JAM seems to work fine. Maybe
I'm doing something incredibly stupid. I hope so.

Suggestions, anyone?
--
Jack O'Quin
Austin, Texas, USA
Mark Knecht
2003-04-17 17:46:55 UTC
Permalink
Post by Jack O'Quin
I'm having a lot of trouble getting anywhere with JAM lately. Early
CVS versions worked reliably. But ever since those .jamrc changes
were committed I've had no luck whatsoever.
This is frustrating. For other people JAM seems to work fine. Maybe
I'm doing something incredibly stupid. I hope so.
Suggestions, anyone?
Start over? Remove all traces of Jam, and download a new copy?

Yesterday, when I first tried Steve's new code for this seg fault, I
downloaded updates using just

cvs -z3 up -Pd

and tried to compile. I actually crashed the C compiler at that point,
and did get a seg fault from gcc itself. I almost sent in a report, but
first I just blew the whole thing away and started over from scrach.
That worked fine and is where I am right now.

I'll bet you've already done this...
Jack O'Quin
2003-04-17 18:10:36 UTC
Permalink
Post by Mark Knecht
Post by Jack O'Quin
Suggestions, anyone?
Start over? Remove all traces of Jam, and download a new copy?
Yesterday, when I first tried Steve's new code for this seg fault, I
downloaded updates using just
cvs -z3 up -Pd
and tried to compile. I actually crashed the C compiler at that point,
and did get a seg fault from gcc itself. I almost sent in a report, but
first I just blew the whole thing away and started over from scrach.
That worked fine and is where I am right now.
I'll bet you've already done this...
Yes, I did.

But, it doesn't hurt to ask. When I'm doing something silly, it's
often the simple questions that shake it out of me. :-)
--
Jack O'Quin
Austin, Texas, USA
Patrick Shirkey
2003-04-17 17:12:44 UTC
Permalink
Post by Jack O'Quin
So, I don't think this is a JACK timing problem. I think it's failing
in the GUI code. The error messages are coming out of the
create_window1() function (generated by glade), and the segfault
happens when gtk_widget_show is called. JACK only gets upset *after*
the segfault.
I definitely want to get rid of these messages. They seem to have
appeared after adding the EQ faders but I have no idea why. It is also
frustrating that the point referenced in the jam binary is always different.

I have no idea how to trace the binary to get the appropriate line and file.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Jack O'Quin
2003-04-17 18:07:33 UTC
Permalink
Post by Patrick Shirkey
I definitely want to get rid of these messages. They seem to have
appeared after adding the EQ faders but I have no idea why. It is also
frustrating that the point referenced in the jam binary is always different.
I have no idea how to trace the binary to get the appropriate line and file.
I started stepping through create_window1 and saw some intriguing
hints. These calls look suspicious to me...

<snip>

437 gtk_widget_set_size_request (vbox8, -2, 250);
(gdb)

(jam:10099): Gtk-CRITICAL **: file gtkwidget.c: line 4807 (gtk_widget_set_size_request): assertion `width >= -1' failed


469 gtk_widget_set_size_request (hbox14, 15, -2);
(gdb)

(jam:10099): Gtk-CRITICAL **: file gtkwidget.c: line 4808 (gtk_widget_set_size_request): assertion `height >= -1' failed

469 gtk_widget_set_size_request (hbox14, 15, -2);
(gdb)

(jam:10099): Gtk-CRITICAL **: file gtkwidget.c: line 4808 (gtk_widget_set_size_request): assertion `height >= -1' failed

482 gtk_widget_set_size_request (inmeter, 20, -2);
(gdb)

(jam:10099): Gtk-CRITICAL **: file gtkwidget.c: line 4808 (gtk_widget_set_size_request): assertion `height >= -1' failed


Since interface.c says it's generated by glade, and since some of
these calls clearly look wrong, I wonder about the version of glade
I'm using (0.6.4-5). I see a glade-2 1.1.3-8 package in Debian
unstable. I'll try to build and install that.

I don't see any glade version checking in ./configure. What version
are you using?

Also, could you send me your copy of interface.c? I'd like to try
building with that.

Regards,
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-17 19:15:01 UTC
Permalink
Post by Jack O'Quin
I started stepping through create_window1 and saw some intriguing
hints. These calls look suspicious to me...
<snip>
437 gtk_widget_set_size_request (vbox8, -2, 250);
It seems that glade is using -2 as a magic value to mean "I dont care",
however seding them to 0's removes all those anoying warnings. Nice bit of
digging.
Post by Jack O'Quin
Since interface.c says it's generated by glade, and since some of
these calls clearly look wrong, I wonder about the version of glade
I'm using (0.6.4-5). I see a glade-2 1.1.3-8 package in Debian
unstable. I'll try to build and install that.
You need glade-2 if you want to edit jam-ui.glade, but its not needed to
build.
Post by Jack O'Quin
Also, could you send me your copy of interface.c? I'd like to try
building with that.
It comes from CVS, I can check in a sed'd one though, it doesn't seem to
hurt.

- Steve
Steve Harris
2003-04-17 19:20:52 UTC
Permalink
Post by Patrick Shirkey
I definitely want to get rid of these messages. They seem to have
appeared after adding the EQ faders but I have no idea why. It is also
frustrating that the point referenced in the jam binary is always different.
OK, here is the "fixed" interface.c file, it appears to work, but dont be
too supprised if somthing odd has broken.

I can't check it into cvs as I still can get access to it form my studio
pc :(

- Steve
Patrick Shirkey
2003-04-17 19:56:45 UTC
Permalink
Post by Steve Harris
OK, here is the "fixed" interface.c file, it appears to work, but dont be
too supprised if somthing odd has broken.
I can't check it into cvs as I still can get access to it form my studio
pc :(
I've been working on getting this problem out of the way with glade. It
appears to be related to the expand and fill bools. It's a real pita but
I've managed to get it down from 45 errors to 28 in the space of 2 hours :/

If we remove them manually after generating the interface.c file we will
have to do it every time we update the gui. It may prove to be quicker
but I forsee it being forgotten occasionally. IMO it is better if we can
make glade work properly.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
Steve Harris
2003-04-17 20:21:11 UTC
Permalink
Post by Patrick Shirkey
If we remove them manually after generating the interface.c file we will
have to do it every time we update the gui. It may prove to be quicker
but I forsee it being forgotten occasionally. IMO it is better if we can
make glade work properly.
I absolutly agree. If you know the rule you could edit the .glade file
directly, its just XML.

I wasn't thinking of manually processing the .c file each time, I was
thinking of creating another .c file that we realy link against, and
giving it a dependency in interface.c in the makefile, with a sed rule.
Your way is nicer ;)

- Steve
Steve Harris
2003-04-17 19:04:02 UTC
Permalink
Post by Jack O'Quin
Post by Mark Knecht
Humm....might be a relative speed thing between your machine and mine.
This one is an Athlon XP 2600+. What's yours?
Mine is an XP 1800+. Certainly adequate for this purpose.
Yup, the machine I'm developing on is slower than that, and the machine im
mostly testing on is the same.
Post by Jack O'Quin
Post by Mark Knecht
My thought is that Jam probably links up to jack, as it's getting
started, but it still has a few jobs to do. Those jobs have to get done
before the first Jack period expires and it just doesn't make it?
I had the same suspicion, but now I don't think so. When I run jam
without gdb, I get the "adios senior jam" message from jackd (with -v)
after the segfault. But, when I run "gdb /usr/local/bin/jam", the
segfault is caught by the debugger. JACK never complains in that
case, and his "max usecs" messages remain very low.
Yeees. I think the max usecs figure is a bit cooked though. I should fix
that.
Post by Jack O'Quin
So, I don't think this is a JACK timing problem. I think it's failing
in the GUI code. The error messages are coming out of the
create_window1() function (generated by glade), and the segfault
happens when gtk_widget_show is called. JACK only gets upset *after*
the segfault.
Interesting. It definatly looked like the stuff I was seeing was jack
related. I guess this is totaly unrelated.
Post by Jack O'Quin
Post by Mark Knecht
BTW - I only see seg faults when starting the program. I have not seen
one yet when the program is running. Same for you?
For me it *never* gets past that point.
OK, dumb question, but what happens if you comment out gtk_widget_show()?

- Steve
Jack O'Quin
2003-04-18 04:21:40 UTC
Permalink
Post by Steve Harris
Interesting. It definatly looked like the stuff I was seeing was jack
related. I guess this is totaly unrelated.
Post by Jack O'Quin
Post by Mark Knecht
BTW - I only see seg faults when starting the program. I have not seen
one yet when the program is running. Same for you?
For me it *never* gets past that point.
OK, dumb question, but what happens if you comment out gtk_widget_show()?
Good suggestion, Steve. I finally tried it tonight with a recent
clean CVS tree. Those gtk messages from create_window1() are all gone
now. Big improvement.

But, it still crashes reliably...

(gdb) run
Starting program: /y/CVS/jam/src/jam
[New Thread 1024 (LWP 15466)]
Registering as jam
[New Thread 2049 (LWP 15467)]
Can't attach LWP 15467: Operation not permitted
(gdb) bt
#0 0x403ccaa1 in __linuxthreads_create_event () from /lib/libpthread.so.0
#1 0x403c7e28 in __pthread_initialize_manager () from /lib/libpthread.so.0
#2 0x403c8004 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
#3 0x403d852f in jack_start_thread (client=0x8102488) at client.c:914
#4 0x403d89dd in jack_activate (client=0x8102488) at client.c:1081
#5 0x0805c6b8 in backend_activate (argc=1, argv=0xbffffb04) at io.c:65
#6 0x0804aaf1 in main (argc=1, argv=0xbffffb04) at main.c:63

Meanwhile jackd said...

new client: jam, id = 2 type 2 @ 0x401a7000 fd = 12
gave capabilities to process 15466

All jackd timing messages are below 50 usecs and 1% usage. It's
running with -R and -p 2048.

When I tried running jackd without -R, JAM ran without crashing. JACK
stays happy (doing nothing) until I control-C the JAM process, then it
complains about timeouts and bids "adios senior jam". There's
probably no INT signal handler to shut down cleanly, so this looks
normal.

Note that I'm running with no ~/.jamrc file because that still crashes
in gtk_rc_parse(). I haven't gotten to the bottom of that one yet,
either. The simplest explanation for all my gtk trouble is that I've
somehow got a broken gtk package. But, that's another story.

I'll work on this some more tomorrow. By all means send suggestions
of more things to look for.

Regards,
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-18 09:18:01 UTC
Permalink
Post by Jack O'Quin
When I tried running jackd without -R, JAM ran without crashing. JACK
stays happy (doing nothing) until I control-C the JAM process, then it
complains about timeouts and bids "adios senior jam". There's
probably no INT signal handler to shut down cleanly, so this looks
normal.
Thats correct, but this is still wierd. I wonder if its possible to get
jam running under valdrind, it could be that theres a buffer overrun that
isn't showing up for any of us.

I can't think why not -R ing it it would stop the segfault or why GTK
would be affected by -R though.

- Steve
Jack O'Quin
2003-04-18 15:49:50 UTC
Permalink
Post by Steve Harris
Post by Jack O'Quin
When I tried running jackd without -R, JAM ran without crashing. JACK
stays happy (doing nothing) until I control-C the JAM process, then it
complains about timeouts and bids "adios senior jam". There's
probably no INT signal handler to shut down cleanly, so this looks
normal.
Thats correct, but this is still wierd. I wonder if its possible to get
jam running under valdrind, it could be that theres a buffer overrun that
isn't showing up for any of us.
I can't think why not -R ing it it would stop the segfault or why GTK
would be affected by -R though.
Well, I hate to say it, but this is starting to smell like some kind
of concurrency bug. Race conditions fail only when the timing is
"just right" to uncover the error. We may be lucky that I'm seeing it
repeatably on this system. Otherwise, it could be hard to find. :-)
Also, don't forget that stepping through things with gdb changes the
timing quite a lot.

That's why I'm so anal-retentive about simplicity and correctness in
realtime programming. The best way to debug concurrent programs is
not to "enbug" them in the first place.

Of course, I won't be confident of anything I'm seeing or saying until
I can find or build a good version of the gtk2 libraries for this
system. At the very least, we need to know what level of these
libraries JAM actually depends on, and have configure.in check it.

Regards,
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-17 18:03:28 UTC
Permalink
Post by Jack O'Quin
Post by Steve Harris
Post by Mark Knecht
Much much better. I had to go about 10 times to get this to happen,
but it did still happen with jackstart set to -p 128. With jackstart set
to -p 256 I went 20 times with no failure. With -p 64 I went 6 times and
then failed.
I am seeing segfaults at -p 1024. I don't consider that a small block
size.
OK, I wonder whats causing that... What machine is it?
Post by Jack O'Quin
Post by Steve Harris
Long term I'm planning to move to the same distribution scheme that
brutefir uses, but its a bit contraversial and it might not play well with
capabilities, which I would be very unhappy about.
Ouch! There was a long, fruitless discussion on jack-devel about
brutefir. I became convinced that the developer of brutefir has no
understanding of or interest in realtime programming, so I gave up on
him.
I dont think thats fair, his solution is perfectly workable, its just
messy.
Post by Jack O'Quin
I would be glad to implement ring queue scheduling for JAM, if you
like. One extra period will make no difference in JAM anyway. But,
flakey I/O handling will be a disaster.
Agreed, the extra latency is irrelevant, I'm not sure how you plan to do
the scheduling, but I'd be interested to hear and feel free to work on it.

- Steve
Jack O'Quin
2003-04-17 18:41:46 UTC
Permalink
Post by Steve Harris
Post by Jack O'Quin
Ouch! There was a long, fruitless discussion on jack-devel about
brutefir. I became convinced that the developer of brutefir has no
understanding of or interest in realtime programming, so I gave up on
him.
I dont think thats fair, his solution is perfectly workable, its just
messy.
Perhaps I am being unfair.

But, experience has convinced me that messy realtime concurrent
progamming solutions don't work. For that kind of work, "clever"
programmers write code that is not obviously broken, but wise
programmers insist on using an approach that is demonstrably correct.
I'm not talking about formal proofs of correctness, but there is a big
difference in mind-set.
Post by Steve Harris
Post by Jack O'Quin
I would be glad to implement ring queue scheduling for JAM, if you
like. One extra period will make no difference in JAM anyway. But,
flakey I/O handling will be a disaster.
Agreed, the extra latency is irrelevant, I'm not sure how you plan to do
the scheduling, but I'd be interested to hear and feel free to work on it.
I haven't thought about it in any detail. Right now I'm struggling
just getting anything at all to work.

The first approach that comes to mind is creating a lower-priority
realtime thread for the DSP stuff, hooked to the input and output
ports' process() handlers with ring queues.

process() input
queue buffer to DSP

DSP thread
wait until enough data available
compute transform(s)
queue buffers to output port

process() output
copy next buffer to output

The output queue starts with enough empty buffers to get things going.

I need to study the code that's already written, and think about
whether that extra DSP thread is really needed. It's probably not
absolutely required, but my intuition says the program will be more
stable if that part of the code is clearly identified and executes
separately from all the GUI events. I am convinced that it's best to
think of these realtime process() threads as if they were hardware
interrupt handlers.

I think the bypass switch should be implemented at this level. With
bypass selected the DSP thread passes its buffers through unmodified,
but still with the same queuing delay.
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-17 19:27:22 UTC
Permalink
Post by Jack O'Quin
The first approach that comes to mind is creating a lower-priority
realtime thread for the DSP stuff, hooked to the input and output
ports' process() handlers with ring queues.
process() input
queue buffer to DSP
DSP thread
wait until enough data available
compute transform(s)
queue buffers to output port
process() output
copy next buffer to output
I thought that was exactly what Brute FIR does? Taht is what I was
thinking of anyway. The nice alternative IMHO is to use a segmented FFT,
so that you compute 1/n th of the FFT each process() so that you end up
with a whole one after n process() calls, wher n is FFT size / process()
size. That relys on process() size being a power-of-two though, and FFTW
doesn't do segmented processing AFAIK.
Post by Jack O'Quin
I need to study the code that's already written, and think about
whether that extra DSP thread is really needed.
I think it is, the UI thread could go away for quite a while while it
calculates curves or whatever.
Post by Jack O'Quin
I think the bypass switch should be implemented at this level. With
bypass selected the DSP thread passes its buffers through unmodified,
but still with the same queuing delay.
Agreed.

- Steve
Jack O'Quin
2003-04-17 20:10:53 UTC
Permalink
Post by Steve Harris
Post by Jack O'Quin
The first approach that comes to mind is creating a lower-priority
realtime thread for the DSP stuff, hooked to the input and output
ports' process() handlers with ring queues.
process() input
queue buffer to DSP
DSP thread
wait until enough data available
compute transform(s)
queue buffers to output port
process() output
copy next buffer to output
I thought that was exactly what Brute FIR does?
No. He plays some kludgy games with process priorities, promoting the
priority of the DSP thread, then waiting in the output process()
handler for the DSP to finish. This allows the output to start one
JACK period earlier, reducing latency by that one buffer. It's not
worth it, in my opinion. Certainly not for JAM.

In our case it's important that JAM work reliably with small buffers,
but it's not necessary for its latency to be especially low.
Post by Steve Harris
That is what I was thinking of anyway. The nice alternative IMHO is
to use a segmented FFT, so that you compute 1/n th of the FFT each
process() so that you end up with a whole one after n process()
calls, wher n is FFT size / process() size. That relys on process()
size being a power-of-two though, and FFTW doesn't do segmented
processing AFAIK.
Given reasonably large FFT chunks, the extra overhead of running in a
separate DSP thread should be negligible.
Post by Steve Harris
Post by Jack O'Quin
I need to study the code that's already written, and think about
whether that extra DSP thread is really needed.
I think it is, the UI thread could go away for quite a while while it
calculates curves or whatever.
You're right.
--
Jack O'Quin
Austin, Texas, USA
Steve Harris
2003-04-17 20:18:52 UTC
Permalink
Post by Jack O'Quin
No. He plays some kludgy games with process priorities, promoting the
priority of the DSP thread, then waiting in the output process()
handler for the DSP to finish. This allows the output to start one
JACK period earlier, reducing latency by that one buffer. It's not
worth it, in my opinion. Certainly not for JAM.
Ah, I see. Yes, agreed. I was typically running the limiter with 0.5 - 1
second of lookahead so an extra 1000 samples isn't even noticable.

- Steve
R Parker
2003-04-16 16:43:56 UTC
Permalink
Hi,
Post by Alexandre Prokoudine
On Wed, 16 Apr 2003 23:06:08 +0900
Post by Patrick Shirkey
I am now looking at a nice brushed steel version
using the png
Post by Patrick Shirkey
from the PressGang folder.
BTW, shall we find a little place for a jar of JAM
in the main
window? :-)
Either that or a knife. Ah, for spreading Jam not
threatening users of inferior products. :)

Or, Mick Jaggers lips with Jam dripping off them. That
thought makes me ill. I digress!

ron
Post by Alexandre Prokoudine
Alexandre Prokoudine
ALT Linux Documentation Team
ATTACHMENT part 2 application/pgp-signature
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
e***@cableone.net
2003-04-16 17:09:51 UTC
Permalink
Actually, I was thinking of the standard reggae "We Be Jammin'" crew.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "R Parker" <***@yahoo.com>
Sent: Wed, 16 Apr 2003 09:43:56 -0700 (PDT)
To: "Alexandre Prokoudine" <***@altlinux.ru>, "jamin-***@lists.sourceforge.net" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit

Hi,
Post by Alexandre Prokoudine
On Wed, 16 Apr 2003 23:06:08 +0900
Post by Patrick Shirkey
I am now looking at a nice brushed steel version
using the png
Post by Patrick Shirkey
from the PressGang folder.
BTW, shall we find a little place for a jar of JAM
in the main
window? :-)
Either that or a knife. Ah, for spreading Jam not
threatening users of inferior products. :)

Or, Mick Jaggers lips with Jam dripping off them. That
thought makes me ill. I digress!

ron
Post by Alexandre Prokoudine
Alexandre Prokoudine
ALT Linux Documentation Team
ATTACHMENT part 2 application/pgp-signature
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Patrick Shirkey
2003-04-16 18:51:44 UTC
Permalink
Added small patch from Jack to make rcfile work from any dir.

Tested and works as superuser or normal. Just link/copy the .jamrc file
to your home dir.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
e***@cableone.net
2003-04-16 19:27:33 UTC
Permalink
Patrick,

I've got the EQ curve drawing (ugly as a mud fence) now. No spline yet. I couldn't use GtkCurve since it decimated the number of points that I wanted to use. I'll be working on the spline and update shortly. Should I check in the ugly curve first?

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Patrick Shirkey" <***@boosthardware.com>
Sent: Thu, 17 Apr 2003 03:51:44 +0900
To: "JAMin mailing list" <jamin-***@lists.sourceforge.net>
Subject: [Jamin] CVS commit

Added small patch from Jack to make rcfile work from any dir.

Tested and works as superuser or normal. Just link/copy the .jamrc file
to your home dir.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Patrick Shirkey
2003-04-16 19:41:09 UTC
Permalink
Post by e***@cableone.net
Patrick,
I've got the EQ curve drawing (ugly as a mud fence) now. No spline yet. I couldn't use GtkCurve since it decimated the number of points that I wanted to use. I'll be working on the spline and update shortly. Should I check in the ugly curve first?
No real hurry but I guess it won't hurt.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
R Parker
2003-04-17 21:23:28 UTC
Permalink
Hi,
Post by Jack O'Quin
stable if that part of the code is clearly
identified and executes
separately from all the GUI events. I am convinced
that it's best to
think of these realtime process() threads as if they
were hardware
interrupt handlers.
I think the bypass switch should be implemented at
this level. With
bypass selected the DSP thread passes its buffers
through unmodified,
but still with the same queuing dela
I take it a simple reroute wouldn't solve all
scenarios; jack_playback > Ardour_input. This way you
don't go to Jam's buffer's at all.

ron
Post by Jack O'Quin
Jack O'Quin
Austin, Texas, USA
-------------------------------------------------------
Post by Jack O'Quin
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Steve Harris
2003-04-17 21:59:57 UTC
Permalink
Post by R Parker
Post by Jack O'Quin
stable if that part of the code is clearly
identified and executes
separately from all the GUI events. I am convinced
that it's best to
think of these realtime process() threads as if they
were hardware
interrupt handlers.
I think the bypass switch should be implemented at
this level. With
bypass selected the DSP thread passes its buffers
through unmodified,
but still with the same queuing dela
I take it a simple reroute wouldn't solve all
scenarios; jack_playback > Ardour_input. This way you
don't go to Jam's buffer's at all.
That doesn;t solve the problem, you you reroute there will be a click and
the audio will jump in time. Dont worry, its not an enourmous problems it
just requires some though.

- Steve
Jan Depner
2003-04-18 22:42:44 UTC
Permalink
All,

I've added the "hand drawn" functionality to the EQ curve. I also
added a spline to the display of the EQ as it comes from the graphic
EQ. There is some minor ringing in the spline curve when you use
extreme settings for single sliders. I have not done anything to use
the values from the hand drawn curve. Steve, please take a look and see
what you can do with that. I have set the interval to 10 times the 1/3
octave spacing. This number is easily changed. There appears to be a
bug in the GDK/GTK package having to do with mouse events. If you press
and hold a mouse button the x,y position that is returned from the
motion event is not the same as when you press and release. The press
and hold position appears to be wrong. The best way to draw the curve
now is to press and release, move, then press right mouse to accept or
middle mouse to abort. I think these changes have been committed but I
got a strange message at the end of the commit. Somebody let me know
what you think.

Jan
Jack O'Quin
2003-04-19 06:04:18 UTC
Permalink
I spent most of today wrestling with apt-get trying to install a 2.2.x
version of libgtk2 on my Debian woody system. I had to install
XFree86 4.2 and a bunch of other stuff from sarge. It's not so woody
anymore. Fortunately, my system still runs.

Here's what I think I've discovered:

1) The ~/.jamrc initialization segfaults with libgtk2 2.0.2 and
2.0.6, but not with 2.2.1. If others agree with this conclusion, we
ought to update the dependency in the configure.in. Maybe, 2.2.0
would work, but I wasn't able to try that version.

2) I can run jam with the gtk_widget_show() call in main.c commented
out and no segfaults. JACK gets the connections and keeps running.

3) If I run the same binary in gdb and step through main.c, it
crashes in backend_activate() trying to create a JACK thread...

Breakpoint 2, jack_activate (client=0x81085b8) at client.c:1036
(gdb) [New Thread 32769 (LWP 29667)]
Can't attach LWP 29667: Operation not permitted
(gdb) bt
#0 jack_start_thread (client=0x81085b8) at client.c:871
#1 0x080620b8 in backend_activate (argc=1, argv=0xbffffaf4) at io.c:65
#2 0x0804fd4b in main (argc=1, argv=0xbffffaf4) at main.c:70

4) If I *don't* comment out the gtk_widget_show(), jam segfaults
with a messed up backtrace stack. If I use gdb to step through
*that* version, it crashes somewhere inside gtk_widget_show().

5) It's late and I'm tired, so no one should rule out the possiblity
that I'm hallucinating, or just doing something incredibly stupid.

But, to me all this spells "race condition". Worse, gdb changes the
timing enough that the results differ. My friend Al Chang used to
call that a "Heisen-bug" -- the observer modifies the experiment.

Its probably time to start reading a bunch of code. One thing
immediately jumps out at me looking at backend_activate(). I think
the order of JACK operations is wrong. If I recall correctly, it
should be "register, activate, connect" rather than "activate,
register, connect". I made that change, but things are still broken.

A patch is appended, if you want to try it. I believe I'm right about
this, but I'll check it again tomorrow.

Regards,
--
Jack O'Quin
Austin, Texas, USA
Jan Depner
2003-04-19 13:46:56 UTC
Permalink
Jack,

I haven't had this problem since I'm using 2.2.1 but I took a look at
the code in main.c. It looks to me like the
gtk_widget_show(main_window);
line should be after all of the geq setup and backend_activate. The
show function causes a ton of things to go on in GTK. Many of these
activate callbacks (expose, configure, etc). Try moving it to just
before the
gtk_main();
line and see if that alleviates some of the trouble. I've done this in
my code and the only effect I see is a slight delay while we get
jackified. Let me know what happens. If it works I'll commit it.
Also, try playing with the EQ sliders and drawing some curves and let me
know how you like that. The hand drawn stuff isn't connected to
anything but you can try it out.

Jan
Post by Jack O'Quin
I spent most of today wrestling with apt-get trying to install a 2.2.x
version of libgtk2 on my Debian woody system. I had to install
XFree86 4.2 and a bunch of other stuff from sarge. It's not so woody
anymore. Fortunately, my system still runs.
1) The ~/.jamrc initialization segfaults with libgtk2 2.0.2 and
2.0.6, but not with 2.2.1. If others agree with this conclusion, we
ought to update the dependency in the configure.in. Maybe, 2.2.0
would work, but I wasn't able to try that version.
2) I can run jam with the gtk_widget_show() call in main.c commented
out and no segfaults. JACK gets the connections and keeps running.
3) If I run the same binary in gdb and step through main.c, it
crashes in backend_activate() trying to create a JACK thread...
Breakpoint 2, jack_activate (client=0x81085b8) at client.c:1036
(gdb) [New Thread 32769 (LWP 29667)]
Can't attach LWP 29667: Operation not permitted
(gdb) bt
#0 jack_start_thread (client=0x81085b8) at client.c:871
#1 0x080620b8 in backend_activate (argc=1, argv=0xbffffaf4) at io.c:65
#2 0x0804fd4b in main (argc=1, argv=0xbffffaf4) at main.c:70
4) If I *don't* comment out the gtk_widget_show(), jam segfaults
with a messed up backtrace stack. If I use gdb to step through
*that* version, it crashes somewhere inside gtk_widget_show().
5) It's late and I'm tired, so no one should rule out the possiblity
that I'm hallucinating, or just doing something incredibly stupid.
But, to me all this spells "race condition". Worse, gdb changes the
timing enough that the results differ. My friend Al Chang used to
call that a "Heisen-bug" -- the observer modifies the experiment.
Its probably time to start reading a bunch of code. One thing
immediately jumps out at me looking at backend_activate(). I think
the order of JACK operations is wrong. If I recall correctly, it
should be "register, activate, connect" rather than "activate,
register, connect". I made that change, but things are still broken.
A patch is appended, if you want to try it. I believe I'm right about
this, but I'll check it again tomorrow.
Regards,
--
Jack O'Quin
Austin, Texas, USA
----
Index: src/io.c
===================================================================
RCS file: /cvsroot/jamin/jam/src/io.c,v
retrieving revision 1.3
diff -u -r1.3 io.c
--- src/io.c 16 Apr 2003 07:29:41 -0000 1.3
+++ src/io.c 19 Apr 2003 05:51:16 -0000
@@ -62,11 +62,6 @@
char *ioports[4];
unsigned int i;
- if (jack_activate(client)) {
- fprintf (stderr, "cannot activate client");
- exit(1);
- }
-
input_ports[0] = jack_port_register(client, "in_L",
JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
input_ports[1] = jack_port_register(client, "in_R",
@@ -85,6 +80,11 @@
ioports[1] = "alsa_pcm:capture_2";
ioports[2] = "alsa_pcm:playback_1";
ioports[3] = "alsa_pcm:playback_2";
+ }
+
+ if (jack_activate(client)) {
+ fprintf (stderr, "cannot activate client");
+ exit(1);
}
if (jack_connect(client, ioports[0], jack_port_name(input_ports[0]))) {
Jack O'Quin
2003-04-19 16:02:28 UTC
Permalink
Post by Jan Depner
I haven't had this problem since I'm using 2.2.1 but I took a look at
the code in main.c. It looks to me like the
gtk_widget_show(main_window);
line should be after all of the geq setup and backend_activate. The
show function causes a ton of things to go on in GTK. Many of these
activate callbacks (expose, configure, etc). Try moving it to just
before the
gtk_main();
line and see if that alleviates some of the trouble. I've done this in
my code and the only effect I see is a slight delay while we get
jackified. Let me know what happens. If it works I'll commit it.
Also, try playing with the EQ sliders and drawing some curves and let me
know how you like that. The hand drawn stuff isn't connected to
anything but you can try it out.
I'm using GTK 2.2.1 now, too.

I tried moving the gtk_widget_show() call as you suggest. It seems
like the right approach.

But, I still get a segfault when running JAM...

[***@sulphur] jam/ $ jam
Using jamrc file: /home/joq/.jamrc
Registering as jam
Segmentation fault

I'm not getting a core file, when running this way. Anyone know how
to activate core dumps? Since gdb is still giving bogus results, I
have no good way to look at what was going on.

If I run with gdb, I still get the same failure as before...

Breakpoint 1, backend_activate (argc=1, argv=0xbffffaf4) at io.c:65
(gdb) cont
Continuing.
[New Thread 32769 (LWP 4298)]
Can't attach LWP 4298: Operation not permitted
(gdb) bt
#0 0x403e03d9 in __linuxthreads_create_event () from /lib/libpthread.so.0
#1 0x403dc740 in __pthread_initialize_manager () from /lib/libpthread.so.0
#2 0x403dc857 in pthread_create@@GLIBC_2.1 () from /lib/libpthread.so.0
#3 0x4042952f in jack_start_thread (client=0x81085b8) at client.c:914
#4 0x404299dd in jack_activate (client=0x81085b8) at client.c:1081
#5 0x08062158 in backend_activate (argc=1, argv=0xbffffaf4) at io.c:74
#6 0x0804fd4b in main (argc=1, argv=0xbffffaf4) at main.c:67
(gdb) info threads
2 Thread 32769 (LWP 4298) Couldn't get registers: No such process.

Since the thread is created successfully when running without gdb, I
suspect a bug in gdb's handling of realtime thread creation. This
crash does *not* occur when I run jackd without -R.

But the overall segfault still happens...

(gdb) run
Starting program: /usr/local/stow/jam/bin/jam
[New Thread 16384 (LWP 4334)]
Using jamrc file: /home/joq/.jamrc
Registering as jam
[New Thread 32769 (LWP 4335)]
[New Thread 16386 (LWP 4336)]
poll interrupted
poll interrupted
poll interrupted
poll interrupted
poll interrupted
poll interrupted

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 4334)]
0x32003836 in ?? ()
(gdb) bt
#0 0x32003836 in ?? ()
Cannot access memory at address 0x31202d20

Commenting out the call to gtk_widget_show() allows the program to run
without crashing (still). I can even run it inside gdb if I start
jackd without -R.

I'm not sure what to conclude from that. Possibilities...

1) The UI is changing the timing in a way that uncovers a
concurrency problem in the backend processing.

2) There's a bug in the UI somewhere. I haven't pursued that.

3) My GTK 2.2.1 installation is somehow screwed up. I spent way too
much time fighting package dependencies and building a hybrid Debian
stable/testing system, yesterday. There were lots of changes
including a new XFree86 version, with new font handling. Then, I
installed GTK 2.2 using some .deb files I downloaded from an
unofficial GNOME 2.2 backport to Debian woody site. So, there was
lots of room for error. Plus, I don't have any other GTK 2.2
applications to try out. I didn't install GNOME 2.2, I'm still
running GNOME 1.4, which doesn't use GTK 2.2. I should probably
find something simple that does use it.

Is this stuff working for everyone but me? Or, am I just seeing an
intermittent failure more often than most? Can anyone suggest a
program that uses GTK 2.2 similarly to JAM and doesn't depend on GNOME
2.2?

I think I was right yesterday about the order of JACK operations in
backend_activate(). I spotted some code in process() that checks for
whether the ports have been registered yet. That should not be
necessary if JACK is initialized correctly. I changed that test to
use assert(3). Building with -DNDEBUG will turn on that check, which
should never fail. The patch is appended, along with a better
placement of the jack_activate() call in backend_activate(). I
recommend applying it to CVS.

If I run JAM with no UI, should I be able to get sound out from the
current version? I haven't tried that yet.

Keep on jammin'
--
Jack O'Quin
Austin, Texas, USA
Jan Depner
2003-04-19 16:06:05 UTC
Permalink
Jack,

I think you're probably right about the ordering but I understand that
stuff *not*. Let's let Steve or Patrick look at it, I'm just a GUI
geek. I can't agree more with you about gdb changing things. I could
go off on a long rant about writing self-modifying code in VAX Macro
assembler and trying to turn off debug - but I won't ;) I think that
the problem you are seeing may be timing related. I wonder what would
happen if you put a sleep call in just before the gtk_widget_show? I
think you may be the only one seeing this - at least on a consistent
basis. I get a hangup or segfault about every twentieth time I run but
if I kick it again it comes right up. No pattern to it.

Jan
Post by Jack O'Quin
Post by Jan Depner
I haven't had this problem since I'm using 2.2.1 but I took a look at
the code in main.c. It looks to me like the
gtk_widget_show(main_window);
line should be after all of the geq setup and backend_activate. The
show function causes a ton of things to go on in GTK. Many of these
activate callbacks (expose, configure, etc). Try moving it to just
before the
gtk_main();
line and see if that alleviates some of the trouble. I've done this in
my code and the only effect I see is a slight delay while we get
jackified. Let me know what happens. If it works I'll commit it.
Also, try playing with the EQ sliders and drawing some curves and let me
know how you like that. The hand drawn stuff isn't connected to
anything but you can try it out.
I'm using GTK 2.2.1 now, too.
I tried moving the gtk_widget_show() call as you suggest. It seems
like the right approach.
But, I still get a segfault when running JAM...
Using jamrc file: /home/joq/.jamrc
Registering as jam
Segmentation fault
I'm not getting a core file, when running this way. Anyone know how
to activate core dumps? Since gdb is still giving bogus results, I
have no good way to look at what was going on.
If I run with gdb, I still get the same failure as before...
Breakpoint 1, backend_activate (argc=1, argv=0xbffffaf4) at io.c:65
(gdb) cont
Continuing.
[New Thread 32769 (LWP 4298)]
Can't attach LWP 4298: Operation not permitted
(gdb) bt
#0 0x403e03d9 in __linuxthreads_create_event () from /lib/libpthread.so.0
#1 0x403dc740 in __pthread_initialize_manager () from /lib/libpthread.so.0
#3 0x4042952f in jack_start_thread (client=0x81085b8) at client.c:914
#4 0x404299dd in jack_activate (client=0x81085b8) at client.c:1081
#5 0x08062158 in backend_activate (argc=1, argv=0xbffffaf4) at io.c:74
#6 0x0804fd4b in main (argc=1, argv=0xbffffaf4) at main.c:67
(gdb) info threads
2 Thread 32769 (LWP 4298) Couldn't get registers: No such process.
Since the thread is created successfully when running without gdb, I
suspect a bug in gdb's handling of realtime thread creation. This
crash does *not* occur when I run jackd without -R.
But the overall segfault still happens...
(gdb) run
Starting program: /usr/local/stow/jam/bin/jam
[New Thread 16384 (LWP 4334)]
Using jamrc file: /home/joq/.jamrc
Registering as jam
[New Thread 32769 (LWP 4335)]
[New Thread 16386 (LWP 4336)]
poll interrupted
poll interrupted
poll interrupted
poll interrupted
poll interrupted
poll interrupted
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 4334)]
0x32003836 in ?? ()
(gdb) bt
#0 0x32003836 in ?? ()
Cannot access memory at address 0x31202d20
Commenting out the call to gtk_widget_show() allows the program to run
without crashing (still). I can even run it inside gdb if I start
jackd without -R.
I'm not sure what to conclude from that. Possibilities...
1) The UI is changing the timing in a way that uncovers a
concurrency problem in the backend processing.
2) There's a bug in the UI somewhere. I haven't pursued that.
3) My GTK 2.2.1 installation is somehow screwed up. I spent way too
much time fighting package dependencies and building a hybrid Debian
stable/testing system, yesterday. There were lots of changes
including a new XFree86 version, with new font handling. Then, I
installed GTK 2.2 using some .deb files I downloaded from an
unofficial GNOME 2.2 backport to Debian woody site. So, there was
lots of room for error. Plus, I don't have any other GTK 2.2
applications to try out. I didn't install GNOME 2.2, I'm still
running GNOME 1.4, which doesn't use GTK 2.2. I should probably
find something simple that does use it.
Is this stuff working for everyone but me? Or, am I just seeing an
intermittent failure more often than most? Can anyone suggest a
program that uses GTK 2.2 similarly to JAM and doesn't depend on GNOME
2.2?
I think I was right yesterday about the order of JACK operations in
backend_activate(). I spotted some code in process() that checks for
whether the ports have been registered yet. That should not be
necessary if JACK is initialized correctly. I changed that test to
use assert(3). Building with -DNDEBUG will turn on that check, which
should never fail. The patch is appended, along with a better
placement of the jack_activate() call in backend_activate(). I
recommend applying it to CVS.
If I run JAM with no UI, should I be able to get sound out from the
current version? I haven't tried that yet.
Keep on jammin'
--
Jack O'Quin
Austin, Texas, USA
----
Index: src/io.c
===================================================================
RCS file: /cvsroot/jamin/jam/src/io.c,v
retrieving revision 1.3
diff -u -r1.3 io.c
--- src/io.c 16 Apr 2003 07:29:41 -0000 1.3
+++ src/io.c 19 Apr 2003 15:41:09 -0000
@@ -62,11 +62,6 @@
char *ioports[4];
unsigned int i;
- if (jack_activate(client)) {
- fprintf (stderr, "cannot activate client");
- exit(1);
- }
-
input_ports[0] = jack_port_register(client, "in_L",
JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput, 0);
input_ports[1] = jack_port_register(client, "in_R",
@@ -75,6 +70,11 @@
JACK_DEFAULT_AUDIO_TYPE, JackPortIsOutput, 0);
output_ports[1] = jack_port_register(client, "out_R",
JACK_DEFAULT_AUDIO_TYPE, JackPortIsOutput, 0);
+
+ if (jack_activate(client)) {
+ fprintf (stderr, "cannot activate client");
+ exit(1);
+ }
if (argc == 5) {
for (i=0; i<4; i++) {
Index: src/process.c
===================================================================
RCS file: /cvsroot/jamin/jam/src/process.c,v
retrieving revision 1.4
diff -u -r1.4 process.c
--- src/process.c 18 Apr 2003 08:34:30 -0000 1.4
+++ src/process.c 19 Apr 2003 15:41:10 -0000
@@ -3,6 +3,7 @@
#include <stdlib.h>
#include <jack/jack.h>
#include <fftw3.h>
+#include <assert.h>
#include "process.h"
#include "compressor.h"
@@ -216,11 +217,8 @@
static unsigned int n_calc_pt = BINS - (BINS / OVER_SAMP);
jack_default_audio_sample_t *in[2], *out[2];
- /* just incase the ports aren't registered */
- if (input_ports[0] == 0 || input_ports[1] == 0) {
- return 0;
- }
- //printf("we seem to have some ports...\n");
+ /* the ports should have been registered */
+ assert(input_ports[0] && input_ports[1]);
in[0] = (jack_default_audio_sample_t *)
jack_port_get_buffer(input_ports[0], nframes);
Jack O'Quin
2003-04-19 17:35:48 UTC
Permalink
Post by Jack O'Quin
I think I was right yesterday about the order of JACK operations in
backend_activate(). I spotted some code in process() that checks for
whether the ports have been registered yet. That should not be
necessary if JACK is initialized correctly.
I changed that test to use assert(3). Building with -DNDEBUG will
turn on that check, which should never fail.
That statement was quite muddled.

Actually, compiling with -DNDEBUG, turns *off* assert() checking. We
probably don't need that, but if anyone wants to, just build with

make CFLAGS=-DNDEBUG

Regards,
--
Jack O'Quin
Austin, Texas, USA
Jan Depner
2003-04-19 15:14:25 UTC
Permalink
All,

* cleaned up the parametric EQ interface

* moved gtk_widget_show below the JACK initialization code in hopes
that it would help out with the seg faults that Jack is seeing

* added a hook in geq.c so that when the hand drawn EQ is modified it
gets called with the hand drawn data (so Steve can make magic with it)


Jan
Steve Harris
2003-04-20 23:10:53 UTC
Permalink
Added a bypass button, it doesn't work 100% right, theres not enough delay
in the bypass stream if the limiter time is high, but it will do for now.

- Steve
Jan Depner
2003-04-21 00:27:57 UTC
Permalink
* added soft and hard labels to knee label in compressors

* set EQ range to -24 to +24 (temporarily)

* added debug printout for hand-drawn EQ


Steve,

Take a look at the printout coming from geq.c when you modify the
hand-drawn curve. You can see the frequencies that are being passed
in. I'm a bit confused about the gains as they are either in the 0.0 to
1.0 range (which I use for splining) or 0.0 to 16.0. I can give you a
value for a frequency (just interpolate) but I'm not sure how to give
you a gain value. The 0.05 factor is a mystery to me. I had assumed
that passing the values to geq.c you could take those, set the faders,
and interpolate the frequencies that you would need.

Jan
Mark Knecht
2003-04-21 02:40:18 UTC
Permalink
Post by Jan Depner
* set EQ range to -24 to +24 (temporarily)
Jan,
I understand this was just a choice you made. No problem.
Jan Depner
2003-04-21 09:09:05 UTC
Permalink
Mark,

We're planning on making it user selectable. I just haven't had time
to implement it yet.

Jan
Post by Mark Knecht
Post by Jan Depner
* set EQ range to -24 to +24 (temporarily)
Jan,
I understand this was just a choice you made. No problem.
Steve Harris
2003-04-21 09:36:54 UTC
Permalink
Post by Jan Depner
Mark,
We're planning on making it user selectable. I just haven't had time
to implement it yet.
I had a quick stab, but everytime I tried to add a context menu glade
froze. It may have to be added by hand :(

- Steve
Steve Harris
2003-04-21 09:42:36 UTC
Permalink
Post by Jan Depner
Take a look at the printout coming from geq.c when you modify the
hand-drawn curve. You can see the frequencies that are being passed
in. I'm a bit confused about the gains as they are either in the 0.0 to
1.0 range (which I use for splining) or 0.0 to 16.0. I can give you a
value for a frequency (just interpolate) but I'm not sure how to give
you a gain value. The 0.05 factor is a mystery to me. I had assumed
that passing the values to geq.c you could take those, set the faders,
and interpolate the frequencies that you would need.
The faders in the gew are too coarse to fine control like the hand draw
curve, what happens is that the values in the geq faders are interpolated
to generate to 1024 bands that the EQ actually uses.

It seems silly to decimate the hand draw curve down to make the geq then
interpolate back up to generate the values for the DSP bands.

- Steve
e***@cableone.net
2003-04-21 11:24:55 UTC
Permalink
Steve,

I am passing you 310 frequencies and gains right now. I can easily change that to 1024. Is the interval between frequencies consistent in the log space? In other words, if I take the range 1.4 to 4.3 and spline the hand-drawn curve to give you 1024 points will these be the frequencies that you want? If not, can you tell me what frequencies you need? It's easy for me to generate them and then hand them to you via a call into geq.c.

I took a look at eval_comp in process.c but I can't figure out how to get a series of x,y points to plot. I really don't understand compression very well ;) Can you explain how I would call eval_comp to get a series of values for each compressor band?

Jan



-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Mon, 21 Apr 2003 10:42:36 +0100
To: "Jamin-devel" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by Jan Depner
Take a look at the printout coming from geq.c when you modify the
hand-drawn curve. You can see the frequencies that are being passed
in. I'm a bit confused about the gains as they are either in the 0.0 to
1.0 range (which I use for splining) or 0.0 to 16.0. I can give you a
value for a frequency (just interpolate) but I'm not sure how to give
you a gain value. The 0.05 factor is a mystery to me. I had assumed
that passing the values to geq.c you could take those, set the faders,
and interpolate the frequencies that you would need.
The faders in the gew are too coarse to fine control like the hand draw
curve, what happens is that the values in the geq faders are interpolated
to generate to 1024 bands that the EQ actually uses.

It seems silly to decimate the hand draw curve down to make the geq then
interpolate back up to generate the values for the DSP bands.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Steve Harris
2003-04-21 11:41:59 UTC
Permalink
Post by e***@cableone.net
Steve,
I am passing you 310 frequencies and gains right now. I can easily change that to 1024. Is the interval between frequencies consistent in the log space? In other words, if I take the range 1.4 to 4.3 and spline the hand-drawn curve to give you 1024 points will these be the frequencies that you want? If not, can you tell me what frequencies you need? It's easy for me to generate them and then hand them to you via a call into geq.c.
The frequencies are linear, the frequency of each band is
i * sample_rate / (BINS*2), for i = 0 to BINS/2-1.

sample_rate and BINS are defined in process.h

write the (linear gain) values into eq_coefs[], c.f. geq_set_gains() in
geq.c. As the numbers you get from the curve are dB's you will need to
convert them into linear gain with

linear = powf(10.0f, db * 0.05f);

We need to sort out how the EQs are going to share the coefficient array
sometime soon.
Post by e***@cableone.net
I took a look at eval_comp in process.c but I can't figure out how to get a series of x,y points to plot. I really don't understand compression very well ;) Can you explain how I would call eval_comp to get a series of values for each compressor band?
Dont worry about that one, I'l start it. I will at least get it to
spit out the appropraite numbers. I've just realised its quite messy to
calculate.

- Steve
e***@cableone.net
2003-04-21 12:19:39 UTC
Permalink
Steve,

It all falls into place now! I'll add a function to geq.c that will set the eq_coeffs values from the curve. I'm basing my interpolation now on BINS/2 - 1. I actually don't have the values in db because that's non-linear and tends to whack out the spline. We also need to move the sliders to sort of represent what we did with the hand-drawn curve just for esthetics. The way I have it implemented now is that if you use the geq faders you override the hand-drawn curve.

If you'll just get something to generate the values for the compressor curves I'll handle the graphics. I'm thinking of color coding the labels on the compressors to match the curves so it will be obvious which is which.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Mon, 21 Apr 2003 12:41:59 +0100
To: "Jamin-devel" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by e***@cableone.net
Steve,
I am passing you 310 frequencies and gains right now. I can easily change that to 1024. Is the interval between frequencies consistent in the log space? In other words, if I take the range 1.4 to 4.3 and spline the hand-drawn curve to give you 1024 points will these be the frequencies that you want? If not, can you tell me what frequencies you need? It's easy for me to generate them and then hand them to you via a call into geq.c.
The frequencies are linear, the frequency of each band is
i * sample_rate / (BINS*2), for i = 0 to BINS/2-1.

sample_rate and BINS are defined in process.h

write the (linear gain) values into eq_coefs[], c.f. geq_set_gains() in
geq.c. As the numbers you get from the curve are dB's you will need to
convert them into linear gain with

linear = powf(10.0f, db * 0.05f);

We need to sort out how the EQs are going to share the coefficient array
sometime soon.
Post by e***@cableone.net
I took a look at eval_comp in process.c but I can't figure out how to get a series of x,y points to plot. I really don't understand compression very well ;) Can you explain how I would call eval_comp to get a series of values for each compressor band?
Dont worry about that one, I'l start it. I will at least get it to
spit out the appropraite numbers. I've just realised its quite messy to
calculate.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
e***@cableone.net
2003-04-21 13:33:52 UTC
Permalink
Steve,

I've got it finished. Works like a champ (I think). You'll need to check the values for me but I think they're correct. I'm resetting eq_coefs and setting the faders to match. I've added another page to the EQ notebook. It's called EQ Options. Right now all it has is a pair of spin buttons for min and max EQ gain. It's all wired in right now. We need to be able to save our settings in some file (~/.jam? since .jamrc is taken). I don't do XML so if that's the plan I won't be much help. I won't be able to commit these changes until this afternoon.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "***@cableone.net" <***@cableone.net>
Sent: Mon, 21 Apr 2003 05:19:39 -0700
To: "Jamin-devel" <jamin-***@lists.sourceforge.net>, "Steve Harris" <***@ecs.soton.ac.uk>
Subject: RE: [Jamin] CVS commit

Steve,

It all falls into place now! I'll add a function to geq.c that will set the eq_coeffs values from the curve. I'm basing my interpolation now on BINS/2 - 1. I actually don't have the values in db because that's non-linear and tends to whack out the spline. We also need to move the sliders to sort of represent what we did with the hand-drawn curve just for esthetics. The way I have it implemented now is that if you use the geq faders you override the hand-drawn curve.

If you'll just get something to generate the values for the compressor curves I'll handle the graphics. I'm thinking of color coding the labels on the compressors to match the curves so it will be obvious which is which.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Mon, 21 Apr 2003 12:41:59 +0100
To: "Jamin-devel" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by e***@cableone.net
Steve,
I am passing you 310 frequencies and gains right now. I can easily change that to 1024. Is the interval between frequencies consistent in the log space? In other words, if I take the range 1.4 to 4.3 and spline the hand-drawn curve to give you 1024 points will these be the frequencies that you want? If not, can you tell me what frequencies you need? It's easy for me to generate them and then hand them to you via a call into geq.c.
The frequencies are linear, the frequency of each band is
i * sample_rate / (BINS*2), for i = 0 to BINS/2-1.

sample_rate and BINS are defined in process.h

write the (linear gain) values into eq_coefs[], c.f. geq_set_gains() in
geq.c. As the numbers you get from the curve are dB's you will need to
convert them into linear gain with

linear = powf(10.0f, db * 0.05f);

We need to sort out how the EQs are going to share the coefficient array
sometime soon.
Post by e***@cableone.net
I took a look at eval_comp in process.c but I can't figure out how to get a series of x,y points to plot. I really don't understand compression very well ;) Can you explain how I would call eval_comp to get a series of values for each compressor band?
Dont worry about that one, I'l start it. I will at least get it to
spit out the appropraite numbers. I've just realised its quite messy to
calculate.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
Jamin-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jamin-devel


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Steve Harris
2003-04-21 15:41:22 UTC
Permalink
Post by e***@cableone.net
I've got it finished. Works like a champ (I think). You'll need to check the values for me but I think they're correct. I'm resetting eq_coefs and setting the faders to match. I've added another page to the EQ notebook. It's called EQ Options. Right now all it has is a pair of spin buttons for min and max EQ gain. It's all wired in right now. We need to be able to save our settings in some file (~/.jam? since .jamrc is taken). I don't do XML so if that's the plan I won't be much help. I won't be able to commit these changes until this afternoon.
Great, that sounds cool. I probably wont do any more today, but I might
add the stereo width thingy.

I'm not sure about the config file stuff, I'd lean in hte direction of
XML, for the format (I can handle that), but there are some issues with
how we describe the presets.

- Steve
Alexandre Prokoudine
2003-04-21 15:45:04 UTC
Permalink
On Mon, 21 Apr 2003 16:41:22 +0100
Post by Steve Harris
I'm not sure about the config file stuff, I'd lean in hte
direction of XML, for the format (I can handle that), but there
are some issues with how we describe the presets.
Issues like... ?
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: ***@altlinux.org
Steve Harris
2003-04-21 17:02:28 UTC
Permalink
Post by Alexandre Prokoudine
Post by Steve Harris
I'm not sure about the config file stuff, I'd lean in hte
direction of XML, for the format (I can handle that), but there
are some issues with how we describe the presets.
Issues like... ?
Well, one of the things that people want to be able to do is swtich
between presets for verse/chorus type changes, you probably want to have a
chorus preset that overrides some of the features (eg. compressors but not
eq). No realtime changes should affect the limiter time, as that will
cause noise.

So, I guess we either have presets the can effect a selection of features,
or we have song presets with part sub-presets, each of whi controls a
subset of things.

- Steve
Alexandre Prokoudine
2003-04-21 17:08:21 UTC
Permalink
On Mon, 21 Apr 2003 18:02:28 +0100
On Mon, Apr 21, 2003 at 07:45:04PM +0400, Alexandre Prokoudine
Post by Alexandre Prokoudine
Post by Steve Harris
I'm not sure about the config file stuff, I'd lean in hte
direction of XML, for the format (I can handle that), but
there are some issues with how we describe the presets.
Issues like... ?
Well, one of the things that people want to be able to do is
swtich between presets for verse/chorus type changes, you probably
want to have a chorus preset that overrides some of the features
(eg. compressors but not eq). No realtime changes should affect
the limiter time, as that will cause noise.
So, I guess we either have presets the can effect a selection of
features, or we have song presets with part sub-presets, each of
whi controls a subset of things.
Can we let users switch betweeen different types of presets?
--
Alexandre Prokoudine
ALT Linux Documentation Team
JID: ***@altlinux.org
Steve Harris
2003-04-21 17:29:03 UTC
Permalink
Post by Alexandre Prokoudine
On Mon, 21 Apr 2003 18:02:28 +0100
Post by Steve Harris
Post by Alexandre Prokoudine
Post by Steve Harris
I'm not sure about the config file stuff, I'd lean in hte
direction of XML, for the format (I can handle that), but
there are some issues with how we describe the presets.
Issues like... ?
Well, one of the things that people want to be able to do is
swtich between presets for verse/chorus type changes, you probably
want to have a chorus preset that overrides some of the features
(eg. compressors but not eq). No realtime changes should affect
the limiter time, as that will cause noise.
So, I guess we either have presets the can effect a selection of
features, or we have song presets with part sub-presets, each of
whi controls a subset of things.
Can we let users switch betweeen different types of presets?
I think we have to, the question is how, and what does the UI look like.

- Steve
R Parker
2003-04-21 14:12:02 UTC
Permalink
Hi,

I just woke up and haven't gone back to view the
sreenshots you posted and I may have been doing some
dyslexic dreaming. :)

Anyway, it occured to me that the windows that
represent eq and compression settings are backwards.
Eq should have a 0 db horizontal line and the window
below the compressors is perfect for that. Compression
can be displayed within the smaller square window and
0 threshold at 0 db should present the line as we see
it in the compression window.

Well, I'll go drink some clean socks and put on some
coffee and see if I can get into the studio and
install Jam.

ron
Post by e***@cableone.net
Steve,
I've got it finished. Works like a champ (I
think). You'll need to check the values for me but
I think they're correct. I'm resetting eq_coefs and
setting the faders to match. I've added another
page to the EQ notebook. It's called EQ Options.
Right now all it has is a pair of spin buttons for
min and max EQ gain. It's all wired in right now.
We need to be able to save our settings in some file
(~/.jam? since .jamrc is taken). I don't do XML so
if that's the plan I won't be much help. I won't be
able to commit these changes until this afternoon.
Jan
-----Original Message-----
Sent: Mon, 21 Apr 2003 05:19:39 -0700
To: "Jamin-devel"
Subject: RE: [Jamin] CVS commit
Steve,
It all falls into place now! I'll add a
function to geq.c that will set the eq_coeffs values
from the curve. I'm basing my interpolation now on
BINS/2 - 1. I actually don't have the values in db
because that's non-linear and tends to whack out the
spline. We also need to move the sliders to sort of
represent what we did with the hand-drawn curve just
for esthetics. The way I have it implemented now is
that if you use the geq faders you override the
hand-drawn curve.
If you'll just get something to generate the
values for the compressor curves I'll handle the
graphics. I'm thinking of color coding the labels
on the compressors to match the curves so it will be
obvious which is which.
Jan
-----Original Message-----
Sent: Mon, 21 Apr 2003 12:41:59 +0100
To: "Jamin-devel"
Subject: Re: [Jamin] CVS commit
On Mon, Apr 21, 2003 at 04:24:55AM -0700,
Post by e***@cableone.net
Steve,
I am passing you 310 frequencies and gains
right now. I can easily change that to 1024. Is
the interval between frequencies consistent in the
log space? In other words, if I take the range 1.4
to 4.3 and spline the hand-drawn curve to give you
1024 points will these be the frequencies that you
want? If not, can you tell me what frequencies you
need? It's easy for me to generate them and then
hand them to you via a call into geq.c.
The frequencies are linear, the frequency of each
band is
i * sample_rate / (BINS*2), for i = 0 to BINS/2-1.
sample_rate and BINS are defined in process.h
write the (linear gain) values into eq_coefs[], c.f.
geq_set_gains() in
geq.c. As the numbers you get from the curve are
dB's you will need to
convert them into linear gain with
linear = powf(10.0f, db * 0.05f);
We need to sort out how the EQs are going to share
the coefficient array
sometime soon.
Post by e***@cableone.net
I took a look at eval_comp in process.c but I
can't figure out how to get a series of x,y points
to plot. I really don't understand compression very
well ;) Can you explain how I would call eval_comp
to get a series of values for each compressor band?
Dont worry about that one, I'l start it. I will at
least get it to
spit out the appropraite numbers. I've just realised
its quite messy to
calculate.
- Steve
-------------------------------------------------------
Post by e***@cableone.net
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
-------------------------------------------------------
Post by e***@cableone.net
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel
-------------------------------------------------------
Post by e***@cableone.net
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jamin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/jamin-devel


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
Steve Harris
2003-04-21 15:29:57 UTC
Permalink
Added output gain control, its from 0 to -12 at the moment, but just change
the HScale if that's wrong.

- Steve
Patrick Shirkey
2003-04-21 16:35:42 UTC
Permalink
Post by Steve Harris
Added output gain control, its from 0 to -12 at the moment, but just change
the HScale if that's wrong.
It works AFAICT but it generates gtk error messages when used.

Also the knee labels are generating error messages too. Not sure how to
fix them. I tried setting the expand/fill and height/width but that
hasn't worked.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman
e***@cableone.net
2003-04-21 15:56:44 UTC
Permalink
Cool. I'll download your latest this afternoon and then add my stuff. I've changed the EQ line to be red, double thick and added some Y grid lines. It should be waiting for you tomorrow morning.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Mon, 21 Apr 2003 16:41:22 +0100
To: "Jamin-devel" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by e***@cableone.net
I've got it finished. Works like a champ (I think). You'll need to check the values for me but I think they're correct. I'm resetting eq_coefs and setting the faders to match. I've added another page to the EQ notebook. It's called EQ Options. Right now all it has is a pair of spin buttons for min and max EQ gain. It's all wired in right now. We need to be able to save our settings in some file (~/.jam? since .jamrc is taken). I don't do XML so if that's the plan I won't be much help. I won't be able to commit these changes until this afternoon.
Great, that sounds cool. I probably wont do any more today, but I might
add the stereo width thingy.

I'm not sure about the config file stuff, I'd lean in hte direction of
XML, for the format (I can handle that), but there are some issues with
how we describe the presets.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
e***@cableone.net
2003-04-21 16:54:26 UTC
Permalink
I haven't caught up to Steve but I'm not seeing any error messages on the Knee labels. Is this when you move it? When you build it? What kind of message?

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Patrick Shirkey" <***@boosthardware.com>
Sent: Tue, 22 Apr 2003 01:35:42 +0900
To: "Steve Harris" <***@ecs.soton.ac.uk>
Cc: "JAMin mailing list" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by Steve Harris
Added output gain control, its from 0 to -12 at the moment, but just change
the HScale if that's wrong.
It works AFAICT but it generates gtk error messages when used.

Also the knee labels are generating error messages too. Not sure how to
fix them. I tried setting the expand/fill and height/width but that
hasn't worked.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
e***@cableone.net
2003-04-21 17:50:31 UTC
Permalink
I was thinking about this problem this morning. Load and save will work for presets. We can have all of the options set, save it, load it back when needed. But that doesn't address the verse/chorus thing. I would think that we could have a series of preset buttons on the main panel that would be assignable with tooltips that change as the user assigns a preset to the button. You could probably change labels on them as well. If they have no preset assigned they would be desensitized. Each assigned set of presets/configs would be loaded into memory. This would allow the user to assign saved presets to each of the preset buttons and allow them to change them rapidly as they are mastering. We could have a ~/.jam directory where we save the presets/config files.

Jan




-----Original Message-----
From: "jamin-devel-***@lists.sourceforge.net" <jamin-devel-***@lists.sourceforge.net> on behalf of "Steve Harris" <***@ecs.soton.ac.uk>
Sent: Mon, 21 Apr 2003 18:29:03 +0100
To: "jamin-***@lists.sourceforge.net" <jamin-***@lists.sourceforge.net>
Subject: Re: [Jamin] CVS commit
Post by Alexandre Prokoudine
On Mon, 21 Apr 2003 18:02:28 +0100
On Mon, Apr 21, 2003 at 07:45:04PM +0400, Alexandre Prokoudine
Post by Alexandre Prokoudine
Post by Steve Harris
I'm not sure about the config file stuff, I'd lean in hte
direction of XML, for the format (I can handle that), but
there are some issues with how we describe the presets.
Issues like... ?
Well, one of the things that people want to be able to do is
swtich between presets for verse/chorus type changes, you probably
want to have a chorus preset that overrides some of the features
(eg. compressors but not eq). No realtime changes should affect
the limiter time, as that will cause noise.
So, I guess we either have presets the can effect a selection of
features, or we have song presets with part sub-presets, each of
whi controls a subset of things.
Can we let users switch betweeen different types of presets?
I think we have to, the question is how, and what does the UI look like.

- Steve


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Loading...