Hello devs,
I just got the CVS pd version (checked out today) and I'm wondering... should I recompile all my externs and libs?
Anyways, things seem to be working fine but I get this problem:
Consistency check failed: glist_findrtext Segmentation fault
when opening certain patches or subpatches. It seems to be happening to the patches that contain the [env] object from ggext (I just checked and recompiled it as well) but not all of them...
any ideas?
debian-ppc, 2.4.18-benh0, gcc 2.95.4
Also, I was trying (lately) to get any of the iiwu synths working... I tried the original iiwu (both versions) and I could get as far as getting it show up on canvas and load a sound font. It hangs pd after I send it a note.
[fiiwu~] makes pd exit at the instantiation time.
And, in contrary to David Casal iiwusynth is working from the console (but I compiled the 0.2.3 version).
BTW, the shadows are cool! :)
On Fri, 18 Oct 2002 12:48:03 -0500 Michal Seta mis@creazone.com wrote:
Consistency check failed: glist_findrtext Segmentation fault
when opening certain patches or subpatches. It seems to be happening to the patches that contain the [env] object from ggext (I just checked and recompiled it as well) but not all of them...
ok, first of all it was [envgen]...
and it only happens when [envgen]'s (any) outlet is connected to anything else or anything is connected to [envegen]'s inlet. It also crashes when I create a brand new [envgen] and try to connect it with anything (inlets/outlets).
This only happens in the CVS version of PD.
Hi, Michal Seta hat gesagt: // Michal Seta wrote:
I just got the CVS pd version (checked out today) and I'm wondering... should I recompile all my externs and libs?
Shouldn't be necessary (except maybe for flext externals)
Also, I was trying (lately) to get any of the iiwu synths working... I tried the original iiwu (both versions) and I could get as far as getting it show up on canvas and load a sound font. It hangs pd after I send it a note.
[fiiwu~] makes pd exit at the instantiation time.
I couldn't get the old iiwu~ working at all anymore - although I did help writing it - after I did some updating in my Debian system. That's why I wrote fiiwu~, but fiiwu~ has only been tested on my machine so far (and on Thomas Grill's). But for all flext externals in general I must say, that I didn't get very far with g++-2.9x
I did have good sucess with 3.0, though, and I'm now using g++-3.2 But anyways, it is important, that you compile the flext lib with the same compiler as the externals.
Do other flext external, for example the flext tutorial files, work?
And, in contrary to David Casal iiwusynth is working from the console (but I compiled the 0.2.3 version).
I didn't test iiwu 0.2.3 yet, I hope, that the API didn't change... I'll check this out tomorrow.
ciao
On Sat, 19 Oct 2002 01:51:11 +0200 Frank Barknecht barknech@ph-cip.uni-koeln.de wrote:
Do other flext external, for example the flext tutorial files, work?
I haven't been able to compile py/pyext but xsample~ works
But I'm checking out gcc 3.0 now...
Hi Michal,
I haven't been able to compile py/pyext but xsample~ works
Could you describe what errors you got? Compilation with 2.95 should also be possible... at least it works for me. The only known problem is when different libraries (also pd itself and libc) are compiled with different compiler versions
best greetings, Thomas
This is where it fails...
g++ -c -O6 -DPD -DFLEXT_THREADS -I/usr/local/lib/pd/src -I/usr/include/python2.1 -I/usr/local/lib/pd/flext source/modmeth.cpp -o pd-linux/modmeth.o source/modmeth.cpp: In static member function `static PyObject* py::py_send(PyObject*, PyObject*)': source/modmeth.cpp:138: `GetBound' undeclared (first use this function) source/modmeth.cpp:138: (Each undeclared identifier is reported only once for each function it appears in.) make: *** [pd-linux/modmeth.o] Error 1
this is with 3.0.4. I compiled flext with same.
And I just noticed that xsample 2.4 fails with this while 2.3 compiles fine...
g++ -c -O6 -funroll-loops -fmove-all-movables -frerun-loop-opt -finline-functions -DPD -I/usr/local/lib/pd/src -I/usr/local/lib/pd/flext main.cpp -o ../pd-linux/main.o main.cpp: In function `void lib_setup()': main.cpp:21: `xrecord' undeclared (first use this function) main.cpp:21: (Each undeclared identifier is reported only once for each function it appears in.) main.cpp:21: `FLEXT_TILDE_SETUP' undeclared (first use this function) main.cpp:22: `xplay' undeclared (first use this function) main.cpp:23: `xgroove' undeclared (first use this function) make: *** [../pd-linux/main.o] Error 1
... and 2.95 had the same problems
Could you describe what errors you got? Compilation with 2.95 should also be possible... at least it works for me. The only known problem is when different libraries (also pd itself and libc) are compiled with different compiler versions
best greetings, Thomas
regards
Hi Michal, i'm sorry for that.... this is not a compiler issue. I eliminated a function in the current flext 0.3.3 which is used in py/pyext 0.1.0.
However, there's an easy fix for that: try to change line 138 t_class **cl = (t_class **)GetBound(recv);
to
t_class **cl = (t_class **)recv->s_thing;
this should do the trick. As soon as i've finished the work on the new flext release i'll update all the various packages (and add some new)
best greetings, Thomas
----- Original Message ----- From: "Michal Seta" mis@creazone.com To: pd-dev@iem.kug.ac.at Sent: Saturday, October 19, 2002 8:24 PM Subject: Re: [PD-dev] CVS pd, fiiwu~
This is where it fails...
g++ -c -O6 -DPD -DFLEXT_THREADS -I/usr/local/lib/pd/src -I/usr/include/pyth on2.1 -I/usr/local/lib/pd/flext source/modmeth.cpp -o pd-linux/modmeth.o
source/modmeth.cpp: In static member function `static PyObject* py::py_send(PyObject*, PyObject*)': source/modmeth.cpp:138: `GetBound' undeclared (first use this function) source/modmeth.cpp:138: (Each undeclared identifier is reported only once
for
each function it appears in.) make: *** [pd-linux/modmeth.o] Error 1
this is with 3.0.4. I compiled flext with same.
And I just noticed that xsample 2.4 fails with this while 2.3 compiles
fine...
g++ -c -O6 -funroll-loops -fmove-all-movables -frerun-loop-opt -finline-func tions -DPD -I/usr/local/lib/pd/src -I/usr/local/lib/pd/flext main.cpp -o ../pd-linux/main.o
main.cpp: In function `void lib_setup()': main.cpp:21: `xrecord' undeclared (first use this function) main.cpp:21: (Each undeclared identifier is reported only once for each function it appears in.) main.cpp:21: `FLEXT_TILDE_SETUP' undeclared (first use this function) main.cpp:22: `xplay' undeclared (first use this function) main.cpp:23: `xgroove' undeclared (first use this function) make: *** [../pd-linux/main.o] Error 1
... and 2.95 had the same problems
Could you describe what errors you got? Compilation with 2.95 should
also be
possible... at least it works for me. The only known problem is when different libraries (also pd itself and
libc)
are compiled with different compiler versions
best greetings, Thomas
regards
-- ./MiS
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hi again,
And I just noticed that xsample 2.4 fails with this while 2.3 compiles
fine...
g++ -c -O6 -funroll-loops -fmove-all-movables -frerun-loop-opt -finline-func tions -DPD -I/usr/local/lib/pd/src -I/usr/local/lib/pd/flext main.cpp -o ../pd-linux/main.o
main.cpp: In function `void lib_setup()': main.cpp:21: `xrecord' undeclared (first use this function) main.cpp:21: (Each undeclared identifier is reported only once for each function it appears in.) main.cpp:21: `FLEXT_TILDE_SETUP' undeclared (first use this function) main.cpp:22: `xplay' undeclared (first use this function) main.cpp:23: `xgroove' undeclared (first use this function) make: *** [../pd-linux/main.o] Error 1
this seems to have the same reason.... i changed all *_TILDE_* notions in flext to *_DSP_* and forgot to add a compatibility definition for that one..... so: Try to change all the FLEXT_TILDE_SETUP in main.cpp to FLEXT_DSP_SETUP
flext is changing a lot these days and keeping all those packages up to date is often not that easy.....
all the best, Thomas
Hello, can someone answer the following question: Is there a real case in which a "sig~" module is needed to do a message-audio conversion? When I tried to find a simple example showing that message- and audio signals are distinguished, I found out that every audio processing module (e.g. "*~", "+~", "-~" ...) also accepts message signals.
Regards, Phil.
I don't think there's any such object, at least not in the Pd distribution. But sig~ has to stay around now for compatibility with old patches. Also, if you happen to be using the same scalar value in several inlets, it's more efficient on most machines to have a single sig~ and fan its output to all the inputs.
cheers Miller
On Sun, Oct 20, 2002 at 06:50:11PM +0200, Philip Stolz wrote:
Hello, can someone answer the following question: Is there a real case in which a "sig~" module is needed to do a message-audio conversion? When I tried to find a simple example showing that message- and audio signals are distinguished, I found out that every audio processing module (e.g. "*~", "+~", "-~" ...) also accepts message signals.
Regards, Phil.
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Sat, 19 Oct 2002, Thomas Grill wrote:
flext is changing a lot these days and keeping all those packages up to date is often not that easy.....
That is a problem I have to deal with currently, making the build system for the externals CVS. Franks externals based on flext, which are in the CVS, add a considerable amount of logistic to the build system, because I would have to check for correct versions of flext, maybe c++ ??, etc.
Wouldn't it make more sense to distribute the flext based externals together with flext, when they are so tightly bound together ?
Greetings, Guenter
Hi, guenter geiger hat gesagt: // guenter geiger wrote:
On Sat, 19 Oct 2002, Thomas Grill wrote:
flext is changing a lot these days and keeping all those packages up to date is often not that easy.....
That is a problem I have to deal with currently, making the build system for the externals CVS. Franks externals based on flext, which are in the CVS, add a considerable amount of logistic to the build system, because I would have to check for correct versions of flext, maybe c++ ??, etc.
Wouldn't it make more sense to distribute the flext based externals together with flext, when they are so tightly bound together ?
I don't think, that this would make sense: flext is a kind of library, that flext externals use, like (f)iiwu~ uses libiiwusynth and other externals use other libraries.
Also it means, that I would have to retract my externals from CVS, as they all use flext :(
But maybe flext could go into CVS as well?
I didn't have time to check out your build system yet, but of course, those are things, that make a general configuration and compilation difficult. If someone introduces an external, that uses another library, the build system must be updated, doesn't it? Add to that the whole bunch of platforms and compilers (GCC, BCC, MS, CW,...), that shall be supported, and we have a fine mess.
ciao
On Sat, 19 Oct 2002, Thomas Grill wrote:
flext is changing a lot these days and keeping all those packages up to
date
is often not that easy.....
That is a problem I have to deal with currently, making the build system for the externals CVS. Franks externals based on flext, which are in the CVS, add a considerable amount of logistic to the build system, because I would have to check for correct versions of flext, maybe c++ ??, etc.
Wouldn't it make more sense to distribute the flext based externals together with flext, when they are so tightly bound together ?
Of course this shouldn't be the case, and i think it looks worse than it is. It's also the case that there are not too many flext based externals yet (but i will add a considerable number shortly), so i'm still thinking about changing and adding things to flext - and due to the lack of in-depth documentation (mea culpa...) flext is only max'd out with my own stuff... i don't think that Frank's externals really depend on the exact version of flext. And although i totally redesigned flext for the upcoming version the API is supposed to remain stable. The real problem is the the incomplete c++ implementation of some compilers and the incompatibility of the gcc binary files. The latter seems to have stabilized with version 3.2 but only a minority of distributions has it included.
I don't want to bind flext based externals to flext itself. I have no time to manage the distribution of it all. Of course i'm considering moving my stuff to the pd cvs server but i'm still thinking of how that can be done as i have my own cvs server and want to run them in parallel.
I'm open for any opininions and suggestions on the issues.
best greetings, Thomas
On Sat, 19 Oct 2002, Frank Barknecht wrote:
Hi, Michal Seta hat gesagt: // Michal Seta wrote:
I just got the CVS pd version (checked out today) and I'm wondering... should I recompile all my externs and libs?
Shouldn't be necessary (except maybe for flext externals)
Also, I was trying (lately) to get any of the iiwu synths working... I tried the original iiwu (both versions) and I could get as far as getting it show up on canvas and load a sound font. It hangs pd after I send it a note.
[fiiwu~] makes pd exit at the instantiation time.
Hi everyone. I was the one that initially posted iiwu, which Frank updated, so I should probably pipe in here to see if anyone needs any help or clarification.
I haven't had time (as seems to be the norm) to do anything with the original version, and since Frank has updated this to use flext, does everybody agree that I should mark the original version as obsolete on my personal web page, and the pd database?
Ironically, I myself can't yet compile flext stuff due to the Red Hat compiler confusion I think. As an aside, can anybody say if the latest redhat 7.x has a compiler that works ok with this? (I don't feel like inviting the uncertainties that would come with an 8.x upgrade)
Larry
Ironically, I myself can't yet compile flext stuff due to the Red Hat compiler confusion I think.
Hi Larry, hi all, it would be helpful if you (and all having compilation problems with flext) could describe what actual problem you are having. I found that all gcc versions (>= 2.95) somehow work, although they might need some special treatment (which i want to include into the flext make procedures)
best greetings Thomas
Hi Larry, Larry Troxler hat gesagt: // Larry Troxler wrote:
Hi everyone. I was the one that initially posted iiwu, which Frank updated, so I should probably pipe in here to see if anyone needs any help or clarification.
First I want to say, I'm sorry, that I didn't mail you about my iiwu branch, yet. But I didn't thought, that fiiwu would get so much attention so soon. I didn't even announce it on pd-announce, yet. I wrote fiiwu~, because I couldn't get the old iiwu to run anymore, probably because of some libc upgrades, that I undertook.
As I'm not that skillful in pure C-programming, I tried to rewrite in it C++ with flext, just to have an iiwusynth running here again, which worked out just fine in the end and even brought some, now fixed, bugs in flext to the light of day.
I haven't had time (as seems to be the norm) to do anything with the original version, and since Frank has updated this to use flext, does everybody agree that I should mark the original version as obsolete on my personal web page, and the pd database?
I don't think, that it would be hard to update the old iiwu to libiiwusynth-0.2.2. It *should* only require a change in the iiwu_settings struct, that should be obvious from looking at the fiiwu-code. But as said above, I couldn't, and I still can't, get C-iiwu to work here. I'm absolutely puzzled, why this is so...
So, I could maintain flext-iiwu, but I'm not sure, what would be gained by this. It's true, that flext imposes an added burden on everyone, who wants to compile a flext-external. My stance on this is obvious: I write all my externals in flext now, because of the IMO much cleaner code (compare the flext-pan~ with the External-HOWTO-pan~...)
OTOH, fiiwu~ has some more functions from the iiwusynth-API implemented, for example pitch bend, and it accepts lists without the prepended "note", something I find very nice.
But nothing of this is (or *shouldn't be*) impossible with C-iiwu.
Ironically, I myself can't yet compile flext stuff due to the Red Hat compiler confusion I think. As an aside, can anybody say if the latest redhat 7.x has a compiler that works ok with this? (I don't feel like inviting the uncertainties that would come with an 8.x upgrade)
RH 8.x comes with g++-3.2, which would be the best compiler for flext, I think. But 7.x should have g++-3.0, which is, what I was using successfully a lot on flext until three weeks ago.
ciao
Hi, Michal Seta hat gesagt: // Michal Seta wrote:
And, in contrary to David Casal iiwusynth is working from the console (but I compiled the 0.2.3 version).
Where could I find the 0.2.3 version?
http://savannah.nongnu.org/ seems to only have 0.2.2...
ciao
On Sat, 19 Oct 2002 11:34:36 +0200 Frank Barknecht barknech@ph-cip.uni-koeln.de wrote:
Where could I find the 0.2.3 version?
http://savannah.nongnu.org/ seems to only have 0.2.2...
...oups... sorry. I'm ahead of myself and the rest... it's 0.2.2 that I've got...
On Fri, 18 Oct 2002, Michal Seta wrote:
Hello devs,
I just got the CVS pd version (checked out today) and I'm wondering... should I recompile all my externs and libs?
Anyways, things seem to be working fine but I get this problem:
Consistency check failed: glist_findrtext Segmentation fault
You should not need to recompile the externals, the bug in envgen you encountered might be the same one that was already reported with Yves external, and has to do with the colored patch coords. I am going to investigate and fix this problem within pd-CVS.
* Please remember, pd CVS is a very unstable version of pd, under development, so I do not recommend to use it in important situations * (yes, yes, we know that already ...)
Guenter
-
Frank Barknecht -
guenter geiger -
Larry Troxler -
Michal Seta -
Miller Puckette -
Philip Stolz -
Thomas Grill