Pd-list March 1998

pd-list@lists.iem.at

16 participants
43 discussions

"expr", Perl??, ...
by Larry Troxler 30 Mar '98

30 Mar '98

I notice in the Ircam Max docs, there is a description of an "expr" object. Will this be implemented soon? Actually, I've been still thinking about how to integrate PD with "linear" programming languages. I asked on this list a short time ago about connecting PD to a Lisp image running CM. For the time being, I'm not going to try this, since I'm don't have any experience programming sockets, especially in Common Lisp. but in the search for an alternative solution to implementing expressions by patching PD objects together, I've now hit upon the idea of linking the perl library to PD, and coding an object that calls Perl. So this object would be like the "expr" object, but more powerfull. This doesn't seem like it would be very difficult to do. Maybe the Perl expression to evaluate could be sent as a message to the perl object. Any thoughts? Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

2 1

DSP questions
by Larry Troxler 30 Mar '98

30 Mar '98

1. I understand that DSP signal inlets and outlets are in the code, but according to MSP aren't quite working right yet. What problems are there (should I try using them or not) 2. In the "stuff" directory, at least one of the examples uses a technique of patching two different signals to the same inlet, and the effect seems to be that the two signals get added at the inlet. The receiving object in this case is a "cos~". Is this technique valid in general? If so, what part of the PD source code implements this? Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

Bug report (loading patch)
by Larry Troxler 28 Mar '98

28 Mar '98

I encountered the following error when loading the patch below. The patch appears with out the connection lines drawn. It was created only within PD, and not using any kind of external editing. Can anyone tell me what is wrong??? Larry - - - Pd version 0.21 compiled Sun Jan 25 21:08:34 PST 1998 port 5400 Waiting for connection request... TCL_LIBRARY=../tcl/library TK_LIBRARY=../tk/library ../bin/pd-gui 5400 ... connected advance 3 Found MIDI ports on /dev/midi00 and /dev/midi01 pd: running. error: /: no such object - - - #N canvas 0 0 626 700 8; #X obj 90 291 sig~; #X obj 67 222 t b f; #X floatatom 120 200 0.95; #X obj 289 206 float; #X floatatom 111 17 20; #X obj 159 408 *~; #X obj 433 397 *~; #X floatatom 462 330 0; #X obj 462 381 line~; #X floatatom 156 20 1255; #X floatatom 25 17 0; #X obj 36 272 phasor~; #X obj 514 433 tabwrite~ array1; #X msg 527 385 bang; #N canvas 311 85 707 568 arrays 0; #X graph graph1 0 -1 200 1 254 344 654 44; #X array array1 200 float; #X pop; #X graph graph1 0 -1 183430 1 253 659 653 359; #X array array5 183430 float; #X pop; #X restore 516 -58 page arrays; #X obj 272 270 line~; #X obj 230 220 pack 0 100; #X obj 175 324 +~; #X obj 80 316 *~; #X obj 462 346 dbtorms; #X obj 462 363 pack 0 100; #X obj 433 426 dac~; #X obj 175 367 tabread4~ array5; #X obj 70 367 cos~; #X obj 105 367 sig~ -1; #X obj 35 247 sig~; #X obj 23 55 mtof; #X obj 24 35 * 0.01; #X floatatom 40 112 1; #X obj 23 73 / 8.1758; #X text 430 315 output level (100 for unit gain); #X msg 532 16 0; #X obj 421 332 r outdb; #X msg 326 15 \; pd dsp 1 \; outdb 90; #X msg 310 88 \; pd dsp 0 \; array5 read \$1 \; array5 print; #X msg 307 -43 foo /p2/sounds/miked/one-more-time.f; #X msg 314 -26 foo /p2/sounds/euro/euro1003.f; #X floatatom 435 13 800000; #X obj 434 94 / 4; #X text 461 96 sizeof(float); #X msg 368 192 0 0; #X text 394 190 rewind; #X obj 434 122 / 44.1; #X text 474 123 total dur in ms; #X text 24 4 XPOSE IN CENTS; #X obj 434 161 /; #X text 453 158 total dur after stretching; #X text 429 0 FILE-SIZE (BYTES); #X text 325 1 ENABLE; #X text 527 0 STOP; #X text 193 4 PLAY-WITH-SPEEDUP; #X obj 338 162 t b b b; #X obj 349 239 float; #X text 151 3 SCRATCH; #X msg 530 270 \; scratch 0; #X obj 452 247 r grain_stop; #X msg 455 288 0; #X obj 531 42 s grain_stop bang; #X text 307 -60 SOUND-FILE; #X floatatom 128 115 0.05; #X msg 128 71 0; #X text 145 96 traversal speedup; #X text 49 89 desired speedup; #X obj 110 172 -; #X text 134 177 needed grain speedup; #X obj 117 147 t b f; #X floatatom 192 20 0.05; #X obj 121 223 * 44100; #X text 110 2 FGRAIN; #X obj 76 40 s grain_fgrain; #X obj 13 192 r grain_fgrain; #X obj 91 254 /; #X floatatom 91 273 2094.75; #X text 119 247 phasor amp in samples; #X obj 399 132 t b f; #X connect 0 0 18 1; #X connect 1 0 71 0; #X connect 1 1 71 1; #X connect 2 0 67 0; #X connect 3 0 15 0; #X connect 4 0 69 0; #X connect 5 0 6 0; #X connect 5 0 12 0; #X connect 6 0 21 0; #X connect 6 0 21 1; #X connect 7 0 19 0; #X connect 8 0 6 1; #X connect 9 0 16 0; #X connect 9 0 60 0; #X connect 10 0 27 0; #X connect 11 0 18 0; #X connect 11 0 23 0; #X connect 13 0 12 0; #X connect 15 0 17 1; #X connect 16 0 15 0; #X connect 17 0 22 0; #X connect 18 0 17 0; #X connect 19 0 20 0; #X connect 20 0 8 0; #X connect 22 0 5 1; #X connect 23 0 5 0; #X connect 24 0 5 0; #X connect 25 0 11 0; #X connect 26 0 29 0; #X connect 27 0 26 0; #X connect 28 0 63 0; #X connect 29 0 28 0; #X connect 31 0 57 0; #X connect 32 0 7 0; #X connect 35 0 34 0; #X connect 36 0 34 0; #X connect 37 0 38 0; #X connect 38 0 42 0; #X connect 38 0 3 1; #X connect 40 0 15 0; #X connect 42 0 45 0; #X connect 45 0 52 1; #X connect 51 0 3 0; #X connect 51 1 52 0; #X connect 51 2 40 0; #X connect 52 0 15 1; #X connect 55 0 54 0; #X connect 55 0 56 0; #X connect 56 0 7 0; #X connect 59 0 65 0; #X connect 60 0 59 0; #X connect 63 0 2 0; #X connect 65 0 63 0; #X connect 65 1 63 1; #X connect 66 0 59 0; #X connect 66 0 51 0; #X connect 66 0 74 0; #X connect 67 0 71 0; #X connect 70 0 25 0; #X connect 70 0 1 0; #X connect 71 0 72 0; #X connect 72 0 0 0; #X connect 74 0 45 0; #X connect 74 1 45 1; - - ] -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 1

test
by oswald berthold 26 Mar '98

26 Mar '98

VICTIM IN A VACUUM

1 0

Re: bug report: array resize
by Miller Puckette 24 Mar '98

24 Mar '98

On Mar 24, 12:48am, Larry Troxler wrote: > > I've had instances of segmentation faults when resizing an array. > > I suspect this happens when an array is downsized while a tabread4~ > object is running, resulting in newly invalid refrences when the > tabread4~ runs its next slice. > > I must admit to not not having narrowed this down with test cases, but a > quick scan of the code shows no evidence that this situation is not > handled. If I'm wrong I'll buy a beer ... > Well, there's probably a bug in there somewhere, otherwise it wouldn't crash (tautology!) but the situation was supposed to be handled by the if (x->x_usedindsp) canvas_checkdsp(); in array_resize(). Perhaps the check doesn't actually do anything though... Miller

1 0

What is the "symbol" menu selection for?
by Larry Troxler 24 Mar '98

24 Mar '98

What is this supposed to do? It appears to bring up a number box, without allowing entering anything in it? Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

bug report: array resize
by Larry Troxler 24 Mar '98

24 Mar '98

I've had instances of segmentation faults when resizing an array. I suspect this happens when an array is downsized while a tabread4~ object is running, resulting in newly invalid refrences when the tabread4~ runs its next slice. I must admit to not not having narrowed this down with test cases, but a quick scan of the code shows no evidence that this situation is not handled. If I'm wrong I'll buy a beer ... And of course, this is only a minor bug if the cause is known, because the workaround is easy, just turn off dsp before resizing, which in most cases is the only thing that makes sense anyway. Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

Re: PD <-> Common Music interface?
by Miller Puckette 23 Mar '98

23 Mar '98

I would definitely write objects in CM to talk to the netreceive and netsend objects in PD. This would also have the advantage of talking with anything _else_ that talked the same protocol. By the way, the current implementation of netsend() unfortunately blocks when sent a "Connect" request; Harry Castle has sent me some code which should improve its behavior which I hope to incorporate soon. One of my background projects is to see if the netreceive/netsend paradigm can replace MIDI as a real-time communication standard for studio and stage. Imagine a keyboard with an ethernet connection which sends out messages like "key 60 64;" ...

1 0

Re: symbols versus strings ? writing route
by Miller Puckette 23 Mar '98

23 Mar '98

In response to Winfried's questions about route: >if a a string is for example "int", a used symbol, than route_symbol(...) seg_faults, because pd_float is used for calling route_symbol(..) with wrong arguments, because the route_symbol(...) is registered as c_floatmethod. ... so you always have to write the "float", etc, methods as special cases. As a first cut, you can just have the "float" and "bang" method call the "anything" method with the arguments re-assigned, as in route_float(t_route *x, t_float f) { t_atom arg; atom_setfloat(&arg, f); route_anything(x, &s_float, 1, &arg); } >So the string "int" or "float" matches all numbers. Lists, which in fact are lists beginning with numbers not strings, are handled correctly. Lists with beginning strings are handled as methods --- is this correct ? Yep. In a message box, you have to say "list" explicitly if the list starts with a symbol; otherwise the symbol is taken as a selector instead of "list". >So the my idea of route (to be compatible in future with real route) could be that "float", "int" routes all integers and floats, which are not in a list, (route should be fast, since, in my experience with max, it is often used for sending synthesis parameters and has to handle high data-rates) I think you don't have to treat numbers and symbols in the same object; it just complicates the thing and you can always put a "number" route on the "list" output of a "symbol" route if that's what you need. Cheers Miller

1 0

Message bug with $ args?
by Larry Troxler 23 Mar '98

23 Mar '98

On my Linux system running PD 0.21, the following patch fails; there seems to be a problem with the Message object interpreting non-numeric $-variables. If the contents of the message box is changed from "foo" to a number, it works. -- snip -- #N canvas 0 0 174 142 8; #X obj 96 6 r a; #X obj 98 36 print a:; #X msg 41 50 \; a \$1; #X msg 37 19 foo; #X connect 0 0 1 0; #X connect 3 0 2 0; -- snip -- Larry -- Larry Troxler -- lt(a)westnet.com -- Patterson, NY USA --

1 0

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 March 1998