i don't know if it was discussed here before, but i'd like to use the percolate externals on a linux machine. has anyone been able to compile it?
Tim mailto:TimBlechmann@gmx.net ICQ: 96771783 http://www.nyds-exp-discogs.tk -- The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" Jack Kerouac
Hi, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
i don't know if it was discussed here before, but i'd like to use the percolate externals on a linux machine. has anyone been able to compile it?
Olaf Matthes did port some of them to Pd, see http://www.akustische-kunst.org/puredata/. I did manage to compile some of these in Linux here, but not all and then I stopped working on it.
I see one problem with these: Percolate, GGEE and some externals by Yves D. all port STK to Pd. Maybe there should be a combined effort, to avoid this duplicate work. In that case, one maybe wants to do a PerColate without the STK objects?
Frank Barknecht _ ______footils.org__
Hi,
some people were independently reporting success in porting some of the objects to linux but nowbody ported them all... (and I still don't have a Linux box because there are no Linux drivers for the motu 828)
Frank Barknecht schrieb:
I see one problem with these: Percolate, GGEE and some externals by Yves D. all port STK to Pd. Maybe there should be a combined effort, to avoid this duplicate work. In that case, one maybe wants to do a PerColate without the STK objects?
My goal was to completely port PeRColate, regardless what other STK based objects already were available. I only excluded objects we already have as core Pd objects. In the end I even ported the video stuff (which is now available as objects for Framestein). At least on Win the two other ways of getting parts of STK into Pd don't work (aren't ported yet), as far as I know. Anyway, I really would like to support someone who wants to port PeRColate to Linux. Maybe I can take this opportunity to learn how to write Linux compatible code.... I would probably try a OS X port if can get hands on a OS X machine again.
Olaf
Olaf Matthes wrote:
Hi,
some people were independently reporting success in porting some of the objects to linux but nowbody ported them all... (and I still don't have a Linux box because there are no Linux drivers for the motu 828)
Well if you are interested in Linux then you should get a new device as MOTU are not moving quickly with the technical details. It's a pity but no one can force them to come to the party.
On Thu, 21 Nov 2002, Olaf Matthes wrote:
At least on Win the two other ways of getting parts of STK into Pd don't work (aren't ported yet), as far as I know.
AFAIK the only missing part was compilation (both, the additional pd code and the stk objects are already cross-platform). I stopped developping the STK objects because I thought that they will be replaced soon by other libraries.
Guenter
Anyway, I really would like to support someone who wants to port PeRColate to Linux. Maybe I can take this opportunity to learn how to write Linux compatible code.... I would probably try a OS X port if can get hands on a OS X machine again.
Olaf
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi, Olaf Matthes hat gesagt: // Olaf Matthes wrote:
some people were independently reporting success in porting some of the objects to linux but nowbody ported them all...
This is my problem as well: I cannot build the whole library, but the single externals often don't load. This surely is something simple, so my developer question is: What needs to be changed to, say, scrub~.c to make it standalone? I never wrote a library of externals so it is not clear to me: What is the difference inside the sources between a standalone external and one designed for a library?
My goal was to completely port PeRColate, regardless what other STK based objects already were available. I only excluded objects we already have as core Pd objects. In the end I even ported the video stuff
This sounds very reasonable.
At least on Win the two other ways of getting parts of STK into Pd don't work (aren't ported yet), as far as I know. Anyway, I really would like to support someone who wants to port PeRColate to Linux. Maybe I can take this opportunity to learn how to write Linux compatible code.... I would probably try a OS X port if can get hands on a OS X machine again.
Actually I don't think, that you have a lot of incompatible code in it. For example scrubber (which I tested again now) builds nearly out of the box. I only had to change an "int i" to an "unsigned int i" in scrub_new(void) to make the compiler happy, but that is not Linux specific at all and it would be a problem, if the Makefile wouldn't treat warnings as errors ("-Werror")
I think, it would help to have at least some externals from the library working, and fix the rest later.
Frank Barknecht _ ______footils.org__
Frank Barknecht schrieb:
This is my problem as well: I cannot build the whole library, but the single externals often don't load. This surely is something simple, so my developer question is: What needs to be changed to, say, scrub~.c to make it standalone? I never wrote a library of externals so it is not clear to me: What is the difference inside the sources between a standalone external and one designed for a library?
There are no differences at all! You can compile any external as a standalone one or as part of a library. The library is just a 'wrapper' that calls all the setup routines from the single objects (and combines the compiled code into one single binary). Most objects in PeRColate could easily be compiled as stand alone externals because they just consist of one *.c file. Only the STK based objects need to be linked with stk.c. One problem arises with "gQ" because Pd's object loader seems not to be case sensitive. Typing "gQ" in an object box fails because Pd attemts to load the file gq.dll and not gQ.dll...
I've uploaded a version 0.7b of PeRColate with some minor bugfixes. It also contains a new makefile for windows which demonstrates how PeRColate could be built without using the VC++ workspace. This is the version that could be used as a basis for a Linux port....
Olaf
PS: find it at http://www.akustische-kunst.org/puredata/percolate/ (sources only...)
Hi.
Any reason for sekere~, shaker~ etc. not being ported to PD?
Anyway I'm converting them.
Maurizio Umberto Puxeddu.
On Fri, 2002-11-22 at 00:50, Olaf Matthes wrote:
Frank Barknecht schrieb:
This is my problem as well: I cannot build the whole library, but the single externals often don't load. This surely is something simple, so my developer question is: What needs to be changed to, say, scrub~.c to make it standalone? I never wrote a library of externals so it is not clear to me: What is the difference inside the sources between a standalone external and one designed for a library?
There are no differences at all! You can compile any external as a standalone one or as part of a library. The library is just a 'wrapper' that calls all the setup routines from the single objects (and combines the compiled code into one single binary). Most objects in PeRColate could easily be compiled as stand alone externals because they just consist of one *.c file. Only the STK based objects need to be linked with stk.c. One problem arises with "gQ" because Pd's object loader seems not to be case sensitive. Typing "gQ" in an object box fails because Pd attemts to load the file gq.dll and not gQ.dll...
I've uploaded a version 0.7b of PeRColate with some minor bugfixes. It also contains a new makefile for windows which demonstrates how PeRColate could be built without using the VC++ workspace. This is the version that could be used as a basis for a Linux port....
Olaf
PS: find it at http://www.akustische-kunst.org/puredata/percolate/ (sources only...)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Here
http://agnula.org/~maurizio/PeRColate0.07b-linuxtoo.tar.gz
is a version of percolate 0.07b for PD adapted to Linux. It has not been tested but I compiled everything. Binaries (compiled on a RH8.0/Intel) are included. If you want rebuild them go into
PeRColate-source
and
make clean make pd_linux
If you test it please report bugs to me. I'll clean up the sources and test the objects this weekend.
Regards,
Maurizio Umberto Puxeddu.
On Fri, 2002-11-22 at 00:50, Olaf Matthes wrote:
Frank Barknecht schrieb:
This is my problem as well: I cannot build the whole library, but the single externals often don't load. This surely is something simple, so my developer question is: What needs to be changed to, say, scrub~.c to make it standalone? I never wrote a library of externals so it is not clear to me: What is the difference inside the sources between a standalone external and one designed for a library?
There are no differences at all! You can compile any external as a standalone one or as part of a library. The library is just a 'wrapper' that calls all the setup routines from the single objects (and combines the compiled code into one single binary). Most objects in PeRColate could easily be compiled as stand alone externals because they just consist of one *.c file. Only the STK based objects need to be linked with stk.c. One problem arises with "gQ" because Pd's object loader seems not to be case sensitive. Typing "gQ" in an object box fails because Pd attemts to load the file gq.dll and not gQ.dll...
I've uploaded a version 0.7b of PeRColate with some minor bugfixes. It also contains a new makefile for windows which demonstrates how PeRColate could be built without using the VC++ workspace. This is the version that could be used as a basis for a Linux port....
Olaf
PS: find it at http://www.akustische-kunst.org/puredata/percolate/ (sources only...)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Maurizio Umberto Puxeddu schrieb:
http://agnula.org/~maurizio/PeRColate0.07b-linuxtoo.tar.gz
is a version of percolate 0.07b for PD adapted to Linux. It has not been tested but I compiled everything. Binaries (compiled on a RH8.0/Intel) are included.
Okay, thanks, that was very fast! I'll check this for any Win-incompatibilities. The missing objects (sekere~, shaker~ etc.) were missing because they're already part of the metashaker object and I didn't have the time (and interest ;-) to port them as well...
"mprims@skynet.be" schrieb:
Lots of them sound rather distorted, however: I don't know if that's the intended behaviour, but I suppose it is.
The objects don't check the input values sent to them... that's why it's very easy to make them sound horribly! (the same applies for the original Max version) I don't have Max and thus can't test PeRColate there to see if they really sound the same. But I guess so. Maybe there's someone out there with Max who could check this (or send me screenshots of the help patches, maybe they show which value ranges to use....).
Olaf
In my usual me-too fashion, here's a modified makefile that builds on MacOSX.
The only other change necessary is in PeRColate_source/_source/stk.c, where you should make the following change:
39c39
#if defined(UNIX) && !defined(__linux) && !defined(MACOSX)
(sorry if I got the diff polarity backwards--I can never remember correctly)
The commands to make are:
make clean_darwin make pd_darwin
Hope that's of some help to people. I'd really appreciate it if these minor changes were included into the linux port, since the differences are so tiny.
Cheers, adam
Maurizio Umberto Puxeddu said this at Fri, 22 Nov 2002 10:35:50 +0100:
Here
http://agnula.org/~maurizio/PeRColate0.07b-linuxtoo.tar.gz
is a version of percolate 0.07b for PD adapted to Linux. It has not been tested but I compiled everything. Binaries (compiled on a RH8.0/Intel) are included. If you want rebuild them go into
PeRColate-source
and
make clean make pd_linux
If you test it please report bugs to me. I'll clean up the sources and test the objects this weekend.
Regards,
Maurizio Umberto Puxeddu.
On Fri, 2002-11-22 at 00:50, Olaf Matthes wrote:
Frank Barknecht schrieb:
This is my problem as well: I cannot build the whole library, but the single externals often don't load. This surely is something simple, so my developer question is: What needs to be changed to, say, scrub~.c to make it standalone? I never wrote a library of externals so it is not clear to me: What is the difference inside the sources between a standalone external and one designed for a library?
There are no differences at all! You can compile any external as a
standalone one
or as part of a library. The library is just a 'wrapper' that calls all
the setup
routines from the single objects (and combines the compiled code into
one single
binary). Most objects in PeRColate could easily be compiled as stand alone externals because they just consist of one *.c file. Only the STK based objects
need to be
linked with stk.c. One problem arises with "gQ" because Pd's object loader seems not to
be case
sensitive. Typing "gQ" in an object box fails because Pd attemts to
load the file
gq.dll and not gQ.dll...
I've uploaded a version 0.7b of PeRColate with some minor bugfixes. It also contains a new makefile for windows which demonstrates how PeRColate
could be
built without using the VC++ workspace. This is the version that could
be used as
a basis for a Linux port....
Olaf
PS: find it at http://www.akustische-kunst.org/puredata/percolate/ (sources only...)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi, Maurizio Umberto Puxeddu hat gesagt: // Maurizio Umberto Puxeddu wrote:
http://agnula.org/~maurizio/PeRColate0.07b-linuxtoo.tar.gz
is a version of percolate 0.07b for PD adapted to Linux. It has not been tested but I compiled everything. Binaries (compiled on a RH8.0/Intel) are included.
I gave your sources a try.
If I load "pd -lib percolate" I can create the PM objects, the Modal synths, the GENs, but not the rest. So I tried building munger as standalone pd_linux, which doesn't require source changes, as Olaf has explained (thank you, Olaf, btw. for that)
Now something strange is happening. If I'm inside the munger directory, I cannot create a [munger~] or [munger~ 3000] object at first.
If I save the patch nevertheless, I can reopen it, and voila: the [munger~] is there!!
Also the helpfile for munger~ works, but I cannot create a munger~ in the first try...
It's late, and I'll have to get up early tomorrow, so I will not check this any further, although I have become curious now. Very curios...
Frank Barknecht _ ______footils.org__
On Fri, 2002-11-22 at 23:00, Frank Barknecht wrote:
Hi, Maurizio Umberto Puxeddu hat gesagt: // Maurizio Umberto Puxeddu wrote:
[...snip...]
If I load "pd -lib percolate" I can create the PM objects, the Modal synths, the GENs, but not the rest.
This is because the calls to the _tilde_setup() functions in percolate_setup() are commented out by mistake in my sources. The new version by Olaf fixed this bug (but you may need to re-fix the makefile).
Maurizio Umberto Puxeddu.
Hi.
I fixed the makefile, the lines that were commented out in percolate.c, gQ~ -> gq~ (as it was called in the help file) and few other bugs maybe.
http://agnula.org/~maurizio/PeRColate0.08b.tar.gz
Anyway it does require some reference parameters or digging the sources because great part of the models are unusable as usual with interesting undocumented DSP algorithms.
No one as experience of them on Max or can compare them?
Bacioni,
Maurizio Umberto Puxeddu.