Pd-list March 2010

pd-list@lists.iem.at

152 participants
270 discussions

Re: [PD] expr size() refuses some array names
by Derek Holzer 27 Mar '10

27 Mar '10

I agree with Matteo...could you please elaborate on the relevance of [value] to the particular problem he is trying to solve? D. On 3/27/10 9:25 PM, colet.patrice(a)free.fr wrote: > yes, but it takes [value foo] variable > ----- Mail Original ----- > De: "Derek Holzer"<derek(a)umatic.nl> > À: "colet patrice"<colet.patrice(a)free.fr> > Cc: "pd-list"<pd-list(a)iem.at>, matteosistisette(a)gmail.com > Envoyé: Samedi 27 Mars 2010 21h21:18 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne > Objet: Re: [PD] expr size() refuses some array names > > Yes, I was going to say next that [expr] doesn't take $1 or $0, it takes > $f1, $f2 etc etc. That's why it won't create. > > D. > > On 3/27/10 9:17 PM, colet.patrice(a)free.fr wrote: >> hello, you can use [value foo] and [expr foo*$f1] when they are in the same patch, [expr foo] wont work in another one, like with block~, that's why you won't need $0 > >> ----- Mail Original ----- >> De: "Derek Holzer"<derek(a)umatic.nl> >> À: "Matteo Sisti Sette"<matteosistisette(a)gmail.com>, "pd-list"<PD-list(a)iem.at> >> Envoyé: Samedi 27 Mars 2010 21h06:35 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne >> Objet: Re: [PD] expr size() refuses some array names >> >> Sorry, meant this in second example: >> >> [bang< >> | >> [f $0] >> | >> [expr size("$0foo")] >> >> But you probably knew that! >> >> D. >> >> On 3/27/10 9:04 PM, Derek Holzer wrote: >>> What if you bang a [f $1] and send it to [expr size("$1foo")]? >>> >>> Likewise with "bang"--->[f $0]--->[expr size("$0foo")]? >> >> >> > -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 10: "Allow an easement (an easement is the abandonment of a stricture)"

1 0

Re: [PD] expr size() refuses some array names
by Matt Barber 27 Mar '10

27 Mar '10

Here's the proper way to do it: [symbol $0-foo] | [expr size("$s1")] substitute anything that outputs the symbol (with the symbol selector) that you want -- [makefilename], etc. Matt > Last option would be to try using [sprintf], [makefilename] or similar > to create the array name, and send to [expr size($1)] . Maybe.... > > Prost! > D.

1 0

Re: [PD] Weird [delread~] behavior under -nogui
by Matt Barber 27 Mar '10

27 Mar '10

Right -- what I was suggesting was that the -nogui might be interfering with the implementation of the delay lines themselves, not specifically with [delread~]. Matt On Sat, Mar 27, 2010 at 2:19 PM, Florian Hollerweger <flo(a)mur.at> wrote: > Hi Matt, > > Matt Barber wrote: >> Are we sure this is a problem with [delread~]? > > I would actually argue it's primarily a problem with -nogui rather than > with [delread~]. > > I have been snooping around the archives, since Derek pointed out that > he posted the same issue to the list about a week ago, and it seems he > observed the same problem also with other objects under -nogui: > >> The way I remember it, anything to do with tables or other allocated >> memory can break with -nogui. [tabwrite~], [tabread~], [delwrite~], >> [delread~], [vd~] etc etc.... > > In response, IOhannes suggested that > >> there are known problems initializing the sound system in nogui-mode. > > I was not suggesting that [delread~] was buggy, but wanted to learn more > about the nature of these -nogui audio initialization problems. > > best, > flo.H >

2 1

Re: [PD] Pd-list Digest, Vol 60, Issue 114
by Florian Hollerweger 27 Mar '10

27 Mar '10

Hi Matt, Matt Barber wrote: > Are we sure this is a problem with [delread~]? I would actually argue it's primarily a problem with -nogui rather than with [delread~]. I have been snooping around the archives, since Derek pointed out that he posted the same issue to the list about a week ago, and it seems he observed the same problem also with other objects under -nogui: > The way I remember it, anything to do with tables or other allocated > memory can break with -nogui. [tabwrite~], [tabread~], [delwrite~], > [delread~], [vd~] etc etc.... In response, IOhannes suggested that > there are known problems initializing the sound system in nogui-mode. I was not suggesting that [delread~] was buggy, but wanted to learn more about the nature of these -nogui audio initialization problems. best, flo.H

1 0

bitand~ and bitor~ bitxor~
by Jonathan Wilkes 27 Mar '10

27 Mar '10

The helpfiles for the above cyclone objects has a pack object with: [pack bits 0 0 0...] Which obviously throws an error. Thing is, what is the selector supposed to be: "bits" or "list"? Thanks, Jonathan

2 1

Re: [PD] Weird [delread~] behavior under -nogui
by Matt Barber 27 Mar '10

27 Mar '10

Are we sure this is a problem with [delread~]? There's a related bug where if you open a patch which has delays at one sample rate, if you then change the sample rate in the preferences it won't reallocate the delay buffers, so if you increase the sample rate, you're left with shorter delay lines (they're just as long in samples but shorter in milliseconds). When it happens it feels like a [delread~] problem since that's what you're controlling, but really it's in the implementation of the delay buffer. This may have been fixed in recent versions -- I have been keeping at 0.40 for a while now, so I don't know for sure. Matt > > Hey Flo, > > IOhannes accused me of making this up when I posted it a week or so ago > ;-) Thanks for posting a documented example. Yes it does seem like > voodoo doesn't it? > > D. > > On 3/27/10 3:13 PM, Florian Hollerweger wrote: >> Dear list, >> >> When starting Pd with the -nogui flag, [delread~] seems to ignore its >> float input (specifying the delay time in ms) and instead produce sounds >> which resemble a [delwrite~]/[delread~] loop at very short (one block of >> audio?) delay times. >> >> Attached is a minimal example. (Attention, this will play straight to >> your soundcard at -20 dB for easy testing with -nogui!). To try, please >> start Pd first with and then without GUI. >> >> I have observed this behaviour with Pd 0.41.4 under Debian GNU/Linux. >> Anyone else who ran into trouble with this or might know what's going on? >> >> best, >> flo.H >> >> >> === BEGIN MINIMAL EXAMPLE === >> >> #N canvas 2 0 568 517 10; >> #X obj 132 359 dac~; >> #X obj 139 118 loadbang; >> #X obj 132 153 metro 1000; >> #X obj -23 386 loadbang; >> #X msg -23 441 \; pd dsp 1; >> #X obj -23 413 del 1000; >> #X obj 53 151 osc~ 220; >> #X obj 61 251 *~; >> #X msg 80 200 1 \, 0 100; >> #X obj 80 225 line~; >> #X text 330 478 Florian Hollerweger \, 2010; >> #X obj 132 330 *~; >> #X obj 205 294 dbtorms; >> #X obj 205 246 loadbang; >> #X msg 205 270 80; >> #X obj 162 220 delread~ line 350; >> #X obj -13 332 delwrite~ line 580; >> #X text 45 410<- This [del 1000] is required due to another -nogui >> bug (audio will not work under -nogui without it); >> #X text -11 88 Tested with Pd 0.41.4 under Debian GNU/Linux; >> #X text 249 272 Master volume; >> #X obj 161 332 *~; >> #X msg 164 193 500; >> #X text -10 8 -nogui bug: This patch creates a test signal on the left >> channel once a second \, which is delayed through [delwrite~] and [delread~] >> and then repeated on the right channel 500ms later. But when started >> with -nogui \, the delay time of 500ms seems to be ignored.; >> #X connect 1 0 2 0; >> #X connect 1 0 21 0; >> #X connect 2 0 8 0; >> #X connect 3 0 5 0; >> #X connect 5 0 4 0; >> #X connect 6 0 7 0; >> #X connect 7 0 16 0; >> #X connect 7 0 11 0; >> #X connect 8 0 9 0; >> #X connect 9 0 7 1; >> #X connect 11 0 0 0; >> #X connect 12 0 11 1; >> #X connect 12 0 20 1; >> #X connect 13 0 14 0; >> #X connect 14 0 12 0; >> #X connect 15 0 20 0; >> #X connect 20 0 0 1; >> #X connect 21 0 15 0; >> >> === END MINIMAL EXAMPLE === >> >> _______________________________________________ >> Pd-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >> > > -- > ::: derek holzer ::: http://macumbista.net ::: > ---Oblique Strategy # 112: > "Magnify the most difficult details"

1 0

build zexy i386 on snow leopard
by Rich E 27 Mar '10

27 Mar '10

Anyone know how to do this? I want to get the library so >~, <~ etc. work along with pd-extended. This is how I got them before. I tried: make CFLAGS="-arch i386" LDFLAGS="-arch i386" but ld is complaining still. thanks.. Rich

2 3

Re: [PD] Reproducing the THX deep note in Pd
by Matt Barber 27 Mar '10

27 Mar '10

Table sizes in Csound are user-defined. You can also use user-defined tables in Pd with [tabosc4~]. I think what may be a little more important for the differences in sound is the fact that csound and Pd use Lagrange interpolators and supercollider uses an Hermite one for the cubic interpolation within oscillators. Matt > Pd's oscillator wave tables are 512 samples. Supercollider uses 8192 - not > sure what CSound uses. The efficiency of the SC code allows for large > sample tables and bigger FFTs, which certainly help make a 'smoother' > sound. > > It would be interesting to hear what happens with 16x larger tables in Pd. >

1 0

any mac OS terminal experts?
by Andrew Faraday 27 Mar '10

27 Mar '10

Hey All I've recently started learning Ruby (on Ubuntu 9.04), part of what I'm trying to do is control PD through ruby, using the terminal. The main trouble I'm having now is that I'm mostly using a Mac OS X machine which doesn't recognize the 'pdsend' and 'pdreceive' commands (as the linux shell does). I've tried opening the files with these names in /resources/bin which open a new terminal window and display what looks like the relevant -help text. But I can't seem to use these to send messages to and from pd from the Mac OS terminal. (in theory I could then automate this with Ruby). Any ideas, at all? _________________________________________________________________ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now http://clk.atdmt.com/UKM/go/195013117/direct/01/

8 12

Re: [PD] Local Variables in GUI Properties (receive-symbol)
by Derek Holzer 27 Mar '10

27 Mar '10

$0, $1 and all other variables should be at the beginning of the name of your variable, not the end. This is the same whether it's a send, an array or anything else. D. On 3/26/10 5:22 PM, Ben Baker-Smith wrote: > I've tested this with toggle, bang, and canvas objects. If I put $0 in > the send or receive properties everything looks fine until i close and > re-open properties, then "test-send-$0" becomes "test-send-0" and > "testreceive$0" becomes "testreceive0". At no point (before or after > closing / re-opening properties) will the objects send or receive $0 > properly. -- ::: derek holzer ::: http://macumbista.net ::: ---Oblique Strategy # 23: "Breathe more deeply"

4 3

← Newer
1
...
6
7
8
9
10
11
12
...
27
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 March 2010