Hi All,
After my Odyssey (with your support) to compile extended on amd64 I still had some basic problems with it, namely:
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended-ubuntu-jaunty-i386.debhttp://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-ubuntu-jaunty-i386.debthrows this error:
Application initialization failed: Can't find a usable init.tcl in the
following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library
/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing tricks now*, I just want to get my hands on a well working copy and make music.
Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/
I don't think anyone really likes dealing with build issues, but
someone has to do it :-D. I was thinking that we should make a pd-
extended PPA on Ubuntu's Launchpad. Then we can get i386, amd64, and
lpia builds from their servers. That means making a Pd-extended
Debian source package. Anyone want to take it on?
.hc
On Jan 3, 2010, at 12:58 PM, András Murányi wrote:
Hi All,
After my Odyssey (with your support) to compile extended on amd64 I
still had some basic problems with it, namely:
- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended- ubuntu-jaunty-i386.deb throws this error:
Application initialization failed: Can't find a usable init.tcl in
the following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./ lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package
"Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing
tricks now*, I just want to get my hands on a well working copy and
make music.Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
That sounds cool, HC. However, do you or anyone have an idea why the Jaunty i386 autobuild gives me those errors?
Andras
2010/1/4 Hans-Christoph Steiner hans@at.or.at
I don't think anyone really likes dealing with build issues, but someone has to do it :-D. I was thinking that we should make a pd-extended PPA on Ubuntu's Launchpad. Then we can get i386, amd64, and lpia builds from their servers. That means making a Pd-extended Debian source package. Anyone want to take it on?
.hc
On Jan 3, 2010, at 12:58 PM, András Murányi wrote:
Hi All,
After my Odyssey (with your support) to compile extended on amd64 I still had some basic problems with it, namely:
- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended-ubuntu-jaunty-i386.debhttp://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-ubuntu-jaunty-i386.debthrows this error:
Application initialization failed: Can't find a usable init.tcl in the
following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library
/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing tricks now*, I just want to get my hands on a well working copy and make music.
Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/ _______________________________________________ Pd-list@iem.at
I've never seen that error. My guess is that its trying to use a
different version of Tcl/Tk than it was compiled against. So like as
if your pd-extended package was compiled against Tcl 8.5.6 but you
have 8.5.0 installed.
.hc
On Jan 5, 2010, at 12:05 PM, András Murányi wrote:
That sounds cool, HC. However, do you or anyone have an idea why the
Jaunty i386 autobuild gives me those errors?Andras
2010/1/4 Hans-Christoph Steiner hans@at.or.at
I don't think anyone really likes dealing with build issues, but
someone has to do it :-D. I was thinking that we should make a pd- extended PPA on Ubuntu's Launchpad. Then we can get i386, amd64,
and lpia builds from their servers. That means making a Pd-extended
Debian source package. Anyone want to take it on?.hc
On Jan 3, 2010, at 12:58 PM, András Murányi wrote:
Hi All,
After my Odyssey (with your support) to compile extended on amd64 I
still had some basic problems with it, namely:
- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended- ubuntu-jaunty-i386.deb throws this error:
Application initialization failed: Can't find a usable init.tcl in
the following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./ lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package
"Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing
tricks now*, I just want to get my hands on a well working copy and
make music.Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/ _______________________________________________
There is no way to peace, peace is the way. -A.J. Muste
I do have Tcl 8.5.6 installed.
$ tclsh
% puts $tcl_version 8.5 % info patchlevel 8.5.6
Looks like my own Tcl is conflicting itself, as 'require' is from /usr/share/tcltk/tcl8.5/init.tcl. Meanwhile, all the other Tcl apps are working well.
My best clue so far is that in Tk 8.5 the Tk_Init() procedure has been changed, and could have something to do with this.
Andras
2010/1/5 Hans-Christoph Steiner hans@at.or.at
I've never seen that error. My guess is that its trying to use a different version of Tcl/Tk than it was compiled against. So like as if your pd-extended package was compiled against Tcl 8.5.6 but you have 8.5.0 installed.
.hc
On Jan 5, 2010, at 12:05 PM, András Murányi wrote:
That sounds cool, HC. However, do you or anyone have an idea why the Jaunty i386 autobuild gives me those errors?
Andras
2010/1/4 Hans-Christoph Steiner hans@at.or.at
I don't think anyone really likes dealing with build issues, but someone has to do it :-D. I was thinking that we should make a pd-extended PPA on Ubuntu's Launchpad. Then we can get i386, amd64, and lpia builds from their servers. That means making a Pd-extended Debian source package. Anyone want to take it on?
.hc
On Jan 3, 2010, at 12:58 PM, András Murányi wrote:
Hi All,
After my Odyssey (with your support) to compile extended on amd64 I still had some basic problems with it, namely:
- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended-ubuntu-jaunty-i386.debhttp://autobuild.puredata.info/auto-build/latest/Pd-0.42.5-extended-ubuntu-jaunty-i386.debthrows this error:
Application initialization failed: Can't find a usable init.tcl in the
following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library
/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing tricks now*, I just want to get my hands on a well working copy and make music.
Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/ _______________________________________________ Pd-list@iem.at
There is no way to peace, peace is the way. -A.J. Muste
Perhaps you have more than one Tcl/TK installed, like in /usr/local.
Try" which tclsh.
.hc
On Jan 5, 2010, at 2:56 PM, András Murányi wrote:
I do have Tcl 8.5.6 installed.
$ tclsh % puts $tcl_version 8.5 % info patchlevel 8.5.6
Looks like my own Tcl is conflicting itself, as 'require' is from / usr/share/tcltk/tcl8.5/init.tcl. Meanwhile, all the other Tcl apps
are working well.My best clue so far is that in Tk 8.5 the Tk_Init() procedure has
been changed, and could have something to do with this.Andras
2010/1/5 Hans-Christoph Steiner hans@at.or.at
I've never seen that error. My guess is that its trying to use a
different version of Tcl/Tk than it was compiled against. So like
as if your pd-extended package was compiled against Tcl 8.5.6 but
you have 8.5.0 installed..hc
On Jan 5, 2010, at 12:05 PM, András Murányi wrote:
That sounds cool, HC. However, do you or anyone have an idea why
the Jaunty i386 autobuild gives me those errors?Andras
2010/1/4 Hans-Christoph Steiner hans@at.or.at
I don't think anyone really likes dealing with build issues, but
someone has to do it :-D. I was thinking that we should make a pd- extended PPA on Ubuntu's Launchpad. Then we can get i386, amd64,
and lpia builds from their servers. That means making a Pd- extended Debian source package. Anyone want to take it on?.hc
On Jan 3, 2010, at 12:58 PM, András Murányi wrote:
Hi All,
After my Odyssey (with your support) to compile extended on amd64
I still had some basic problems with it, namely:
- Didn't like each other with the gui-rewrite
- The GUI was very slow!
...so I decided to try an i386 autobuild, but Pd-0.42.5-extended- ubuntu-jaunty-i386.deb throws this error:
Application initialization failed: Can't find a usable init.tcl in
the following directories: /usr/lib/pd/tcl/library /usr/share/tcltk/tcl8.5 ./lib/tcl8.5 ./ lib/tcl8.5 ./library ./library ./tcl8.5.0/library ./tcl8.5.0/library/usr/share/tcltk/tcl8.5/init.tcl: version conflict for package
"Tcl": have 8.5.0, need exactly 8.5.6 version conflict for package "Tcl": have 8.5.0, need exactly 8.5.6 while executing "package require -exact Tcl 8.5.6" (file "/usr/share/tcltk/tcl8.5/init.tcl" line 20) invoked from within "source /usr/share/tcltk/tcl8.5/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]"This probably means that Tcl wasn't installed properly.
Now my Tcl is 8.5.6, had even reinstalled it.
To tell you the truth, I'm not so much into compiling or doing
tricks now*, I just want to get my hands on a well working copy
and make music.Can you give me some advice? Jaunty, amd64.
Thanks, Andras
*because I got the cold :o/ _______________________________________________
There is no way to peace, peace is the way. -A.J. Muste
-- Muranyi Andras
Access to computers should be unlimited and total. - the hacker ethic
2010/1/5 Hans-Christoph Steiner hans@at.or.at
Perhaps you have more than one Tcl/TK installed, like in /usr/local. Try" which tclsh.
.hc
/usr/bin/tclsh.
Nice x86_64 (with 32-bit Pd) oddity, as i have found out: "getlibs -p tk8.5" helped the case.
Thanks, Andras
Hi List,
Does anyone implemented some echo cancellation or adaptative filtering with pd ?
Cheers, Damien.
I tried to do it with wavelet subbands. I failed miserably. Mostly, it was because I didn't get all the math the first time around. I also tried making some adaptive reverberation analysis routines, which failed due to lack of computational power. Now, I've got the math nailed down and put together a solid development computer but have not worked on the implementation lately.
Let me know if you need any help with this stuff. Perhaps we can collaborate to make something that actually works!
Chuck
On Wed, Jan 6, 2010 at 10:47 AM, Damien Henry dh@dh7.net wrote:
Hi List,
Does anyone implemented some echo cancellation or adaptative filtering with pd ?
Cheers, Damien.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Is there something/anything similar & usable for windows?
Hallo!
Does anyone implemented some echo cancellation or adaptative filtering with pd ?
We made some adaptive filter: http://grh.mur.at/software/adaptive.html But I think more people did similar and more advanced things ...
LG Georg
Hi, Thanks Georg, Patrick and Brand for your reply.
I'll try this one first : http://grh.mur.at/software/adaptive.html
On my side I've find http://www.rowetel.com/ucasterisk/oslec.html that give some explantion and also some source code : http://svn.astfin.org/software/oslec/trunk/spandsp-0.0.3/src/echo.c that may interest some of you.
Damien.
Georg Holzmann a écrit :
Hallo!
Does anyone implemented some echo cancellation or adaptative filtering with pd ?
We made some adaptive filter: http://grh.mur.at/software/adaptive.html But I think more people did similar and more advanced things ...
LG Georg
On Wed, 2010-01-06 at 19:54 +0100, Georg Holzmann wrote:
But I think more people did similar and more advanced things ...
Somebody with a deep understanding of the subject matter must be saying that. How should he know otherwise? ;-)
Seriously, I think there is only little point in pointing to how others did it better. I haven't looked at your externals, though, but I pretty sure, that they are _very_ advanced (from my perspective. me, who doesn't have a clue about adaptive filtering at all, yet). It seems to be quite an interesting subject, when looking at your webpage.
Thanks for sharing the link and the externals.
Roman
On Thu, Jan 7, 2010 at 1:18 PM, Roman Haefeli reduzierer@yahoo.de wrote:
Seriously, I think there is only little point in pointing to how others did it better. I haven't looked at your externals, though, but I pretty sure, that they are _very_ advanced (from my perspective. me, who doesn't have a clue about adaptive filtering at all, yet). It seems to be quite an interesting subject, when looking at your webpage.
Doing it better or worse is not the issue. It's how well it fits your application. There's as many adaptive filters as you've got fingers and toes, and there's quite a few different methods for the adaptation.
Questions for the application are things like: How long is the filter going to be? Are you trying to solve a system modeling problem or a system inverse problem? Acoustic echo cancellation can mean either identifying the system on the receiving end, or solving the inverse problem on the output side. Are you trying to filter a non-stationary system or make a calibrated system? How fast does the convergence need to be? How much latency is in the system? You can't realistically expect to make good adaptations if you're updating the system when the output hasn't reached its way back since the previous adaptation. Last one, and trickiest... are you trying to solve a problem that's badly conditioned?
One class of methods is gradient descent. These would be LMS, NLMS, and RLS. These typically have a burn-in period of about 10^2 to 10^4 and then a logarithmic rate of error decreases. These are better for system identification problems than inverses.
One issue here is that the gradient can be very small along certain vectors. So, your system acts as a unary operator on the signal you feed through it. It has eigenvectors and eigenvalues. For linear systems, the Riesz representation theorem applies, and we have an integral equation with a kernel that can be decomposed into eigenvector/eigenvalue pairs. For systems good for filtering, we have convolution operators whose eigenvectors are complex sines/cosines, and your eigenvalues are the spectrum of the signal in convolution.
Gradient descent methods can only converge in the bad spots at the rate of f_min/f_max (the spread of the magnitudes in the spectrum). This is generally not a problem, since these spots also make small contributions to the error. But you will have some vectors in your filter that just never converge to anything good, and depending where you start from, you will get different solutions.
Then, there's the Gauss-Newton methods. These are like magic for certain problems. Where the error function is linear-quadratic and your operator is positive definite, the filter will converge to something good in one shot. An example of this method is the block frequency domain method. It's problematic where operators are positive semi-definite--things can blow up easily and the system will be prone to noise. There are ways to regularize the 2nd derivative operator so that it's inverse is stable, but it also reduces the convergence rate.
I've got a method in the works (all except for implentation) for minimizing the product of error and filter variance that will achieve a trade-off between goodness of fit and computational expense at a uniformly fast convergence rate, regardless of the ill-behavior of the system. It's sort of halfway between gradient descent and regularized Gauss-Newton. The idea of which is to solve the system closely where the solution is good and be able to set the remaining parts of the filter arbitrarily to make the filter look good, since they can't affect the results much.
This is all much in how I just look at these problem and analyze things to death, even when it's not warranted. You might just grab an implementation that exists, integrate it correctly on the first try, and forget all about the analysis. But the interesting problems generally require a couple tries and a couple good guesses :)
Chuck