Hello everybody!
I am running pd on a linux laptop and a linux box both of which run a 2.0.33 kernel. They have different audio setups but I always get a few warnings, like "failed to open audio read port" and "could not open MIDI ports" (even though, at least on the linux box, MIDI is up and running on a SB16). Also, pd must be set suid if running as user because otherwise there are a number of operations (like setting scheduler priorities, etc.) which are not permitted. Anyway, no big problems there (at least for the moment).
One thing that is not clear is the two environment variables TCL_LIBRARY and TK_LIBRARY that are set upon exec'ing pd-gui. Are they for some future purpose? (Actually, I noticed that pd runs also if these variables are not set or are set to incorrect paths, so are they of any use at all?) I made a little trivial patch so that TCL_LIBRARY and TK_LIBRARY can be set externally and applied upon calling pd-gui. I am appending it at the bottom of this mail, if somebody finds it useful, she/he can apply it with patch. Also, on the same idea, some call or some library like, I believe, kpathsea or something like that could be used to infer the path where pd is being run from so to apply it to sys_progdir.
Aside from that, there are a few things I am not able to solve:
If, for example, I call up pd, set the audio to ON, THEN open a patch like "cos~.pd" and run the oscillator, no audio happens; if I open the patch THEN turn the audio ON the audio works (this used to happen to 0.18 too)
on 0.20 when I edit the patch and audio is ON, after *any* edit operation (like delete a cord, change a patch name, etc.) the program sigsevs and collapses; I cannot run gdb on pd because it says it cannot ptrace (I am using 4.14), but I managed to look into pd-gui and that's not the process doing the segmentation violation: it's pd, but since sigsev does not dump core there is little that I can do there to help...
At any rate, let's go on! Looks like we have a bright future to look up to...
ciao Nicola
Nicola Bernardini E-mail: nicb@axnet.it
Re graphics: A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.
Nicola Bernardini writes:
Hello everybody!
I am running pd on a linux laptop and a linux box both of which run a 2.0.33 kernel. They have different audio setups but I always get a few warnings, like "failed to open audio read port"
This is due tue the fact that SB's only support one directional sampling. Pd chooses to use the write port and therefore fails for the read port.
open MIDI ports" (even though, at least on the linux box, MIDI is up and running on a SB16). Also, pd must be set suid if running as user because otherwise there are a number of operations (like setting scheduler priorities, etc.) which are not permitted. Anyway, no big problems there (at least for the moment).
Basically MIDI is known to work .. You are right, I did put in some rt scheduling stuff for Linux which can only be used under root. Otherwise it will just be ignored.
One thing that is not clear is the two environment variables TCL_LIBRARY and TK_LIBRARY that are set upon exec'ing pd-gui. Are they for some
Aside from that, there are a few things I am not able to solve:
- If, for example, I call up pd, set the audio to ON, THEN open a patch like "cos~.pd" and run the oscillator, no audio happens; if I open the patch THEN turn the audio ON the audio works (this used to happen to 0.18 too)
This, or similar cases are "known" bugs. I guess they are not high priority at the moment, but anybody solving this is welcome .. :)
- on 0.20 when I edit the patch and audio is ON, after *any* edit operation
I can't reproduce this, but there have been two 0.20 versions, the first one had a bug. Probably we should come up with a 0.21 just for clearness. Miller ?
Guenter
Thanks Guenter for your quick reply (and to Miller too, for his reply on d_ugen bug)
On Mon, 9 Feb 1998, Guenter Geiger wrote:
[snip]
few warnings, like "failed to open audio read port"
This is due tue the fact that SB's only support one directional sampling. Pd chooses to use the write port and therefore fails for the read port.
I should have guessed that, sorry... Does somebody have a current list of the cards that support full duplex and that have drivers for linux?
[snip]
Basically MIDI is known to work ..
well, I'll test MIDI a little bit further...
You are right, I did put in some rt scheduling stuff for Linux which can only be used under root. Otherwise it will just be ignored.
I think it could be a good idea to su-id pd (not pd-gui) in the installation target: I do not think there is a security breach in this (but I am not a specialist of security). Or better, there could be a condition that allows to select whether to do this or not.
- If, for example, I call up pd, set the audio to ON, THEN open a patch like "cos~.pd" and run the oscillator, no audio happens; if I open the patch THEN turn the audio ON the audio works (this used to happen to 0.18 too)
This, or similar cases are "known" bugs. I guess they are not high priority at the moment, but anybody solving this is welcome .. :)
I'll look this up if this is still there on 0.21...
- on 0.20 when I edit the patch and audio is ON, after *any* edit operation
I can't reproduce this, but there have been two 0.20 versions, the first one had a bug. Probably we should come up with a 0.21 just for clearness. Miller ?
Well, this is extremely deterministic on my machine (it happens all the time). If this persist, I'll try harder. Does somebody know how to trap processes dying with sigsegv with gdb? (no core is produced, even with ulimit -c unlimited, and gdb says it cannot ptrace the pd process...)
Nicola
Nicola Bernardini E-mail: nicb@axnet.it
Re graphics: A picture is worth 10K words -- but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures.
Nicola Bernardini writes:
time). If this persist, I'll try harder. Does somebody know how to trap processes dying with sigsegv with gdb? (no core is produced, even with ulimit -c unlimited, and gdb says it cannot ptrace the pd process...)
I had no problem debugging pd with gdb. Be sure you have the right paths to the source in gdb. ( assuming pd is compiled -g). Use Emacs. Most of the time gdb should be able to backtrace pd. After the segfault you can then easily examine your variables ... and look what went wrong.
Get the new version of pd-0.20 at my site or wait until 0.21.
Guenter
-
Guenter Geiger -
Nicola Bernardini