Re: [PD] Noop message.
oh yeah, sorry. that's why i would use -1 or another integer instead of noop. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Noop message.
That works for floats, but again, [unpack s] won't take -1. David hasn't said much about what types of arguments he expects. -1 for floats and noop for symbols would seem to work. -Chuckk On 2/18/07, hard off [EMAIL PROTECTED] wrote: oh yeah, sorry. that's why i would use -1 or another integer instead of noop. -- http://www.badmuthahubbard.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Noop message.
This works. Ugly error messages, if that bothers you, but no messages passed on noop. -Chuckk On 2/17/07, David F. Place [EMAIL PROTECTED] wrote: 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:[EMAIL PROTECTED] ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://www.badmuthahubbard.com #N canvas 263 214 537 532 12; #X obj 114 209 unpack s s s; #X obj 312 218 unpack f f f; #X msg 92 46 15 jump 45; #X obj 75 267 route noop; #X obj 75 243 list trim; #X obj 168 317 route noop; #X obj 168 293 list trim; #X obj 216 269 route noop; #X obj 216 245 list trim; #X obj 143 403 print one; #X obj 262 405 print two; #X obj 378 396 print three; #X msg 193 48 noop 35 noop; #X obj 207 138 t a a; #X msg 308 52 56 22 noop; #X msg 341 83 booyah noop hotcha; #X connect 0 0 4 0; #X connect 0 1 6 0; #X connect 0 2 8 0; #X connect 1 0 9 0; #X connect 1 1 10 0; #X connect 1 2 11 0; #X connect 2 0 13 0; #X connect 3 1 9 0; #X connect 4 0 3 0; #X connect 5 1 10 0; #X connect 6 0 5 0; #X connect 7 1 11 0; #X connect 8 0 7 0; #X connect 12 0 13 0; #X connect 13 0 0 0; #X connect 13 1 1 0; #X connect 14 0 13 0; #X connect 15 0 13 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Google Summer of Code
On Sat, 2007-02-17 at 23:15 +0100, Georg Holzmann wrote: any suggestions for projects ? well, if you're planning to work on the pd core, i guess, it would be a good idea to contact miller in order to see, which projects he would include and which projects he would reject. imo, it would be a bad idea to spent the summer coding and in the end miller rejects the patch ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Your mind will answer most questions if you learn to relax and wait for the answer. William S. Burroughs signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Noop message.
quick edit to make no errors (i hope!) i mainly like this thread cos it has given such life to the word 'noop' ;) noop2.pd Description: Binary data ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Dynamic patching questions
or the edit subpatch of the iemgui help objects has some rgb-iemgui conversion stuff. so, basically, make a canvas, right click on it, and select help...then go into the 'edit subpatch' ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pix_film more questions
Hallo, chris clepper hat gesagt: // chris clepper wrote: On 2/17/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, chris clepper hat gesagt: // chris clepper wrote: The metro is not so hot in Pd either. Good luck. [metro] in Pd is hot enough to play in sync with a phasor~, see attached patch. Media handling APIs have internal clocks and it is best to use those for the most efficient playback. It is basically impossible to sync Pd or Max to one of these APIs without some tricks (GEM) or having the API drive the app (Max/Jitter). Syncing Pd's clock to other clocks of course is a difficult issue. I actually was more trying to illustrate how hot Pd's [metro] is compared to Max's [metro], which AFAIK has a lowest period of 20 msec, while Pd can go as low as 1 msec and actually could go even lower if you remove the limit in the source code (or build a metro-clone with [delay]). Even with periods that small Pd's [metro] stays tight compared to audio objects. But yes, that still doesn't make it a good choice when playing or recording video. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Noop message.
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote: That works for floats, but again, [unpack s] won't take -1. David hasn't said much about what types of arguments he expects. -1 for floats and noop for symbols would seem to work. [route noop] accepts everything and will only block, if it gets noop-messages like noop and noop blocked ... See attachement. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 0 0 616 396 10; #X obj 99 158 route noop; #X msg 86 96 noop; #X obj 99 184 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 203 71 bang; #X msg 247 69 1; #X msg 278 69 1 2 3; #X msg 326 69 list noop; #X msg 535 68 a b c; #X obj 164 234 print passed; #X obj 179 190 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 53 71 noop blocked; #X text 51 41 blocked; #X text 201 44 passed; #X msg 403 67 list noop passed; #X connect 0 0 2 0; #X connect 0 1 8 0; #X connect 0 1 9 0; #X connect 1 0 0 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 0 0; #X connect 7 0 0 0; #X connect 10 0 0 0; #X connect 13 0 0 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
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=detailatid=478072aid=1529010group_id=55736 Jamie ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: metro vs. samm~ [was: Re: [PD] Re: pix_film more questions]
On Mon, 2007-02-19 at 04:39 +, padawan12 wrote: If I understood Erics paper correctly [samm~] allows you to specify which sample of a block is set consistently, if you like a periodic version of [dirac~]. That's surely useful if you want to do somthing in the signal domain like convolution with a impulse train. What I couldn't figure, is this really equivilent to [phasor~ 0.0173474647] very accurate signal phasor hehe, i think the number format used in pd doesn't allow such a high accuracy ;-) | [=~ 0.9] floated 1.0 so we get an equivilence which should give a single sample set on the top of each phasor cycle. But I seem to remember this not working properly for some reason. not each edge of a signal generated by [phasor~] lies exactly on 1 or 0 because of the grid introduced by the samplingrate. see attached patch. roman On Sun, 18 Feb 2007 13:53:52 +0100 Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, [EMAIL PROTECTED] hat gesagt: // [EMAIL PROTECTED] wrote: 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. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 736 523 450 300 10; #X obj 74 166 tabwrite~ array; #X obj 60 124 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 95 210 table array 40; #X msg 184 74 44100; #X floatatom 62 37 5 0 0 0 - - -; #X obj 184 98 / 8; #X obj 65 7 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 7100 1; #X obj 88 125 phasor~; #X obj 184 45 loadbang; #X msg 143 77 7237; #X text 232 71 - choose frequency; #X text 212 10 - set phase; #X text 211 211 - watch signal; #X connect 1 0 0 0; #X connect 3 0 5 0; #X connect 4 0 1 0; #X connect 4 0 7 1; #X connect 5 0 7 0; #X connect 6 0 4 0; #X connect 7 0 0 0; #X connect 8 0 3 0; #X connect 9 0 7 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Re: metro vs. samm~
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 [EMAIL PROTECTED] To: pd-list@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 [EMAIL PROTECTED] To: Alexandre Quessy [EMAIL PROTECTED] 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 [EMAIL PROTECTED] To: marius schebella [EMAIL PROTECTED] Date: Sun, 18 Feb 2007 15:21:30 + 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=detailatid=478072aid=1529010group_id=55736 Jamie --===0388656242==-- ___ PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] cange for symbols/lists?
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: metro vs. samm~ [was: Re: [PD] Re: pix_film more questions]
Hallo, padawan12 hat gesagt: // padawan12 wrote: So another way I came up with was to use [z~] to delay a squarewave by a sample and then subtract it from itself leaving just an isolated value set to 1.0. Afair that worked okay. Nice idea. You can also just send the square through [rzero~ 1] which does this: y[n] = x[n] - a[n] * x[n-1] usind a=1 then. See att. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 0 0 562 500 10; #N canvas 0 0 450 300 square 0; #X obj 163 192 -~; #X obj 163 118 -~ 0.5; #X obj 179 146 wrap~; #X obj 179 169 -~ 0.5; #X obj 163 93 phasor~ \$1; #X obj 163 223 outlet~; #X obj 228 36 inlet; #X obj 163 36 inlet~; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 1 0 2 0; #X connect 2 0 3 0; #X connect 3 0 0 1; #X connect 4 0 1 0; #X connect 6 0 4 1; #X connect 7 0 4 0; #X restore 65 130 pd square; #X floatatom 65 102 5 0 0 0 - - -; #X obj 66 229 tabwrite~ \$0-x; #N canvas 0 0 450 300 (subpatch) 0; #X array \$0-x 100 float 0; #X coords 0 1 99 -1 200 140 1; #X restore 242 38 graph; #X msg 95 208 bang; #X obj 66 181 rzero~ 1; #X msg 65 75 1000; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 4 0 2 0; #X connect 5 0 2 0; #X connect 6 0 1 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re: infinite composing
David Powers wrote: I doubt it. Mac people seem to not give a shit that some of us are far too poor to ever afford a Mac. yeah. this is the american way of life. but seriously, I don't think that money is the problem, because actually it is not really so much more expensive. I bought a mac, because everybody I work with uses them. so it was peer pressure. and, hey, after the 3rd kernelpanic/crash this week I start to like it. lol! jitter is the reason for me to run max, and better grafic drivers for video (YUV! quicktime) is the reason to run it on a mac. and 998 arguments convince me to do everything else in pd. marius. On 2/17/07, Matteo Sisti Sette [EMAIL PROTECTED] wrote: Please note, that works must be compatible with Macintosh computers in either QuickTime, max/MSP, Flash, Firefox or Safari. If a competition allows to submit music generators made in Max/MSP, but disallows submitting music generators made in PureData, then why is such an announcement relevant to pd-announce ? While I'm not affiliate in any way to Infinite Composing, and while I do hate the fact they don't allow PD patches (and don't understand why - do they ignore that pd can run on a mac?), I guess that some pd artists may be able and willing to port their pd patches to max/msp in order to submit them to the call... ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re: metro vs. samm~
Hallo, Eric Lyon hat gesagt: // Eric Lyon wrote: 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]. 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. 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? 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. ;) Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ #N canvas 203 1 993 701 10; #X obj 89 86 samm~ 60 1; #X obj 544 157 t b b; #X floatatom 544 201 5 0 0 0 - - -; #X obj 544 84 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 544 105 metro 1000; #X obj 544 179 realtime; #X obj 612 158 t b b; #X floatatom 612 202 5 0 0 0 - - -; #X obj 612 180 timer; #X floatatom 609 28 5 0 0 0 BPM - -; #X obj 609 49 expr 6/$f1; #X msg 89 64 tempo \$1; #X floatatom 628 76 5 0 0 0 - - -; #X obj 43 422 writesf~; #X msg 186 365 open samm.wav; #X msg 21 26 resume; #X msg 76 28 pause; #X obj 505 285 vline~; #X obj 580 369 writesf~; #X msg 679 336 open metro.wav; #X msg 131 364 start; #X msg 85 360 stop; #X obj 769 493 soundfiler; #X obj 85 332 del 2000; #X msg 626 334 start; #X msg 580 330 stop; #X obj 580 302 del 2000; #X msg 781 466 read samm.wav samm.tab; #X obj 168 414 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 654 373 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 769 440 read metro.wav metro.tab; #X obj 175 64 impulse~; #X obj 85 307 t b b b b; #X obj 580 277 t b b b b; #N canvas 0 0 450 300 (subpatch) 0; #X array samm.tab 88200 float 2; #X array metro.tab 88200 float 2; #X coords 0 1 88199 -1 882 140 1; #X restore 65 528 graph; #X msg 505 263 -1 \, 0 10; #X obj 85 274 bng 24 250 50 0 empty empty record_samm 26 7 1 10 -24198 -1 -1; #X obj 580 247 bng 24 250 50 0 empty empty record_metro 26 7 1 10 -24198 -1 -1; #X text 770 404 open samm and metro recordings; #X msg 663 476 \; pd dsp \$1; #X obj 663 446 tgl 24 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X connect 0 0 13 0; #X connect 1 0 5 0; #X connect 1 1 5 1; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 4 0 6 0; #X connect 4 0 35 0; #X connect 5 0 2 0; #X connect 6 0 8 0; #X connect 6 1 8 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 9 0 11 0; #X connect 10 0 4 1; #X connect 10 0 12 0; #X connect 11 0 0 0; #X connect 14 0 13 0; #X connect 15 0 0 0; #X connect 16 0 0 0; #X connect 17 0 18 0; #X connect 19 0 18 0; #X connect 20 0 13 0; #X connect 21 0 13 0; #X connect 21 0 28 0; #X connect 23 0 21 0; #X connect 24 0 18 0; #X connect 25 0 18 0; #X connect 25 0 29 0; #X connect 26 0 25 0; #X connect 27 0 22 0; #X connect 30 0 22 0; #X connect 31 0 0 0; #X connect 32 0 23 0; #X connect 32 1 20 0; #X connect 32 2 31 0; #X connect 32 3 14 0; #X connect 33 0 26 0; #X connect 33 1 24 0; #X connect 33 2 4 0; #X connect 33 3 19 0; #X connect 35 0 17 0; #X connect 36 0 32 0; #X connect 37 0 33 0; #X connect 40 0 39 0; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
RE: [PD] Wiimote external for PC Platform
A while back there was some information posted on a PC version of the Wii controller. Can someone point me to the PC dll?? Thanks in advance. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wozniewski Sent: Monday, February 12, 2007 12:48 PM To: patrick Cc: pd-list@iem.at Subject: Re: [PD] Wiimote external for Linux 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 e-Solutions/BCM2042). 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re: pix_film more questions (Roman Haefeli)
hi i don't know to which mail you are answering, but i still believe, that pd's [metro] is absolute accurate (even sub-sample-accurate), when used in combination with [vline~] for example. the only case, where it could be considered inaccurate, is when cpu-load is too high, though when writing to a file, it is still accurate. roman On Sun, 2007-02-18 at 11:21 +1100, [EMAIL PROTECTED] wrote: 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Dynamic patching questions
On Sun, 2007-02-18 at 01:55 -0500, marius schebella wrote: try to create the gui objects with all its arguments. documentation about how to create arguments is not easy to find, but exists. maybe search the archieves. or just have a look at the pd-file with a text-editor. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] fader gain
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
hi derek, On Sun, 2007-02-18 at 23:51 +0100, Derek Holzer wrote: 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? well, i guess, this is mathematically correct, if complete silence would start at db ;) i usually scale the midi range 1 to 127 from the lowest audible sound to the loudest i want to produce, which works pretty good for my ears, except the fact, that 7 bit are just too little for an accurate volume control (at least for my ears). cheers .. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk The only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn, like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes Awww! Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Noop message.
On 2/18/07, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote: That works for floats, but again, [unpack s] won't take -1. David hasn't said much about what types of arguments he expects. -1 for floats and noop for symbols would seem to work. [route noop] accepts everything and will only block, if it gets noop-messages like noop and noop blocked ... See attachement. He wants certain fields to stay blank, not certain lists to be ignored. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- http://www.badmuthahubbard.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
Hi Derek Probably not the best solution, but to my ears, it sounds good to scale the input to 0-1 and then square it. cheers dafydd On 2/18/07, Derek Holzer [EMAIL PROTECTED] wrote: 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- www.sideshowmedia.ca skype: chickeninthegrass ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
On Mon, 2007-02-19 at 00:21 +0100, Derek Holzer wrote: i usually scale the midi range 1 to 127 from the lowest audible sound to the loudest i want to produce, which works pretty good for my ears, What range are you scaling to? 0 - 0 1 - a sound, that's barely audible 127 - the loudest sound i can't tell you exact values, since this is dependent on the kind of sound, that i'm using ... if you have a pink noise, at low volume, it may have the same energy as a 4kHz sine wave, and you hear the sine, but don't hear the noise, as it's easier hidden in the background soundscape of your studio / concert room / etc ... so, i'm just scaling to the range of my ears ;) cheers .. tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Life is really simple, but we insist on making it complicated. Confucius signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Re: metro vs. samm~ (Frank Barknecht)
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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
OK, I guess it's not such a systematic answer as I would hope for ;-) I'll go back to fiddling with my sliders now. d. Tim Blechmann wrote: 0 - 0 1 - a sound, that's barely audible 127 - the loudest sound i can't tell you exact values, since this is dependent on the kind of sound, that i'm using ... if you have a pink noise, at low volume, it may have the same energy as a 4kHz sine wave, and you hear the sine, but don't hear the noise, as it's easier hidden in the background soundscape of your studio / concert room / etc ... so, i'm just scaling to the range of my ears ;) -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 61: Don't be frightened of cliches ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
I want to point interested people to the great iem abstraction [fadtorms] and [fadtodb], in the cvs abstractions. I am using them everytime i touch a (physical) fader. lg,P Derek Holzer wrote: OK, I guess it's not such a systematic answer as I would hope for ;-) I'll go back to fiddling with my sliders now. d. Tim Blechmann wrote: 0 - 0 1 - a sound, that's barely audible 127 - the loudest sound i can't tell you exact values, since this is dependent on the kind of sound, that i'm using ... if you have a pink noise, at low volume, it may have the same energy as a 4kHz sine wave, and you hear the sine, but don't hear the noise, as it's easier hidden in the background soundscape of your studio / concert room / etc ... so, i'm just scaling to the range of my ears ;) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] cange for symbols/lists?
Hi, I think the attached patch does what you want. Chris. On Sun, Feb 18, 2007 at 12:41:16PM -0500, Dafydd Hughes wrote: 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 --- [EMAIL PROTECTED] http://mccormick.cx symbol-change-help.pd Description: application/puredata symbol-change.pd Description: application/puredata ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fader gain
On Mon, Feb 19, 2007 at 12:18:20AM +0100, Tim Blechmann wrote: the loudest i want to produce, which works pretty good for my ears, except the fact, that 7 bit are just too little for an accurate volume control (at least for my ears). But how great is that digital jumping sound you get from moving the slider too fast as Pd catches up with all the midi messages![1] 8bit tunes are so passé. 7bit ftw! ;) Chris. 1. http://www.sciencegirlrecords.com/chr15m/music/CD004/search_and_rescue.mp3 --- [EMAIL PROTECTED] http://mccormick.cx signature.asc Description: Digital signature ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Wiimote external for PC Platform
Hi Michael, I haven't explored the Wii controller on Windows that much, but the defacto method is to use GlovePIE (http://carl.kenner.googlepages.com/glovepie) and re-map the Wii data to something useable by Pd (eg, MIDI). Hope that helps, -Mike Michael Garrett wrote: A while back there was some information posted on a PC version of the Wii controller. Can someone point me to the PC dll?? Thanks in advance. Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wozniewski Sent: Monday, February 12, 2007 12:48 PM To: patrick Cc: pd-list@iem.at Subject: Re: [PD] Wiimote external for Linux 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 e-Solutions/BCM2042). 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 ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
