Pd-list February 2007

pd-list@lists.iem.at

148 participants
295 discussions

Re: metro vs. samm~
by Eric Lyon 19 Feb '07

19 Feb '07

> > If you're worried by metro's irregularity then you should use Eric > > Lyons' samm~ (sample accurate multiple metronomes). This is > > described in > > http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-ICMC2006.pdf > > Note that samm~ is almost exactly as sample-accurate as Pd's metro. I > tried to illustrate this in attached patch. samm~ however is also > available for Max, where the metro according to Eric's paper is not as > accurate as the one in Pd, so if you need to move patches between both > systems, samm~ is a good choice. Of course Eric's system has some > convenient extensions to generate polyrhythms etc., but timing alone > IMO is no reason to exchange [metro] with [samm~] on Pd. > Cool patch, Frank. Note though that by converting the click signal from samm~ into a bang, you are rounding it to the nearest vector. As I showed in my demo at LAC, I can make metro perform poorly in a subpatch with a very large blocksize (say 4096), but samm~ will perform the same irrespective of blocksize. It is true that samm~ and friends were originally written for MaxMSP to deal with its problematic event-level timing. OTOH as my paper points out, Pd's audio thread is more susceptible to interruption from GUI events than MaxMSP. In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering, particularly with the soundfile player called player~ which I think has some nice features. Best, Eric > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > > > ---------- Forwarded message ---------- > From: Frank Barknecht <fbar(a)footils.org> > To: pd-list(a)iem.at > Date: Sun, 18 Feb 2007 14:01:08 +0100 > Subject: Re: [PD] Dynamic patching questions > Hallo, > Alexandre Quessy hat gesagt: // Alexandre Quessy wrote: > > 3) Is the use of [namecanvas $0] recommended or totally deprecated ? > > if you want to edit the content of subpatches I'd say it's totally > deprecated because it's completely unnecessary, as every subpatch has > its own receiver "pd-subpatchname" builtin. This also works for > subpatch names containing $0 as: "pd-$0-subpatchname" > > > 4) Where can I find an abstraction or object to convert any familiar > > representation of colors to the Tk colors (or whatever is used for GUI > > objects) ? > > E.g. here: > http://lists.puredata.info/pipermail/pd-list/2006-03/036005.html > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > > > > > ---------- Forwarded message ---------- > From: Yves Degoyon <ydegoyon(a)free.fr> > To: Alexandre Quessy <listes(a)sourcelibre.com> > Date: Sun, 18 Feb 2007 16:16:17 +0100 > Subject: Re: [PD] Google Summer of Code > > > > > http://r23.cc/interface/ is a very nice example of audio streaming > > with server-side Pd. > > hum, there is an update on this, the new map component is there : > http://gollum.artefacte.org/mapuse/map.html > > the map itself is not pd, but some emitters ( radios ) use pd patches > to link this to a netjuke database that enables > to make playlist and programation. > > so, r23 itself uses pd, but the global infrastructure ( http://giss.tv ) > allows to use any software to stream ( Muse, IceS, libshout, ... ) > > cheers, > sevy > > > > > > ---------- Forwarded message ---------- > From: Jamie Bullock <jamie(a)postlude.co.uk> > To: marius schebella <marius.schebella(a)gmail.com> > Date: Sun, 18 Feb 2007 15:21:30 +0000 > Subject: Re: [PD] Re: infinite composing > On Sat, 2007-02-17 at 19:19 -0500, marius schebella wrote: > > the call is written in a way that makes me think, that the producers > > don't know to much about what is going on in the world... > > but maybe the reason is, that there is no such thing as a kiosk mode or > > a protection from changing the patch in pd. > > There was a patch submitted by IOhannes to do this: > > https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1529010&group_… > > Jamie > > > > > --===============0388656242==-- > _______________________________________________ > PD-list mailing list > PD-list(a)iem.at > to manage your subscription (including un-subscription) see > http://lists.puredata.info/listinfo/pd-list > > >

5 10

Re: metro vs. samm~
by Eric Lyon 19 Feb '07

19 Feb '07

> > It's not the [metro] that is shaky in your patch, it's the > [impulse~]! Attached variation proves this. Impressive - thanks! Pd's messages come in two kinds: regular, GUI-generated messages and > so called "clock-derived" messages. The time objects in Pd like metro, > delay, pipe etc. all generate clock-derived messages. Their timing is > not affected by dsp-blocks at all. > > However, and now comes the important trick: DSP objects need to do > some extra work to make use of the accurate timing of clock-delayed > messages, when converting these messages to audio signals. So far, the > only object that does this is vline~ AFAIK. You may want to have a > look at its source to check out what needs to be done to convert from > control messages to signals with accurate timing. I better do that so I can fix impulse~. Arrrggh. Eric

1 0

cange for symbols/lists?
by Dafydd Hughes 19 Feb '07

19 Feb '07

Hi everybody Am I extra stupid this morning? Is there a version of [change] that deals with symbols or lists or a way of accomplishing this? My brain is just shutting down... cheers dafydd -- www.sideshowmedia.ca skype: chickeninthegrass

5 5

Re: metro vs. samm~ (Frank Barknecht)
by Eric Lyon 19 Feb '07

19 Feb '07

> > Cool patch, Frank. Note though that by converting the click signal > > from samm~ into a bang, you are rounding it to the nearest vector. > > Hm, I actually only used click2bang~ to be able to do measurements > with [timer]. In attached patch I removed that part, so the impulses > are directly recorded to samm.wav. It still is in sync with [metro]. > It can only be off by the blocksize which I believe is 64 samples in the default. So, I wonder if your patch graphic shows that level of accuracy? But even in that case, it might just be lucky that they line up. > > As I showed in my demo at LAC, I can make metro perform poorly in a > > subpatch with a very large blocksize (say 4096), but samm~ will > > perform the same irrespective of blocksize. > > But weren't you showing this only for Max? Pd's [metro] doesn't care > about the blocksize at all. > I showed it for both programs. According to my experimentation blocksize can make a big difference for metro in both Pd and MaxMSP. Please see if you have the same result: #N canvas 795 77 454 304 10; #N canvas 537 201 482 454 shaky 0; #X obj 113 158 block~ 8192; #X obj 334 229 adsr~; #X obj 346 273 *~; #X obj 344 306 outlet~; #X obj 112 96 inlet; #X obj 236 74 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 242 119 metro 500; #X obj 355 120 samm~ 120 1; #X obj 273 172 impulse~; #X obj 273 210 adsr~; #X obj 181 223 osc~ 440; #X obj 217 253 *~; #X obj 195 302 outlet~; #X obj 267 243 osc~ 567; #X obj 323 72 loadbang; #X msg 243 36 1; #X connect 1 0 2 1; #X connect 2 0 3 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 9 0 11 1; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 5 0; #X restore 145 90 pd shaky; #X obj 146 143 *~ 0.1; #X obj 146 229 dac~; #X obj 211 143 *~ 0.1; #X msg 109 40 set 8192 1 1; #X msg 234 34 set 64 1 1; #X obj 214 188 *~ 1; #X obj 282 134 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 293 110 listen to samm~; #X obj 124 183 *~ 1; #X obj 100 146 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 17 124 listen to metro; #X text 105 22 metro is drunk; #X text 236 15 metro more sober; #X obj 323 210 loadbang; #X msg 322 235 1 0; #X obj 323 260 unpack 0 0; #X connect 0 0 1 0; #X connect 0 1 3 0; #X connect 1 0 9 0; #X connect 3 0 6 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 2 1; #X connect 7 0 6 1; #X connect 9 0 2 0; #X connect 10 0 9 1; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 10 0; #X connect 16 1 7 0; > > It is true that samm~ and friends were originally written for MaxMSP > > to deal with its problematic event-level timing. OTOH as my paper > > points out, Pd's audio thread is more susceptible to interruption > > from GUI events than MaxMSP. > > But aren't samm~ etc. also derived from the audio thread, because they > are signal externals? Then they should be just as shaky or solid as > the clock-derived objects metro, delay etc., shouldn't they? > I'm not convinced that metro is accurate, rather than being rounded to somewhere within the vector. The *underlying* clock of Pd's metro is certainly as accurate as samm~ (unlike for MaxMSP) but that doesn't matter if the blocksize is too big. The one vulnerability of samm~ is if the audio stream itself is interrupted. But that should never happen unless you're doing glitch music ;-) > > In addition to convenience, The benefits of samm~ come from its > > integration into a system of signal-level triggering, particularly > > with the soundfile player called player~ which I think has some nice > > features. > > Yes, it's definitely a cool collection, and I'm glad to have it in the > CVS soon. ;) > Thanks. I hope so too, but I first have to figure out how the CVS system works. Best, Eric

2 2

fader gain
by Derek Holzer 19 Feb '07

19 Feb '07

I've been using the following to control the output volume of a channel from my MIDI faders: [ctlin 7 1] (in from faderbox) | [* 0.787402] (scale 0-127 to 0-100) | [dbtorms] | [pack 0 50] | [*~] (multiplied by sound from channel) I know that this is the "mathematically" correct way to do decibels to RMS, but it doesn't sound right. The bottom 2/3rds of the slider are almost silent, then the sound comes in very loud at the top. What other kind of setup are people using to control gain? d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 172: "Use `unqualified' people"

7 12

nogui and compute audio
by Richard Lewis 19 Feb '07

19 Feb '07

Hey there, I'm just moving my PD code onto my (headless) server where I want it to run with no GUI (it uses OSC for input messages and outputs to Icecast). Currently I'm not getting any output from it. I've tried replacing the mp3cast~ with a simple dac~ and plugging some speakers into the server machine as a debugging test but I still don't hear anything. I'm starting PD like this: # pd -rt -oss -nogui mixer-mp3cast.pd & (its version 0.40 provided with Debian "unstable" and version 0.39 of pd-extended). I then remembered the "compute audio" switch in the GUI. Does an equivalent action have to be performed for PD running without a GUI? If so, does anyone know what it is? Cheers, Richard -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis Sonic Arts Research Archive http://www.sara.uea.ac.uk/ JID: ironchicken(a)jabber.earth.li -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

2 1

Re: [PD] Wiimote external for Linux
by Mike Wozniewski 19 Feb '07

19 Feb '07

There's a list of compatible Bluetooth devices here: http://www.wiili.org/index.php/Compatible_Bluetooth_Devices I use a D-Link (DBT-120), which works great. The Bluetooth chip in the Wiimote is a Broadcom BCM2042 (http://www.broadcom.com/products/Bluetooth/Bluetooth-RF-Silicon-and-Softwar…). Maybe you can get some more details on the product page about range, etc. Cheers, -Mike patrick wrote: > great work mike! > > i am running linux, but i don't have bluetooth. do you have any > recommandation for an usb bluetooth key that's working on linux? is > there spec like distance (power) and stuff that i should consider? > > really again thanks in advance for your release of other externals > (openscenegraph and such). > > pat

2 2

Noop message.
by David F. Place 19 Feb '07

19 Feb '07

Maestri: I would like a special message (let's call it "noop") which when sent does nothing. (That is to say, sending it would be like not sending it.) This would be useful in automation. For instance, I may have a program which generates a bunch of events which I will trigger using [textfile]. Some of the fields will not be updated in a given event. In that case, it would like to be able to write "noop" in that field. Surely such a thing exists and I haven't found it yet. Feel free to berate me if it is right under my nose. Cheers, David --o-------o-o-o---o-o-o--- David F. Place mailto:d@vidplace.com

6 15

Re: pix_film more questions (Roman Haefeli)
by schiemer＠uow.edu.au 18 Feb '07

18 Feb '07

If you're worried by metro's irregularity then you should use Eric Lyons' samm~ (sample accurate multiple metronomes). This is described in http://www.sarc.qub.ac.uk/~elyon/LyonPapers/SampleAccurate-Lyon-ICMC2006.pdf

4 6

Re: [PD] Noop message.
by David F. Place 18 Feb '07

18 Feb '07

Yes, thanks. That's exactly what I want. Pd is full of surprises! On Feb 18, 2007, at 10:21 AM, pd-list-request(a)iem.at wrote: > Date: Sun, 18 Feb 2007 20:28:48 +0900 > From: "hard off" <hard.off(a)gmail.com> > Subject: Re: [PD] Noop message. > To: "Chuckk Hubbard" <badmuthahubbard(a)gmail.com> > Cc: pd-list(a)iem.at > Message-ID: > <161320dd0702180328t4354b416xc03beceb9d886a64(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > quick edit to make no errors (i hope!) > > i mainly like this thread cos it has given such life to the word > 'noop' ;) >

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
30
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 February 2007