Pd-list

pd-list@lists.iem.at

19 participants
33278 discussions

Signal s_n (length) field - different sizes?
by Larry Troxler 12 Feb '98

12 Feb '98

It seems that PD carries around the size of the signal as a variable, as if it is expected that signals may be of different sizes withing the same instance of PD. But yet, it looks like most things would break anyway if the signals weren't all the same size. I'm just wondering what the history and/or future plans are with this. Is PD heading toward allowing multiple length signals, or is the opposite true (at first, multiple-lengths were provided for, but it never materialized)? Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

Re: tables in Pd
by Miller Puckette 11 Feb '98

11 Feb '98

On Feb 7, 5:13pm, William Kleinsasser wrote: > > When trying to create a new array using the menu, I get an error: > > bad screen distance ".x1008a828.a10095220" > > and see no new array. When I try to send messages to it (array2) I am > told that it doesn't exist. Also, moving the arrays around the screen > is very slow. > > > Is there a simple way to create and use envelope shapes like Hamming, > Hanning, etc.? > > Thanks, > > Bill > >-- End of excerpt from William Kleinsasser Ouch... I never saw the error you're getting creating tables, the "bad screen distance ".x1008a828.a10095220" Does this happen if you make a new document and put an array into it or is there more context I should reproduce? Also, I forgot which kind of machine you run on; perhaps there's a bizarre machine dependency lurking. You can make Hanning/Hamming windows by blasting an oscillator right into tabwrite~, although it's tricky setting the phase. (you do it by taking a snapshot~ of the phasor~ output and subtracting that number from phasor~'s future output. Not that tabread4~'s 4-point interpolation means that its input should be between 1 and size-2. cheers Miller

2 3

problems running pd-0.20 under linux
by Nicola Bernardini 11 Feb '98

11 Feb '98

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: 1) 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) 2) 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(a)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.

2 3

new pd user question
by Curtis Bahn 11 Feb '98

11 Feb '98

Hi, I was wondering what sound cards worked best with Pd on WindowsNT4.0. thanks, Curtis Bahn

1 0

Re: PD: d_ugens.c bug found?
by Miller Puckette 10 Feb '98

10 Feb '98

About the ugen cleanup bug -- I'm with Larry Troxler; it's the "used" list that should be freed; the free list should just be zeroed out. I've fixed this for 0.21 (which I'm hoping to get out Thursday.) This might explain Nicola's problems making and breaking connections with DSP on... -Miller

1 0

I have some bug fixes ...
by Larry Troxler 10 Feb '98

10 Feb '98

... What should I do with them? Most relate to Linux soundcard handling, but there's also the twice freed() bug in the DSP buffer handling. In addition, I've added some comments in various places as I've discovered what's going on, and made some changes to make it easier to select outlets with the mouse (should be eventually configurable, I suppose). Also I expanded on the "src/notes" file. I could either - generate a patch file against 0.20 and mail it to Miller or Guenter for review - Mail the complete package to Miller or Guenter for review - Make either of the above available on my FTP directory Let me know. Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

Major code cleanup needed?!?!
by Larry Troxler 09 Feb '98

09 Feb '98

I think PD must have originally been inherited from the Pre-ANSI C days :-) Is it just me, or does anyone else have an urge to clean the thing up before the project grows further? - Compiling with -Wall on gcc/Linux results in many screen fulls of warnings. Perhaps the #pragmas in gcc are a bit weak (to disable specific warnings) and this is why -Wall isn't used by default? - There as some function prototypes patched directly into the C files where the functions are called, as opposed to using an include-file. - Some files (the Tk ones?) use the old K&R-style function definitions and declarations! If anyone is interested in collaborating, perhaps, on cleaning this up, please contact me at lt(a)westnet.com Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

2 2

tables in Pd
by Miller Puckette 09 Feb '98

09 Feb '98

Hi all, I've received two requests for tabread4~/tabwrite~ examples. Here's a rather silly patch that records and "scratches" a 1-second sound. Tables are created using the "array" item in the new menu. If you don't want all your arrays to be in the same graph (rectangle), make a new "graph" each time and the array will (supposedly) find the newest one. You can then pass messages to set the size ("resize"), write, read, and access them by name using tabwrite~, tabread4~. Enjoy... ------------------------------ #N canvas 376 125 642 692 10; #X msg 45 62 bang \; pd dsp 1; #X obj 213 178 * 44.1; #X floatatom 212 154 894; #X obj 213 229 line~; #X obj 212 203 pack 0 100; #X floatatom 112 152 59; #X floatatom 42 168 21; #X obj 42 192 sig~; #N canvas 0 0 629 645 Untitled-1 1; #X graph graph1 0 -1 44100 1 141 327 541 27; #X array array1 44100 float; #X pop; #X msg 152 348 \; array1 read foo.tab; #X msg 151 399 \; array1 write foo.tab; #X msg 150 444 \; array1 resize 44100; #X msg 152 489 \; array1 print; #X restore 437 92 page table; #X obj 84 354 sig~ 0.1; #X obj 44 353 *~; #X obj 318 248 metro; #X msg 319 201 1; #X floatatom 319 224 1; #X obj 414 309 tabwrite~ array1; #X obj 414 228 sig~; #X obj 414 198 random 1000; #X obj 414 253 phasor~; #X obj 414 283 cos~; #X obj 43 382 hip~ 5; #X obj 46 412 dac~; #X obj 44 322 tabread4~ array1; #X obj 41 218 phasor~; #X msg 383 151 bang \; pd dsp 1; #X obj 113 227 line~; #X obj 44 247 *~; #X obj 44 279 +~; #X obj 112 201 pack 0 100; #X obj 111 177 * 44.1; #X msg 42 144 20; #X msg 112 123 100; #X obj 315 279 random 30; #X connect 0 0 29 0; #X connect 0 0 30 0; #X connect 1 0 4 0; #X connect 2 0 1 0; #X connect 3 0 26 1; #X connect 4 0 3 0; #X connect 5 0 28 0; #X connect 6 0 7 0; #X connect 7 0 22 0; #X connect 9 0 10 1; #X connect 10 0 19 0; #X connect 11 0 16 0; #X connect 11 0 31 0; #X connect 12 0 13 0; #X connect 13 0 11 0; #X connect 15 0 17 0; #X connect 16 0 15 0; #X connect 17 0 18 0; #X connect 18 0 14 0; #X connect 19 0 20 0; #X connect 19 0 20 1; #X connect 21 0 10 0; #X connect 22 0 25 0; #X connect 23 0 12 0; #X connect 23 0 14 0; #X connect 24 0 25 1; #X connect 25 0 26 0; #X connect 26 0 21 0; #X connect 27 0 24 0; #X connect 28 0 27 0; #X connect 29 0 6 0; #X connect 30 0 5 0; #X connect 30 0 2 0; #X connect 31 0 11 1;

2 1

problems running pd-0.20 under linux (2. posting)
by Nicola Bernardini 08 Feb '98

08 Feb '98

I am sending this mail again because the list seems to have gotten another (later) mail from me but not this one. Sorry if you get double postings... Nicola ------------------------------------------------------------------------ Nicola Bernardini E-mail: nicb(a)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. ---------- Forwarded message ---------- Date: Thu, 5 Feb 1998 10:25:19 +0100 (MET) From: Nicola Bernardini <nicb(a)axnet.it> To: pd list <pd-list(a)iem.mhsg.ac.at> Subject: problems running pd-0.20 under linux 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: 1) 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) 2) 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(a)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.

1 0

the patch (I forgot...)
by Nicola Bernardini 06 Feb '98

06 Feb '98

(Sorry, I forgot to append the patch. Here it is...) Nicola ------------------------------------------------------------------------ Nicola Bernardini E-mail: nicb(a)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. --- ./s_inter.c.orig Thu Feb 5 08:35:00 1998 +++ ./s_inter.c Thu Feb 5 09:19:51 1998 @@ -60,6 +60,9 @@ static t_binbuf *inbinbuf; static t_socketreceiver *sys_socketreceiver; +static char *s_tcl_libdir = (char *) NULL; +static char *s_tk_libdir = (char *) NULL; + void sys_sockerror(char *s) { #ifdef NT @@ -318,12 +321,14 @@ } else /* we're the child */ { + char *sys_getenv(const char *e); /* in s_linux.c (at least) */ + s_tcl_libdir = sys_getenv("TCL_LIBRARY"); + s_tk_libdir = sys_getenv("TK_LIBRARY"); dup2(pipeto[0], 0); close(pipeto[0]); close(pipeto[1]); - sprintf(cmdbuf, - "TCL_LIBRARY=%s/tcl/library TK_LIBRARY=%s/tk/library %s/bin/pd-gui %d\n", - sys_progdir->s_name, sys_progdir->s_name, sys_progdir->s_name, + sprintf(cmdbuf, "TCL_LIBRARY=%s TK_LIBRARY=%s %s/bin/pd-gui %d\n", + s_tcl_libdir, s_tk_libdir, sys_progdir->s_name, portno); fprintf(stderr, "%s", cmdbuf); execl("/bin/sh", "sh", "-c", cmdbuf, 0); --- ./s_linux.c.orig Thu Feb 5 08:45:51 1998 +++ ./s_linux.c Thu Feb 5 08:49:12 1998 @@ -616,3 +616,15 @@ { return (cp_ch); } + +#include <stdlib.h> + +char *sys_getenv(const char *envname) +{ + static char *empty_string = ""; + char *result = getenv(envname); + if (result == (char *) NULL) + result = empty_string; + + return result; +}

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list