Pd-list January 2010

pd-list@lists.iem.at

127 participants
208 discussions

ppc/linux build issues..
by dmotd 22 Jan '10

22 Jan '10

hi there.. running linux on a powerpc (old powerbook g4), pd-0.42-5 fails to compile (success with older pd-0.41-1, failure with pd-gui-rewrite). any clues? error follows: --- $ make cc -g -O2 -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -DDL_OPEN -DPA_USE_OSS -DUNIX -DUNISTD -DUSEAPI_OSS -fno-strict-aliasing -DPA_USE_ALSA -DUSEAPI_ALSA -O6 -funroll-loops -fomit-frame-pointer -D_LARGEFILE64_SOURCE -DINSTALL_PREFIX=\"/usr/local\" -c -o ../obj/s_audio_alsa.o s_audio_alsa.c s_audio_alsa.c: In function ‘alsa_send_dacs’: s_audio_alsa.c:472: error: called object ‘stderr’ is not a function s_audio_alsa.c:472: error: expected ‘)’ before ‘;’ token s_audio_alsa.c:474: error: too few arguments to function ‘fprintf’ s_audio_alsa.c:474: error: expected ‘;’ before ‘}’ token s_audio_alsa.c:584: error: called object ‘stderr’ is not a function s_audio_alsa.c:584: error: expected ‘)’ before ‘;’ token s_audio_alsa.c:586: error: too few arguments to function ‘fprintf’ s_audio_alsa.c:586: error: expected ‘;’ before ‘}’ token make: *** [s_audio_alsa.o] Error 1 --- $ gcc -v Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=powerpc --with-cpu=powerpc --disable-altivec --without-altivec Thread model: posix gcc version 4.4.2 (GCC)

2 2

get the values of an array as a list
by Jaime Oliver 22 Jan '10

22 Jan '10

Hi all is there a pd-vanilla way to get the values of an array as a list? thx, J -- Jaime E Oliver LR joliverl(a)ucsd.edu www.realidadvisual.org/jaimeoliver www-crca.ucsd.edu/ www.realidadvisual.org 858 750 0924 (cel) 858 202 1522 (home) 9168 Regents Rd. Apt. G La Jolla, CA 92037 USA

5 14

Convolution / Impulse Response
by Solen Music 22 Jan '10

22 Jan '10

Hi, A quick search has led me to believe that partconv~ is a good way to explore impulse response reverbs in pure data. Has anybody compiled this for windows? ...or are there any other options that I should explore for that platform? Thanks in advance, as always! -- John http://www.myspace.com/solenband

4 4

pd-gui-rewrite testing
by Rich E 22 Jan '10

22 Jan '10

Hi List, Hans, I've been using the pd-gui-rewrite-0.43 svn for a couple days now and here are some notes I've taken when finding various bugs (is the better sent to the pd-dev list?): • In Audio Settings, the text in the drop down menus is hardly visible because it is very light grey • there is a new menu item called 'apple' with "about pd" and preferences" • editing an object name: ‣ moving with arrows adds a space to the end, but does not move within the object name • opening "about pd" gives an error: ‣ Error: can't read "pd_myversion": no such variable" ‣ an't read "pd_myversion": no such variable can't read "pd_myversion": no such variable while executing "regsub -all PD_VERSION $bigstring2 $pd_myversion bigstring3" (procedure "::pd_menucommands::menu_opentext" line 15) invoked from within "::pd_menucommands::menu_opentext "$dirname/$basename"" (".txt" arm line 1) invoked from within "switch -- [string tolower [file extension $basename]] { ".txt" {::pd_menucommands::menu_opentext "$dirname/$basename" } ".c" {::..." (procedure "menu_doc_open" line 4) invoked from within "menu_doc_open doc/1.manual 1.introduction.txt" (menu invoke) I have some time on my hands now that I finished my Master's, and frankly I think the pd-vanilla GUI is unpleasant, so I could learn tcl/tk and help out, if needed. rich

3 14

Help installing pd-extended
by David 22 Jan '10

22 Jan '10

Hi! I'm trying to install pd-extended 0.41.4 on an Asus Eee PC running Xandros Linux (derived, I believe, from Debian etch). I used to have an earlier version of pd (0.39.2-4) installed, but would like to install pd-extended. I downloaded the package 'Pd-0.41.4-extended-debian-etch-i386.deb' and tried to install it, but I'm getting the following error message: "The following packages have unmet dependencies: pd-extended: depends on liblame0 (>= 3.97)" I searched the archive and found several messages about this missing package and another one that's supposed to replace it, but I still not sure what to do. I downloaded 'liblame0_3.97-0.0_i386.deb' and tried to install it, but I just got this message: "Cannot install package liblame0_3.97-0.0_i386.deb. Please, check your installation and try again." What do I do now? I can go back to the older version of pd, but I'd rather not. Thanks.

3 3

Re: [PD] Convolution / Impulse Response
by Matt Barber 21 Jan '10

21 Jan '10

I used to have a set of abstractions that did this. I threw it together on a whim, it wasn't all that efficient, and I haven't tested it in a couple of years... it would need a total revamp to be usable even for teaching because the constituent abstractions are not documented and not altogether straightforward. Anyway, I think you can copy the contents of an impulse-response array to several smaller arrays (the partitioning) using dynamic patching, then do fft-convolution with the incoming signal and the contents of the array (using [tabreceive~]), and then delay each separate signal by the appropriate amount (taking block delay into account) so that the aggregate produces the original impulse response convolved with the input. I think you might be able to get a bonus in efficiency if you do the partitioning into the following array sizes: 64 64 128 128 256 256 512 512 etc. Then you can avoid having more than a 64-sample-block delay overall, because the block delay associated with each set of larger arrays will be just enough to collect enough samples to compute the fft, do the mulitplication and ifft, and output the result. You might even be able to build in a buffer by doing: 64 32 32 64 64 128 128 256 256 512 512 etc. This should give extra time to compute the fft->mult->ifft I think I had built in an optional maximum fft size, so that at some point it would just continue to partition into, say, 8192-sample chunks. I had been thinking about doing the first block as a direct convolution for no overall delay, but I couldn't decide whether it would be worth it from the standpoint of efficiency... anyway, I couldn't get it to work without dropouts for a response of more than about 2 seconds long. Matt > > is it possible to do something vaguely similiar in vanilla pd? >

1 0

Re: [PD] 'synced' number and slider
by Matteo Sisti Sette 21 Jan '10

21 Jan '10

Hi, I haven't read the pd-list for a few days so I reply to this a bit late. Hope not too much. Usually, not only I want a number and a slider (and maybe more) to remain always "synced", but also to "respond" to any variation of the value they control when it is changed from other sources. I know this is not very clear so I will illustrate it with an example. Say for example you want to control the volume (meaning the gain) of something. We have: - a slider for controlling that volume - a number box controlling the same volume - the same volume can be controlled via midi - some object in the patch modifies that volume automatically (for example it changes adaptively relative to the volume of something else). So, first of all we assign this volume a name, e.g. "st-volume" (something's volume). Somewhere there will be a [r st-volume] whose outlet will trigger the piece of patch that implements the volume thing (i.e. modulate the amplitude of some signal with the received value). We want: 1) That when you move either the number box or the slider by hand, a message is sent to "st-volume" with the value output by the gui element you're moving 2) That all the gui elements associated with this volume move together 3) To be able to create an abstraction or subpatch or whatever, that receives midi data and "forwards" it to "st-volume". When you do this, you don't want to worry about the existence of the numberbox and sliders to keep them synced. You just use a [s st-volume] or [; st-volume ...( 4) To do the same to create any piece of patch that changes that volume. Indeed the midi thing is just an example and points 3 and 4 are the same thing Basically our number box and slider (ther may be even more that one number box and more than one sliders, e.g. in different windows/places, of different sizes etc, all linked) must work both as controllers and as monitors. But this MUSTN'T be a source of headaches when designing the whole patch (to ensure the syncing, and to avoid loops). So, "my" solution is an abstraction and a convention. The abstraction, I call it [control_element], is like this: -------- control_element abstraction ---------------- [r $1-ifsend] | [s $1] [r $1] | [list prepend set] | [list trim] | [s $1-ifreceive] ------------------------------------------------------ And the convention is that: 1) all numberboxes or sliders (or whatever interface elements, e.g. toggles or radio's) that have to be 'linked' to a control named <controlname> will have their send- and receive-symbols set to: <controlname>-ifsend <controlname>-ifreceive ("if" stands for "interface", not conditional "if") 2) While I can place as many such interface elements as I want, for a given control there must be one and only one [control_element <controlname>] So in our example, we put somewhere a: [control_element st-volume] and we configure our slider(s) and number box(es) to send to st-volume-ifsend and receive from st-volume-ifreceive Et voilÃ . Note that the same abstraction works for symbols as well as numbers. You may even use it for lists if you implement some gop-abstraction that is capable of receiving a message "set cis boom bash" and displaying the "cis boom bash" list somewhere (e.g. by joining the symbols with blank spaces and using a canvas' label) When using the gui to control manually the value, the first half of the abstraction "forwards" the messages coming from the gui elements to the destination. The second half does the opposite: when the value is changed with a message sent to the target, it catches it and set the gui elements to show that. Note that in the case of using one of the gui objects to change the value, the objects receives a redundant, useless "set" messages that tell it to update to the value that it has just generated. However, this is harmless and doesn't create an infinite loop. Let me know if my explanation is not clear or you need an example patch. Bye m. --- On Sat, 1/16/10, IOhannes zm?lnig <zmoelnig(a)iem.at> wrote: > > From: IOhannes zm?lnig <zmoelnig(a)iem.at> > > Subject: Re: [PD] 'synced' number and slider > > To: "Lorenzo" <lsutton(a)libero.it> > > Cc: pd-list(a)iem.at > > Date: Saturday, January 16, 2010, 11:36 AM > > Lorenzo wrote: >> > > This seems trivial but I've never managed to figure > > out how to do it in >> > > a non-trivial way: >> > > >> > > Have a number (atom) and a slider (be it horizontal or > > vertical) which >> > > are 'synced', that is if one changes the number the > > slider changes and >> > > vice-versa. > > > > > > if you use numberbox2 as the numberbox, you can give both > > the nbx and > > the slider the same send/receive names > > (that is: > > numberbox2.sendname=numberbox2.receivename=slider.sendname=slider.receivename) > > > > and they will be magically linked to each other. > > > > to use the value in the patch add another receiver > > [r <samereceivename>] > > Except if you need to send a value to the inlet of the numbox2 or the slider. Then this method magically doesn't work, whereas the [set $1( idiom does. -- Matteo Sisti Sette matteosistisette(a)gmail.com http://www.matteosistisette.com

1 0

Re: [PD] get the values of an array as a list
by Matt Barber 21 Jan '10

21 Jan '10

I don't know if this is relevant, but I thought that since it came up I would mention that you can get the size of an array with expr: [symbol arrayname( | [expr size("$s1")] should do it. Matt > > My little participation :) > A small modification of [list-tabdump] is 40% faster than the original > (avoiding to send everytime the new list from [list append] in [list]). > ++ > > Jack > > > > Le jeudi 21 janvier 2010 ? 13:53 +0100, Roman Haefeli a ?crit : >> Am 21.01.10 09:57 schrieb "William Brent" unter <william.brent(a)gmail.com>: >> >> > But is there something in Pd-ext that does this? There must be, >> > right? An external is waaaaaaaay faster for long arrays. >> >> An external will always be faster. However, the patching method still can be >> optimized a lot. [list-tabdump] copies the same data back and forth and the >> number-of-elemts/cputime ratio is not linear, but something like >> 'exponential' (please someone put here the correct term). Attached is a >> benchmark patch, that compares [tabdump], [list-tabdump] and a patched >> vanilla version, that has a linear ratio, which makes it a lot faster than >> [list-tabdump], especially with big arrays (though it is still 10 times >> slower than [tabdump]). >> >> Roman >> >

1 0

[PD-announce] [many]
by Mathieu Bouchard 21 Jan '10

21 Jan '10

Hans-Christoph Steiner wrote: > Looks quite nice. Is it necessarily part of Gridflow? Yes. > Seems like it would be generally useful, not only for video stuff. GridFlow is not only for video stuff. It's never been only for video stuff. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

RJDJ, comport, Pd on iPhone, serial communication
by David NG McCallum 21 Jan '10

21 Jan '10

Hi there list, I'm looking at doing a project prototype where the audio system is on the iPhone, and it interfaces with an Arduino through serial. I'm assuming since RJDJ is a working version of Pd, I could just use it as the engine for this stage of the prototype. Does the [comport] object work in RJDJ and can it communicate with the external serial port on the iPhone? And if the answer is "no" or "yes, but," what are my other options for using Pd on the iPhone and communicating with the serial port? Thanks! Cheers, David -- __ _ _ _ __ _ http://sintheta.org

7 13

← Newer
1
...
6
7
8
9
10
11
12
...
21
Older →

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 January 2010