Hi,
I am having problems running PD on my machine. I installed 0.38.4 extended RC8linux i686 on Ubuntu dapper without any problems. Firstly when I tried running it, it complained about not being able to find lib jack. I then found lib jack from synaptic package manager installed version 0.100.04 and then tried to run PD again. No luck again this time as pd is trying to load libjack-0.80.0.so.0 specifically. Is there any way around this by making it pick up the later version or do I have to hunt down this particular version of libjack? Any ideas? Conor
forwinder wrote:
Hi, I am having problems running PD on my machine. I installed 0.38.4 extended RC8linux i686 on Ubuntu dapper without any problems. Firstly when I tried running it, it complained about not being able to find lib jack. I then found lib jack from synaptic package manager installed version 0.100.04 and then tried to run PD again. No luck again this time as pd is trying to load libjack-0.80.0.so.0 specifically. Is there any way around this by making it pick up the later version or do I have to hunt down this particular version of libjack?
Had the same problem yesterday. I could not find the 0.80 version and tried to install another version of pd. But today i found out that it is not really great if you have to install all those externals yourself. So i tried again :-)
On tip i got yesterday: just make symbolic links. I hope you are a bit used to a linux system? Just type
locate libjack
and it will show you where to find the installed library. Then you make a symbolic link to it.
ln -s <real_name> <the_name_pd_looks_for>
so like
ln -s /usr/lib/jack.0.so.0 /usr/lib/jack.0.so.80
(something like that)
In my case, pd started after this but still gave an error complaining about an unknown API (audio I/O stuck) but i think that has another cause. If you do have this problem, try to use pd -oss for now. If pd starts, it will complain about other missing libraries. Just locate them and make symbolic links like above. Everytime you start pd again, it will complain about another missing library, but in the end you'll get there. (depending on which libraries you'll load. Try without first.
If locate does not find a library wit the same name, you'll probably have to install it, using apt-get or yum or whatever ubuntu uses. But I only needed to do that when loadling some externals, not for the standard pd.
Please let me know if this helps. Maybe it is time to make a new installation guide for pd, because there seem to be some complexities for newcomers. (I have used pd on windows until know, and am quite familiar with linux, but i took quite some time to figure it all out.)
regards,
yvan
On Wed, 21 Jun 2006, forwinder wrote:
is trying to load libjack-0.80.0.so.0 specifically. Is there any way around this by making it pick up the later version or do I have to hunt down this particular version of libjack?
Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
You would still have to resolve the library dependencies for the externals one by one though.
Günter
Any ideas? Conor
On Thu, 2006-06-22 at 08:36 +0200, geiger wrote:
On Wed, 21 Jun 2006, forwinder wrote:
is trying to load libjack-0.80.0.so.0 specifically. Is there any way around this by making it pick up the later version or do I have to hunt down this particular version of libjack?
Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
it works, but there is a problem doing that: the external [import] won't load anymore (undefined symbol: sys_load_lib_dir) and since many externals are compiled as single objects in pd-extended, you would have to add a -path for each directory in [...]pd/extra/ .
besides that, the externals still work, though.
roman
You would still have to resolve the library dependencies for the externals one by one though.
Günter
Any ideas? Conor
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Thu, 22 Jun 2006, Roman Haefeli wrote:
Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
it works, but there is a problem doing that: the external [import] won't load anymore (undefined symbol: sys_load_lib_dir) and since many externals are compiled as single objects in pd-extended, you would have to add a -path for each directory in [...]pd/extra/ .
.. or by instantiating the objects with a prefix (like "foo/bar") which also prevents you from importing the wrong object.
Günter
besides that, the externals still work, though.
roman
You would still have to resolve the library dependencies for the externals one by one though.
Günter
Any ideas? Conor
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, 2006-06-22 at 17:31 +0200, geiger wrote:
On Thu, 22 Jun 2006, Roman Haefeli wrote:
Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
it works, but there is a problem doing that: the external [import] won't load anymore (undefined symbol: sys_load_lib_dir) and since many externals are compiled as single objects in pd-extended, you would have to add a -path for each directory in [...]pd/extra/ .
.. or by instantiating the objects with a prefix (like "foo/bar") which also prevents you from importing the wrong object.
.. which is IMO the more elegant solution. thanks for that hint.
Günter
besides that, the externals still work, though.
roman
You would still have to resolve the library dependencies for the externals one by one though.
Günter
Any ideas? Conor
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
On Thu, 2006-06-22 at 18:06 +0200, Roman Haefeli wrote:
On Thu, 2006-06-22 at 17:31 +0200, geiger wrote:
On Thu, 22 Jun 2006, Roman Haefeli wrote:
Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
it works, but there is a problem doing that: the external [import] won't load anymore (undefined symbol: sys_load_lib_dir) and since many externals are compiled as single objects in pd-extended, you would have to add a -path for each directory in [...]pd/extra/ .
.. or by instantiating the objects with a prefix (like "foo/bar") which also prevents you from importing the wrong object.
.. which is IMO the more elegant solution. thanks for that hint.
Let me clarify, I understand the pd -path [PATH]external. I could throw the bash call into a bash script and bobs your uncle but as for the other suggestion from Gunter : > the objects with a prefix (like "foo/bar") which
also prevents you from importing the wrong object.
I'm lost there. What do you mean by that explicitly. Sorry Linux newbie here...
On Thu, 22 Jun 2006, Conor J Curran wrote:
> the objects with a prefix (like "foo/bar") which
also prevents you from importing the wrong object.
I'm lost there. What do you mean by that explicitly. Sorry Linux newbie here...
Thats ok, the concept is not very well documented, and it might look complex, but it is easy to use. It is not linux specific, but works on every platform.
Pd looks for its externals in a path, which by default includes the "extra" directory which is in your pd installation.
This way, if you instantiate an object called, lets say "lowpass", pd checks if there is an object "lowpass" in several places (built-in object, abstraction and as external). It does this by concatenating the path, the object name and some extension (.pd_linux, .dll or .pd_darwin).
Imagine you have an external in /usr/lib/pd/extra/ggee/lowpass.pd_linux (for linux in this example)
Now, if you write in your object box "ggee/lowpass", what pd does is looking for and object called "ggee/lowpass", which it finds by concatenating "/usr/lib/pd/extra/" and "ggee/lowpass" and ".pd_linux".
The same for windows, just that the extension will be ".dll".
Now, in your patch you can use "ggee/lowpass" just as if you would have loaded the "lowpass" external, but with an unambiguous name.
Therefore, at the same time you can use other objects with the same name, but from a different sub directory, like "something/lowpass". You can also call and use an abstraction called only "lowpass", because now it is different from ggee/lowpass.
Because of the fact that I have explained this several times already on the list, the concept is know as "geiger namespaces", which I think is the wrong name. This concept was introduced by Miller, but not very well documented. I found it by looking at the phase locked vocoder examples.
Hope this makes it clear,
Günter
On Jun 21, 2006, at 11:36 PM, geiger wrote:
On Wed, 21 Jun 2006, forwinder wrote:
is trying to load libjack-0.80.0.so.0 specifically. Is there any
way around this by making it pick up the later version or do I have to
hunt down this particular version of libjack?Have you tried with apt-get install puredata ? Theoretically it should be possible to use the externals together with the puredata version that is shipped by ubuntu.
You would still have to resolve the library dependencies for the
externals one by one though.
Even better would be to have OS-specific packages based on Pd- extended, including Debian, RedHat, etc.
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
On Thu, 22 Jun 2006, Hans-Christoph Steiner wrote:
Even better would be to have OS-specific packages based on Pd- extended, including Debian, RedHat, etc.
It depends. I am scared of trying to do that, because it seems to me to be a maintainance nightmare. I also think that there is too much duplicated functionality in pd-extended, which makes it bloated.
I see the usefulness of pd extended for the user, but as a developer I just can't invest my spare time into something that I think is not a good thing. Most of the externals in pd-extended are for beginners, when people do not know how to solve a problem in pd, they just look if an external for solving their problem exists.
The idea of the CVS was not to throw everything in a pot and cook it, but to extract the useful parts and combine efforts.
Anyhow, I have said that several times already, and please don't get me wrong, I think pd-extended is great for the user and for being able to quickly install everything that is around, but I just can not invest my time on working on something where I constantly have to fix things that I think that shouldn't be there in the first place.
Official Debian/Ubuntu packages of pd-extended are very unlickely to come from my side.
Günter
.hc
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
On Jun 22, 2006, at 11:47 PM, geiger wrote:
On Thu, 22 Jun 2006, Hans-Christoph Steiner wrote:
Even better would be to have OS-specific packages based on Pd- extended, including Debian, RedHat, etc.
It depends. I am scared of trying to do that, because it seems to me to be a maintainance nightmare. I also think that there is too much duplicated functionality in pd-extended, which makes it bloated.
I see the usefulness of pd extended for the user, but as a developer I just can't invest my spare time into something that I think is not a good thing. Most of the externals in pd-extended are for beginners, when people do not know how to solve a problem in pd, they just look if an external for solving their problem exists.
The idea of the CVS was not to throw everything in a pot and cook it, but to extract the useful parts and combine efforts.
Anyhow, I have said that several times already, and please don't
get me wrong, I think pd-extended is great for the user and for being able to quickly install everything that is around, but I just can not
invest my time on working on something where I constantly have to fix things
that I think that shouldn't be there in the first place.Official Debian/Ubuntu packages of pd-extended are very unlickely to come from my side.
I definitely don't have an interest in fixing things that are not
useful. That is certainly not the aim of Pd-extended. So much stuff
is included because a) there is a ton of good code available for Pd,
and b) people use this stuff. Before, if someone posted a patch
where they used some non-standard externals, it was always a major
chore for other to set up the externals so that patch worked. If
everyone is on the same install, that problem goes away.
Yes, its a big package, and yes there is a lot of crap that is
included. But these days, hard drive space is far cheaper and more
abundant than Pd developer time. So it doesn't really seem
worthwhile to spend much time removing cruft if it doesn't get in the
way, and its safely tucked away in a libdir, where it can't do any
harm to people unless they try to use it.
Another thing about a common build system is that a lot of the
maintenance and debugged is then shared across platforms. This saves
a lot of labor. I think that the debian packages would be less
maintenance if their build system was pooled with Pd-extended,
especially if you include pdp and pidip and others that aren't
currently part of the "official" debian packages.
If someone else did the work, would you be willing to accept it as
the standard Debian packages?
.hc
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Fri, Jun 23, 2006 at 12:09:24AM -0700, Hans-Christoph Steiner wrote:
On Jun 22, 2006, at 11:47 PM, geiger wrote:
Official Debian/Ubuntu packages of pd-extended are very unlickely to come from my side.
If someone else did the work, would you be willing to accept it as
the standard Debian packages?
I know this has been suggested before, but the Debian way to do it would be to have puredata as a Debian package, as it is now, and sets of externals as their own Debian packages, as is the case with pd-zexy (mad props to G. Geiger!). So puredata-extended should not include puredata, but only externals. This is probably even more work, and we'll see even less hands going up to volunteer. I've tried to start doing it myself on more than one occasion and was defeated pretty quickly. One thing that is true of pd-extended is that it exists; most other similar efforts are vapourware. Argh, confused flu-infused ramblings.
Best regards,
Chris.
chris@mccormick.cx http://mccormick.cx
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
I definitely don't have an interest in fixing things that are not useful. That is certainly not the aim of Pd-extended. So much stuff is included because a) there is a ton of good code available for Pd, and b) people use this stuff. Before, if someone posted a patch where they used some non-standard externals, it was always a major chore for other to set up the externals so that patch worked. If everyone is on the same install, that problem goes away.
Yes, its a big package, and yes there is a lot of crap that is included. But these days, hard drive space is far cheaper and more abundant than Pd developer time. So it doesn't really seem worthwhile to spend much time removing cruft if it doesn't get in the way, and its safely tucked away in a libdir, where it can't do any harm to people unless they try to use it.
Another thing about a common build system is that a lot of the maintenance and debugged is then shared across platforms. This saves a lot of labor. I think that the debian packages would be less maintenance if their build system was pooled with Pd-extended, especially if you include pdp and pidip and others that aren't currently part of the "official" debian packages.
If I bundle up everything it will be pretty hard to get it into a state where it can enter the debian repository, especially for things like pdp (which is in debian) and pidip, which have their own build system, and what pd-extended does is mainly calling that, if I am not wrong.
If the packages are split up I can work on the problems separately, while other parts that are less complicated to get going can easily go through quality control.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone should use and which just use up disk space.
If someone else did the work, would you be willing to accept it as the standard Debian packages?
I am not in the position to accept standard Debian packages, if you ask if I would upload such a package to Debian, I would say probably. It depends on the quality of the package (see above) and if the person who packages it is reliable enough.
Günter
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jun 23, 2006, at 7:49 AM, geiger wrote:
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
I definitely don't have an interest in fixing things that are not useful. That is certainly not the aim of Pd-extended. So much stuff is included because a) there is a ton of good code available for Pd, and b) people use this stuff. Before, if someone posted a patch where they used some non-standard externals, it was always a major chore for other to set up the externals so that patch worked. If everyone is on the same install, that problem goes away.
Yes, its a big package, and yes there is a lot of crap that is included. But these days, hard drive space is far cheaper and more abundant than Pd developer time. So it doesn't really seem worthwhile to spend much time removing cruft if it doesn't get in the way, and its safely tucked away in a libdir, where it can't do any harm to people unless they try to use it.
Another thing about a common build system is that a lot of the maintenance and debugged is then shared across platforms. This saves a lot of labor. I think that the debian packages would be less maintenance if their build system was pooled with Pd-extended, especially if you include pdp and pidip and others that aren't currently part of the "official" debian packages.
If I bundle up everything it will be pretty hard to get it into a state where it can enter the debian repository, especially for things like pdp (which is in debian) and pidip, which have their own build system, and what pd-extended does is mainly calling that, if I am not wrong.
If the packages are split up I can work on the problems separately, while other parts that are less complicated to get going can easily go through quality control.
The Pd-extended build system should be able to handle this right
now. Each section is easily buildable on its own by doing: make
ggee, make zexy, make pdp, make iemlib, etc. And it is quite easy to
redirect the install location of make pdp_install, make zexy_install,
etc.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone
should use and which just use up disk space.
There is undoubtedly a lot of cruft. Part of what I think we should
do with Pd-extended is to make a standard way of deprecating cruft.
But that takes a lot of work. So in the meantime, Pd-extended ships
with a lot of cruft.
The way Pd-extended is now is by no means a finished product, its
just one of the stepping stones to a Pd platform. I think its time
to stop wasting time making separate build systems and distros for
each platform. The amount of time that people have wasted on issues
due to the separate distros is massive. The amount of time people
have to wait because the package is 25 megs bigger than it should be
is not very big. We can then put that effort into going forward on
all platforms.
For example, I have already started the process of building a farm of
servers for automatic nightly builds for a number of platforms. This
will help us catch problems and save us a lot of time making test
releases. Having a common build system means that when a problem is
solved on one platform, its most likely going to fix that problem on
all the rest.
If someone else did the work, would you be willing to accept it as the standard Debian packages?
I am not in the position to accept standard Debian packages, if you
ask if I would upload such a package to Debian, I would say probably. It depends on the quality of the package (see above) and if the person who packages it is reliable enough.
Once we have the automatic nightly builds setup, that should catch a
lot of problems. Moving it to Debian proper shouldn't be a big deal
then.
.hc
Günter
.hc
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
The Pd-extended build system should be able to handle this right now. Each section is easily buildable on its own by doing: make ggee, make zexy, make pdp, make iemlib, etc. And it is quite easy to redirect the install location of make pdp_install, make zexy_install, etc.
Yes, but still I have to do prepare a package each time something went wrong. And there are more things that can go wrong than one generally thinks.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone should use and which just use up disk space.
There is undoubtedly a lot of cruft. Part of what I think we should do with Pd-extended is to make a standard way of deprecating cruft. But that takes a lot of work. So in the meantime, Pd-extended ships with a lot of cruft.
The way Pd-extended is now is by no means a finished product, its just one of the stepping stones to a Pd platform. I think its time to stop wasting time making separate build systems and distros for each platform. The amount of time that people have wasted on issues due to the separate distros is massive. The amount of time people have to wait because the package is 25 megs bigger than it should be is not very big. We can then put that effort into going forward on all platforms.
Sorry, I just do not agree. Most of the things can be done with Pd builtin objects. If we would not try to maintain useless stuff we would save even more time. If people wouldn't have to try several externals and versions before finding the right object to do their things they would save time.
<snip> > > Once we have the automatic nightly builds setup, that should catch a > lot of problems. Moving it to Debian proper shouldn't be a big deal > then.
It might not be a big deal, but it is work, and there are quality checks in Debian that are not that easy to surpass. Being able to build is only one step. We might be lucky, but I do not think that the Debian people share your opinion about quality, so I am in for trouble, and it will be hard for me to justify the size of the package, especially if I am not convinced myself.
Then, there is also the possiblity to maintain packages outside of Debian, which might be easier.
Günter
On Jun 27, 2006, at 9:34 AM, geiger wrote:
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
The Pd-extended build system should be able to handle this right now. Each section is easily buildable on its own by doing: make ggee, make zexy, make pdp, make iemlib, etc. And it is quite easy to redirect the install location of make pdp_install, make zexy_install, etc.
Yes, but still I have to do prepare a package each time something went wrong. And there are more things that can go wrong than one generally thinks.
I also like to have the possibility to only install pd, and not hundreds of externals which I won't use, and which I think noone should use and which just use up disk space.
There is undoubtedly a lot of cruft. Part of what I think we should do with Pd-extended is to make a standard way of deprecating cruft. But that takes a lot of work. So in the meantime, Pd-extended ships with a lot of cruft.
The way Pd-extended is now is by no means a finished product, its just one of the stepping stones to a Pd platform. I think its time to stop wasting time making separate build systems and distros for each platform. The amount of time that people have wasted on issues due to the separate distros is massive. The amount of time people have to wait because the package is 25 megs bigger than it should be is not very big. We can then put that effort into going forward on all platforms.
Sorry, I just do not agree. Most of the things can be done with Pd builtin objects. If we would not try to maintain useless stuff we
would save even more time. If people wouldn't have to try several externals and versions before finding the right object to do their things they would save time.
All of libc can be written in C, yet basically no one writes C
programs without libc. libc is not small, there is a lot of stuff in
there. Pd needs to have a lot of stuff included before its anywhere
near as flushed out as libc. We really cripple ourselves if we do
not build and use libraries, whether those libraries are written in C
or Pd or whatever. I would rather create music than rewrite an
object that someone else has already created and debugged. For
example, I would have no idea how to write a feedback delay network
in Pd, it would take me a long time to figure out how, and then debug
it. But luckily someone else has done it. And it took me 20 minutes
to get it working how I wanted it to.
I agree that stuff is a mess as it is now. That's why I think we
should work on standard libraries and deprecate things as we have
useful replacements. But Pd as Miller distributes it just too small
compared to all of the useful work that people have done. Many of
the projects I have done quite simply could not be accomplished using
that set of objects.
<snip> > > Once we have the automatic nightly builds setup, that should catch a > lot of problems. Moving it to Debian proper shouldn't be a big deal > then.
It might not be a big deal, but it is work, and there are quality
checks in Debian that are not that easy to surpass. Being able to build is
only one step. We might be lucky, but I do not think that the Debian people share your opinion about quality, so I am in for trouble, and it
will be hard for me to justify the size of the package, especially if I am not convinced myself.Then, there is also the possiblity to maintain packages outside of
Debian, which might be easier.
I think Debian quality checks are a good idea. If we have a unified
build system, then all platforms would be more likely benefit from
the Debian quality checks.
.hc
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Even better would be to have OS-specific packages based on Pd- extended, including Debian, RedHat, etc.
Seems that opinions are divided about this. I think it would be worth the effort, but it's entirely true that sooner or later, one will give up if the process to generate the packages comsumes too much time. But i recalled a system i once looked at. Never used it myself though. A dynamic apt repository builder... The author claims it can do a lot of work automaticly. And i know he's a nice guy, he might even help setting it up. Maybe it's worth to consider?
There is information about it on http://dag.wieers.com/home-made/dar/
Greetings, yvan
hi Conor
try to install this more up-to-date version of pd-extended: http://idmi.poly.edu/pdlab/Pd-0.39.2-extended-test4-linux-i686.tar.bz2
you can always get the neweset version of pd-extended here: http://at.or.at/hans/pd/installers.html
cheers
roman
On Wed, 2006-06-21 at 15:53 -0700, forwinder wrote:
Hi, I am having problems running PD on my machine. I installed 0.38.4 extended RC8linux i686 on Ubuntu dapper without any problems. Firstly when I tried running it, it complained about not being able to find lib jack. I then found lib jack from synaptic package manager installed version 0.100.04 and then tried to run PD again. No luck again this time as pd is trying to load libjack-0.80.0.so.0 specifically. Is there any way around this by making it pick up the later version or do I have to hunt down this particular version of libjack? Any ideas? Conor
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de