Not a really big deal, mainly because the Postfish is of admittedly limited appeal (it's targetted at creators, not consumers ;-)
...but to get it out of my head for a bit, I declare today's last Postfish commit to consitute a prerelease of this fine app. I have to put it down for a while but it seems silly to keep something very useful hidden for no reason.
Have no freaking clue what the Postfish is? Well, here's the prerelease README:
This README file covers the 2004-05-29 pre-release of the Postfish by
Xiph.Org.
>>>> What is the Postfish?
The Postfish is a digital audio post-processing, restoration,
filtering and mixdown tool. It works as a linear audio filter, much
like a rack of analog effects. The first stage of the filter
pipeline provides a bank of configurable per-channel processing
filters for up to 32 input channels. The second stage provides
mixdown of the processed input audio into a group of up to eight
output channels. The third stage applies processing filters to the
output group post-mixdown.
The Postfish is a stream filter; feed it audio from a list of files
or input stream, and it renders audio to standard out, as well as
optionally providing a configurable audio playback monitor via a
sound device. If the input audio is being taken from files,
Postfish also provides simple forward/back/cue seeking and A-B
looping control.
>>>> What is the Postfish for?
The Postfish intends to include exactly and only the most useful
basic filters needed to produce a good mixdown from audio recorded
'in the field'. The filter set also comprises the fundamentals
needed for master mixdown in a small studio. It is not an editor;
for that reason, it's intended to be used with an audio editor, such
as Audacity.
If, for example, you've just multi-track recorded a rehearsal of
your troupe's current rock opera and the Director then appears out
of nowhere (they always do) and says "Have a mix for my review by
morning", the Postfish is all you need.
Or, as another example, you've recorded for a band who'd like to put
out a CD of the live performance... All the band FX are already in
the multi-track, so the Postfish plus Audacity is all you need.
In a studio situation, tracks usually get recorded dry, so there's
generally multiple mixdown stages of adding effects. Postfish
(obviously) does not give you a large array of instrument or
situation-specific effects and it never will (dammit). What it does
give you is the effects necessary to take the tracks from earlier
mixing and produce intermediate mixes and final masters. Of course,
if you already have $100k of analog rack... you likely won't be
using Postfish. But hey, who knows....
>>>> What effects does the Postfish include?
Declipper:
The Postfish declipper is a 'build audio from scratch'
reconstruction filter. Any section of audio exceeding a configured
amplitude threshold is marked 'lost' and the filter builds new
audio to fill the gap. In this way it can be used to repair both
digital clipping that occurred during sampling, as well as analog
clipping that may have happened at an earlier stage.
Single-band compander:
A single-band compander is used to compress, limit, expand, or gate
an input signal, thus providing basic dynamic range manipulation
abilities.
The Postfish single-band compander provides independent over and
under threshold controls for each channel, each providing expansion,
compression, attack, release, lookahead and soft-knee configuration
for three independent over, mid and under tracking filters. Each
filter may also be configured to track by peak, or track by RMS
energy.
Multi band compander:
The Postfish multi-band compander is similar to the single-band
compander above, and provides all of the same controls with an
addition: each over/under threshold is configurable by full-octave,
half-octave or third-octave bands, for up to 30 bands of independent
companding for each of 32 input channels and the group of eight
outputs.
The multi-band compander includes a global 'mid' compand slider,
like the single-band compander. This slider acquires a new use in
multi-band mode however, where it can flatten or expand the dynamic
range of an entire channel (or the entire recording) without
any artifacts.
Equalization:
30 band -60/+30dB 1/3-octave beat-less EQ per input channel and full
output group.
Deverberator:
Live recordings have a tendency to end up with too much reverb,
especially when one is forced to use ambient miking. The
deverberator dries out overly 'wet' live signals.
Reverberator:
...for adding reverb to signals that are too 'dry', especially to
even out apparent depth when mixing close miked signals (like
vocals) to an ambient-miked signal.
The Postfish provides a stereo reverb per input channel and a mono
reverb per output post-mix.
Limiting:
Simple, old-fashioned causal output hard-limiter to avoid unexpected
digital clipping on the output. Configurable by threshold, knee
depth and release speed.
Mixdown:
Postfish provides both a master attenuation and delay panel (which
places these basic sliders for all channels on one window) as well
as per-input mixdown that allows each input channel to be multiply
routed to one or all of eight output through an additional cascade
of four additional independent attenuation/delay/invert units per
input, as well also allowing each input to be mixed through a
'crossplacer'.
The crossplacer is used to place any input into a stereo [or
greater] image by altering not only the relative attenuation across
channels (the 'cross attenuate' control), but also by adjusting
phase and delay across channels (the 'cross delay' control). The
A-B slider then controls how far the input apparently images toward
the A output bank or the B output bank.
The mixdown blocks can also be configured to take as input not only
the input channel, but also each channel's left (A) or right (B)
reverb output. For example, reverb left can be mixed to the left
output, the reverb right mixed to the right channel and the original
input crossplaced somewhere between left or right. The input
placement can be altered on the fly thus apparently moving the
input's location while the impression of space the reverb creates
holds still. For even more realism, adding an additional delay of 10
ms or so to the reverb (sound travels roughly one meter in 3 ms) can
pull the original image closer without losing the impression of
reverberation in a medium-to-large hall. A reverb delay also allows
the use of a faster/tighter reverb time without losing the
the impression of size.
Of course, with eight channels, one can begin imaging/mastering for
more than just stereo...
>>>> Don't we already have several free apps that do this sort of thing?
The short/wrong answer is maybe. The complicated answer is no.
.) I needed a specific set of filters
.) I needed them in one place working together
.) I needed to hear changes I made to settings as I made them
.) I needed to be able to absolutely trust the filters would function
as expected
.) I needed it all to be convenient to use
Given my specific requirements, nothing else came close to filling
the niche and I didn't want to cobble together a 90% solution out of
multiple other apps when this functionality was the very core of
what I needed for mixdown.
Both the Postfish UI and the filter functionality are intended to be
the most usable day-to-day set, rather than sporting the maximum
number of buttons in the smallest space or more features than the
next app (or the slickest skin).
Postfish is the way it is because I need it, and I use it for the
core basics of mixing that I absolutely cannot afford to screw up.
Some filters (like the declipper and deverberator) are unique. Even
among those that aren't, Postfish as implemented deliberately sets
speed/quality tradeoff much higher than most existing apps.
The multiband compander is a case in point; other free apps do
implement this effect. To my knowledge, all use the simplest/fastest
method, operating directly on the FFT of a windowed block. An
FFT-based multicompander is fast, but the aliasing and frequency
multiplication artifacts (you eventually end up multiplying the
input by the transfer function of the window shape; most noticeably,
they tend to cause odd pitch changes in raw vocals) render them
unsuitable for professional-quality work.
>>>> What does the Postfish require?
.) Linux 2.x (ports come later) with OSS or ALSA OSS emulation
.) Libraries: FFTW3, pthreads, Gtk2
.) Gcc and gmake
.) A sound card or external USB/Firewire A/D/A
.) A video card, preferrably one with fast AGP
.) Alot of CPU. Really. As much as you can throw at it. Dual Xeon 3GHZ?
Yup, you can use all of it.
Seriously, this is a very CPU hungry app because of the
aforementioned speed/quality tradeoff. I can do simple mixdown of 8
channels to stereo with a few effects in realtime on my G3-400, but
the machine is crying. The dual Athlon 2600 keeps up much better,
but it's still possible to overwhelm it by lighting up all the
effects and feeding it enough input channels. The declipper,
especially, eats CPU on heavily damaged audio. The multiband
compander is runner up in 'absurd levels of CPU usage'.
Postfish, BTW, is designed to scale to dual CPUs. A dual
Athlon/Pentium/UltraSparc/PowerPC runs Postfish much better than a
single processor.
>>>> Why is this a pre-release?
Because it's not finished. A few things are more obvious than others:
1) The 'cue sheet' and 'settings list' panels are still
unimplemented. These are the only inactive features on the UI,
but they're right on the main panel.
2) Postfish *should* be a JACK-able app, but isn't. That too should
be done for a real release.
3) Although the whole thing is designed as a rendering engine
wrapped up in a neat async-safe library that's then used by an
asynchronous UI, the source isn't entirely arranged that way. It
should be. It will be for final release.
4) The stereo reverb code used by Postfish is Steve Harris's GPL
plate reverb from LADSPA. Although this is a solid, reliable
reverb implementation, it's also a bit thinner on final output
results than I'd like. Don't get me wrong, this reverb is
excellent code, but it places emphasis more toward 'fast' rather
than my desired 'best possible results given unlimited CPU'. I'm
evaluating other reverb implementations; this is a case where
others have achieved clearly better results than I would, and
thus I plan to use the best available to me.
5) This code is just now seeing light of day. It is probably *full*
of simple bugs. I'm confident in the audio pipeline itself (I've
hammered on it mercilessly) but there's certainly many UI
interconnection bugs left to find.
6) Everyone knows a release requires documentation. There is no
documentation.
>>>> There's no documentation!?
Not yet; good documentation requires effort and time.
That said, if read the list of effects, knew what they were, and
knew basically how to use them, you should be able to pick up the
Postfish and do useful work in a few minutes of playing around.
I took care to establish and follow conventions in the UI: If you're
using the shipped postfish-gtkrc theme, square blue buttons turn
things on. Triangular blue buttons pop configuration windows.
The grid of buttons on the right in the 'channel' frame are the
effects for the input channels. The square blue buttons turn a
specific effect on for a specific channel. A triangle pops the
configuration for that effect. Mixing controls are labelled
"Atten/Mix" in the lowest row in the "channel" panel.
Further right is the "master" panel; these controls work the same
way for effects on the output channels after mixdown.
Finally, postfish -h will tell you how to get audio in and read
audio out.
Only two things are probably impossible to figure out just from
an afternoon of playing around:
1) Output from a reverb effect in the "channel" panel is sent to a
separate internal stereo bus. The reverb has to be explicitly
mixed into the output on a 'mix' panel. When postfish starts for
the first time, the default setup mixes one side of the reverb
pair back into left or right.
2) Turning "Atten/Mix" off for any channel will mute it completely
in all input effects, not just in the mixdown (this obviously
doesn't affect output, but it also silences all the VU meters for
that input channel, and that can be disconcerting if you don't
expect it).
>>>> How do I get, build and install it?
Postfish is in Xiph.Org's Subversion repository. Get the source using:
svn co http://svn.xiph.org/trunk/postfish (http://svn.xiph.org/trunk/postfish) postfish
Edit the Makefile to select the proper 'ADD_DEF' line. LinuxPPC
users want the first, almost everyone else wants the second. It
should be self explanatory given text in the Makefile.
cd postfish
make
and as root,
make install
Happy hacking (and mixing),
Monty
TD, Xiph.Org
Wow, Monty, you've been busy! I don't even pretend to know how you could fit this in with all the other Xiph stuff. Pretty sweet though.
Wow, Monty, you've been busy! I don't even pretend to know how you could fit this in with all the other Xiph stuff. Pretty sweet though.
the Postfish has been a project I've been tinkering on for years. This isn't exactly new software, just newly in a more releasable quality :-)
Monty
I wish windows-compatible version also!!!
I wish windows-compatible version also!!!
I remember in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=18259&hl=postfish) that QuantumKnot had compiled a postfish version. But I don't know exactly if it's a win32 or linux version...
I remember in this post (http://www.hydrogenaudio.org/forums/index.php?showtopic=18259&hl=postfish) that QuantumKnot had compiled a postfish version. But I don't know exactly if it's a win32 or linux version...
He only said he would investigate. He never reported success.
You'll probably need glib-dev, gtk-dev, and fftw3-dev to compile it. I'll tell you all the dependencies when I finish building..
edit:
It looks like it won't build with gtk 2.4.1.
outpanel.o(.text+0x371): In function `outpanel_state_from_config':
: undefined reference to `GTK_OPTION_MENU'
outpanel.o(.text+0x38d): In function `outpanel_state_from_config':
: undefined reference to `GTK_OPTION_MENU'
outpanel.o(.text+0x3a9): In function `outpanel_state_from_config':
: undefined reference to `GTK_OPTION_MENU'
outpanel.o(.text+0x3c8): In function `outpanel_state_from_config':
: undefined reference to `GTK_OPTION_MENU'
outpanel.o(.text+0x3e7): In function `outpanel_state_from_config':
: undefined reference to `GTK_OPTION_MENU'
outpanel.o(.text+0x406): more undefined references to `GTK_OPTION_MENU' follow
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/kjoonlee/xiph/postfish'
make: *** [all] Error 2
edit2:
or maybe I'm doing something horribly wrong..
It looks like gtk 2.4.1 is missing the define for no reason. It was in previous releases, and the functionality isn't marked deprecated in any online GTK docs... 2.0 through 2.3 have it....
Even weirder, the define *does* exist in the GTK2.4.1 source includes. Plain old Gtk2 bug?
[edit: I'm just an idiot. See below]
Monty
Ah *ha*. The docs still say to use it.... but in the *source*, gtk_option_menu is suddenly listed as 'deprecated' as of 2.4. WTF!?
[edit: my docs say to use it because my docs were a few months old :-]
Monty
OK! I have fixed the build for 2.4.1 for the moment. Eventually I will have to replace the use of GtkOptionMenu in the output panels, but for the forseeable future, simply turning off the super-strict-no-deprecated-code defines allow things to build and function properly.
kjoonlee: you should be able to build now.
Monty
Yay! Success.
Put it somewhere in your path, then run something like:
postfish The_Corrs-I_Know_My_Love.wav > /dev/dsp
(edit: Not the best way to run it if you want to save results.)
You can run postfish -h to learn more.
Here's the ldd output:
libgtk-x11-2.0.so.0
libgdk-x11-2.0.so.0
libatk-1.0.so.0
libgdk_pixbuf-2.0.so.0
libm.so.6
libpangoxft-1.0.so.0
libpangox-1.0.so.0
libpango-1.0.so.0
libgobject-2.0.so.0
libgmodule-2.0.so.0
libdl.so.2
libglib-2.0.so.0
libpthread.so.0
libfftw3f.so.3
libc.so.6
libX11.so.6
libXrandr.so.2
libXi.so.6
libXext.so.6
libXft.so.2
libfreetype.so.6
libz.so.2
libfontconfig.so.1
libXcursor.so.1
libXrender.so.1
/lib/ld-linux.so.2
libpangoft2-1.0.so.0
libexpat.so.2
I still think this deserves an announcement in the News Submissions (which I made just now but realised instead it was in here) since it wasn't that obvious Monty would announce it in the Digital A/V News forum and it is an audio tool after all.
OK, time to checkout
I've tried compiling the Postfish. But I got this compile error:
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/xiphsvn/postfish'
make: *** [all] Error 2
Exit 2
I'm using GTK 2.4.0.
I've tried compiling the Postfish. But I got this compile error:
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/xiphsvn/postfish'
make: *** [all] Error 2
Exit 2
I'm using GTK 2.4.0.
Thanks for the report...
This is an internal function in the gtk_check_button class I'm subclassing from. It exists in Gtk 2.2 and 2.4.1, but is missing in 2.4.0. So a quick gtk upgrade will correct this.
However, looking at this strategically it's obviously an unsafe call to be relying upon (if the leading underscore didn't give that away ;-). The good news is it's just a small wrapper around a few supported/exported functions, so I'll move the wrapper up into windowbutton.c
Monty
This was quick a fix, and I committed it.
Monty
Excellent. It now builds perfectly in 2.4.0 now. But then, I downloaded 2.4.1 for nothing
Anyway, thanks Monty
hmm....Here is a snapshot of it. See the triangular buttons. Looks like they've been offset a bit. Cosmetic issue I guess
Postfish Screenshot (http://www.rarewares.org/quantumknot/postfish.png)
Looks very slick indeed
EDIT: Changed image to URL since the pic is a bit big.
hmm....Here is a snapshot of it. See the triangular buttons. Looks like they've been offset a bit. Cosmetic issue I guess :)
Looks very slick indeed :cool:
Not sure what you mean by 'offset' as the pic you posted won't come up here. If you mean 'the window poppers overlap the activity buttons', that's intentional. When you have 16 input channels, width becomes an issue, thus the horizontal compression of the Channel and Master panels.
[edit: Whoops! There it is! :-) Yes, that's all as its supposed to be. Well, except the monospace font for number readouts is supposed to be 6x13 or smaller for optimal formatting... but libpango makes gettting the desired monospace font really hard]
Monty
Oh I understand. Looks like rarewares.org is having problems again.
Another point for people who might be interested in is that they should compile the single precision part of fftw. My existing fftw was compiled in double precision (since I needed that for SSE2) and the Makefile couldn't find fftwf-wisdom. So I made a single precision compile of fftw as well
Oh I understand. Looks like rarewares.org is having problems again.
Another point for people who might be interested in is that they should compile the single precision part of fftw. My existing fftw was compiled in double precision (since I needed that for SSE2) and the Makefile couldn't find fftwf-wisdom. So I made a single precision compile of fftw as well :)
Yes, single precision fftw is required. BTW, I had terrible trouble with FFTW3 compiled with SSE support: mostly it crashes without doing anything useful (and yes, my processor has SSE support). This is an issue with FFTW3, not Postfish and I can't seem to do much about it; I had to use the stock debian FFTW3 without vector unit support.
Also, I don't know how Linux sets up SSE and what default exception mode it uses. I know that Linux sets up Altivec in 'useless' mode so that any denormalized math just crashes the program. *That* I found an ugly but working fix for (see the top of main.c), so Altivec is OK. Stupid thing is that GCC's C99 support is supposed to be able to set this all up through fedisableexcept() except GCC only implements the functionality for the core FPU and not for the vector unit (ie, Altivec or SSE) so there's no portable way to put the vector unit in a known, sane state on Linux.
If you get your FFTW3 with SSE to work properly... or have an answer to any of those unkowns... let me know :-)
Monty
Oh I understand. Looks like rarewares.org is having problems again.
Another point for people who might be interested in is that they should compile the single precision part of fftw. My existing fftw was compiled in double precision (since I needed that for SSE2) and the Makefile couldn't find fftwf-wisdom. So I made a single precision compile of fftw as well :)
Yes, single precision fftw is required (debian at least installs both single and double precision version). BTW, I had terrible trouble with FFTW3 compiled with SSE support: mostly it crashes without doing anything useful (and yes, my processor has SSE support). This is an issue with FFTW3, not Postfish and I can't seem to do much about it; I had to use the stock debian FFTW3 without vector unit support. It appeared to be a simple logic problem in FFTW3 plan generation; the SSE itself is fine, the segfaults happen before that.
FFTW3 with altivec is fine, and Postfish does properly handle Altivec exception setup via some ugly but workable gcc-intrinsics-based fixes (see the top of main.c), so Altivec is OK. Stupid thing is that GCC's C99 support is supposed to be able to set this all up through fedisableexcept() except GCC only implements the functionality for the core FPU and not for the vector unit (ie, Altivec or SSE) so there's no portable way to put the vector unit in a known, sane state on Linux.
If you get your FFTW3 with SSE to work properly... let me know :-) I do know that Linux does set up SSE to mask exceptions by default (unlike Altivec), so that part is fine.
Monty
The only word that comes to mind, regarding the interface, as I play with this is: slick The spinning fish and the smooth graphical bars moving....very nice (and slick) .
I opened up the equalizer as I was playing a file and tried to move the sliders but I couldn't move any. They seem to be stuck. Same for any other slider control. They highlight as I move my mouse over them, but I can't seem to drag them.
I opened up the equalizer as I was playing a file and tried to move the sliders but I couldn't move any. They seem to be stuck. Same for any other slider control. They highlight as I move my mouse over them, but I can't seem to drag them.
Perhaps you need that gtk 2.4.1 upgrade after all? ;-)
Actually, when you try to click/drag, is the focus moved? It appears mouse button presses are disappearing. That's weird; the widget uses very correct event hooks and is only aware of what GTK tells it.... The fact that the prelight appears means it's getting mouse enter, so it's odd that button press would get swallowed.
Monty
I guess that's the story of my life: things that work for most never work for moi
Here is the exact behaviour I get. I move my mouse over a slider and it turns light blue. When I click on the slider, it goes dark. But the moment I drag it, it lights up to light blue again.
I think it's time to upgrade to 2.4.1 (might as well since I downloaded the source). Things can only get better (or I hope so anyway).
On my side, it looks like modifying the EQ settings in real time takes up huge amounts of CPU cycles. It's easy to move the sliders when playback has been paused, but it takes patience to move the sliders in "real time."
edit: Oops, mistake on my side. It isn't so slow when I'm just modifying the EQ.
I guess that's the story of my life: things that work for most never work for moi ;)
Here is the exact behaviour I get. I move my mouse over a slider and it turns light blue. When I click on the slider, it goes dark. But the moment I drag it, it lights up to light blue again.
I think it's time to upgrade to 2.4.1 (might as well since I downloaded the source). Things can only get better (or I hope so anyway). ;)
Eh, not so odd for a brand new app that's only seen a few machines.
Also, that verifies that the mouse button events are not disappearing. Thanks for the clarification. I'll grab 2.4.0 and see what's up.
BTW is the 2.4.0 from a package or built from source?
Monty
QuantomKnot: I just ran Postfish against a source build of Gtk 2.4.0 here and everything worked properly.
Did the 2.4.1 upgrade fix anything for you? Does a debug build show any odd warnings or errors? Are there perhaps more than one mismatched install of gtk on your box?
"Hmm"
Monty
QuantumKnot:
Having traced through the multibar event handling code, the only likely way the slider dragging could be malfunctioning is if GTK is calling the wrong event callback.
If you're interested in running this in a debugger to see what's going on (I'd be interested to know), build postfish with:
make clean ; make debug
then run it in GDB, interrupt execution with C-c C-c, and then set breakpoints for the following functions:
multibar.c:multibar_focus
multibar.c:button_release
multibar.c:multibar_leave
multibar.c:multibar_motion
multibar.c:unfocus
then, continue execution and try to drag a slider. The button_press callback isn't breakpointed (because we know it's working), so the first callback that fires *should* be multibar_motion. My guess is the one that fires is one of the others and that likely indicates a problem with linking against GTK; the callbacks are ending up at the wrong addresses. If the wrong one *does* fire, does the motion callback get called eventually?
Are any other Mandrake users having the same problem? There's a good liklihood this is just due to a weird mis-build (either of Postfish or Gtk2 itself) against the wrong headers. It wouldn't show up in other Gtk apps unless the app in question is implementing custom widget classes.
This is just an initial direction to get the debugging ball rolling. Or... you could give me a shell with X forwarding :-)
Monty
I updated to 2.4.1 and still no success. But I found out the problem. I changed to Gnome (2.6) and the sliders work perfectly!! But they don't work in KDE, which is what I use normally. gtk 2.4.0 came packaged with Fedora Core 2.
But I'll give the debugging a try (in KDE) and let you know how it goes.
EDIT: I run it through gdb and set the breakpoints. The instant my mouse enters the window, the breakpoint at multibar_motion. When I keep continuing, it keeps triggering on the same function. After a few goes, it goes to the breakpoint at multibar_leave. Now if I remove these two breakpoints and try to click on the slider, the slider doesn't drag. Once I release the mouse click, the breakpoint at button_release triggers.
I guess there is something wrong with using gtk apps in KDE. Can anyone running Postfish in KDE confirm this problem with sliders not dragging?
I updated to 2.4.1 and still no success. But I found out the problem. I changed to Gnome (2.6) and the sliders work perfectly!! But they don't work in KDE, which is what I use normally. gtk 2.4.0 came packaged with Fedora Core 2.
But I'll give the debugging a try (in KDE) and let you know how it goes.
EDIT: I run it through gdb and set the breakpoints. The instant my mouse enters the window, the breakpoint at multibar_motion. When I keep continuing, it keeps triggering on the same function. After a few goes, it goes to the breakpoint at multibar_leave. Now if I remove these two breakpoints and try to click on the slider, the slider doesn't drag. Once I release the mouse click, the breakpoint at button_release triggers.
I guess there is something wrong with using gtk apps in KDE. Can anyone running Postfish in KDE confirm this problem with sliders not dragging?
QuantunKnot:
Interesting and thanks for narrowing it down further. So, if you run all the above breakpoints except multibar_motion, what is the order of triggering? You mention that 'multibar_leave' triggers at some point while you are still in the multibar button? Does the multibar_leave trigger during the drag attempt?
Perhaps KDE's windowmanager is delivering mouse attempts in a radically different order/behavior from the others.
Monty
QuantunKnot:
Interesting and thanks for narrowing it down further. So, if you run all the above breakpoints except multibar_motion, what is the order of triggering? You mention that 'multibar_leave' triggers at some point while you are still in the multibar button? Does the multibar_leave trigger during the drag attempt?
Perhaps KDE's windowmanager is delivering mouse attempts in a radically different order/behavior from the others.
Monty
Yes, I removed the breakpoint at multibar_motion because it kept triggering and I couldn't even move my mouse into the Postfish window without it triggering, let alone trying to drag a slider. After a few cont's, multibar_leave triggers. Once I remove the one for multibar_motion, the multibar_leave keeps triggering. Once I remove that breakpoint, then nothing triggers anymore and I can try clicking on some things in Postfish. I can click on any button or checkbox and nothing triggers a breakpoint. When I click on the slider and hold down the mouse, nothing triggers. I drag it but it doesn't work (and nothing triggers as well). At the instant I release my mouse button, the breakpoint at button_release triggers.
hmm....Hope this helps.
I'll try this process in GNOME as well to see what is supposed to happen. Regarding KDE, I run quite a few gtk programs and they seem to function ok in KDE.
EDIT: In GNOME, multibar_leave and multibar_motion do most of the triggering. Removing those, when I click and drag a slider, it drags and nothing triggers. Once I release my mouse, button_release triggers. When I continue, then unfocus triggers.
OK, I was able to reproduce the behavior myself. The problem is a click-to-focus WM that doesn't use a strict event ordering. This is perfectly legal behavior, I just hadn't seen it yet, and it broke the code.
Bug is mine, a patch is coming.
Monty
Patch completed. Our SVN is down right now, I'll commit in the morning.
For now, grab an updated source tarball from http://www.mit.edu/afs/athena/user/x/i/xip...ix-20040531.tgz (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/postfish-kde-fix-20040531.tgz)
Thanks to QuantumKnot and Vektor for this patch.
Monty
I tried to compile, I got this error back again.
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/svntest/postfish'
make: *** [all] Error 2
Exit 2
EDIT: Anyway, I took the windowbutton.c from my previous Postfish and it compiles now And now the sliders work in KDE!! *does happy dance*
Thanks Monty.
I tried to compile, I got this error back again.
windowbutton.o(.text+0x157): In function `windowbutton_draw_indicator':
: undefined reference to `_gtk_check_button_get_props'
collect2: ld returned 1 exit status
make[1]: *** [target] Error 1
make[1]: Leaving directory `/home/stephen/svntest/postfish'
make: *** [all] Error 2
Exit 2
EDIT: Anyway, I took the windowbutton.c from my previous Postfish and it compiles now :) And now the sliders work in KDE!! *does happy dance*
Thanks Monty. :)
Ha, oops! I had actually checked that the two dev machines were up to date w.r.t SVN, but I guess I missed.
Also, I found a two more cosmetic bugs, so that too will go into SVN when Mofish is back tomorrow (I forgot today was a holiday; the colo isn't staffed on holidays)
Monty
Here is something new I found out. It seems when you quit by pressing the close button on the Postfish window, it spits out these errors:
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `Multibar'
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkToggleButton'
(postfish:18904): Gtk-CRITICAL **: file gtktogglebutton.c: line 326 (gtk_toggle_button_get_active): assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkEntry'
(postfish:18904): Gtk-CRITICAL **: file gtkentry.c: line 3699 (gtk_entry_get_text): assertion `GTK_IS_ENTRY (entry)' failed
Trapped signal 11; saving state and exiting!
This signal almost certainly indicates a bug in the Postfish;
If this version of Postfish is newer than a few months old,
please email a detailed report of the crash along with
processor type, OS version, FFTW3 version, and as much
information as possible about what caused the crash. The best
possible report will outline the exact steps needed to
reproduce the error, ensuring that we at Xiph can fix the
bug as quickly as possible.
-- monty@xiph.org, Postfish revision 6781 2004-05-29 11:53:59Z
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `Multibar'
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkToggleButton'
(postfish:18904): Gtk-CRITICAL **: file gtktogglebutton.c: line 326 (gtk_toggle_button_get_active): assertion `GTK_IS_TOGGLE_BUTTON (toggle_button)' failed
(postfish:18904): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GtkEntry'
(postfish:18904): Gtk-CRITICAL **: file gtkentry.c: line 3699 (gtk_entry_get_text): assertion `GTK_IS_ENTRY (entry)' failed
Segmentation fault
Exit 139
It doesn't do this when you press the 'Quit' button.
I have a couple of questions: Does it exist a link for a stable windows compile,
and have this "postfish" tool, any to do with Sascha Eversmeier at http://www.digitalfishphones.com (http://www.digitalfishphones.com). There is similarity in both effects and GUI style,
(endorphin), beside the name "the fish fillets". This postfish "plugin" sounds like it will be the greatest audio tool this year, and it`s still june.
I have a couple of questions: Does it exist a link for a stable windows compile,
and have this "postfish" tool, any to do with Sascha Eversmeier at http://www.digitalfishphones.com (http://www.digitalfishphones.com). There is similarity in both effects and GUI style,
(endorphin), beside the name "the fish fillets". This postfish "plugin" sounds like it will be the greatest audio tool this year, and it`s still june.
There is no Postfish for Windows yet. It's a Linux application for the time being.
As for 'DigitalFishPhones', this seems to be a complete coincidence (I had not known about it before; the logos are very cute). The applications do not appear to be very similar, although they're both audio filters. I'm not sure why you think the GUIs are similar :-)
(Another odd coincidence; Sascha Eversmeier and I are the same age as well. How very strange!)
In any case, the spinning fish now used by Xiph.Org has been a personal logo for about twelve years (and I used an earlier version of the fish since high-school). My computer naming scheme is fish-related and xiph.org itself is named after a fish. I don't actually have any real fish.
The Postfish tool actually began about two and a half years ago and was always named 'Postfish'. 'Post' meaning 'after' (it's for processing audio after recording llive performances) and 'fish' meaning 'fish'. (1)
I hope that clarifies things.
Monty
(1) based on a joke formula pioneered by Dave Barry
Even more edits!
The bug was actually, in the end, an out-of-order shutdown.
I can't save out UI state if the UI has already disappeared :-)
Patched tarball at http://www.mit.edu/afs/athena/user/x/i/xip...es-20040601.tgz (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/postfish-fixes-20040601.tgz)
That work for ya?
Monty
[hooray for finding all the predicted UI interconnect bugs!]
Even more edits!
The bug was actually, in the end, an out-of-order shutdown.
I can't save out UI state if the UI has already disappeared :-)
Patched tarball at http://www.mit.edu/afs/athena/user/x/i/xip...es-20040601.tgz (http://www.mit.edu/afs/athena/user/x/i/xiphmont/Public/postfish-fixes-20040601.tgz)
That work for ya?
Monty
[hooray for finding all the predicted UI interconnect bugs!]
Great job. Now the interface seems to be pretty much bug-free. Will keep my eyes out as I keep playing with it.
You can go back to OggFile now or else you might get a lot of shouting
Great job. Now the interface seems to be pretty much bug-free. Will keep my eyes out as I keep playing with it.
You can go back to OggFile now or else you might get a lot of shouting :lol: ;)
Heh, I've been working on Oggfile, these have been five minute fixes once you told me the bug was there with enough details :-)
I need to add a patch to prevent the Bessel filters in the companders from denormalizing, then I'll stick it all in SVN.
Monty