Pd-list June 2007

pd-list@lists.iem.at

146 participants
264 discussions

isn't the GUI supposed to have lower priority than process?
by Matteo Sisti Sette 06 Jun '07

06 Jun '07

Hi, I always thought that in PD, "process" (i.e. dsp and control processing) had the priority over GUI rendering, in such a way that drawing the gui would NEVER cause audio clicks although this means there's no warranty about how much gui rendering may be delayed. To my great disappointment, I see that when opening a subpatch with a lot of gui, audio clicks are produced. Just opening it, i.e., right-clicking on it and "open" (or just left-clicking when not in edit mode) Not to mention moving around a "big" GOP-enabled object (or, I guess, a handful of gui elements at the same time). But the first one seems to me a much more severe problem. Suppose you have a large application (for a performace, for example) with a lot of controllers and display that you may only occasionally need. So you have your main interface (i.e. most important elements you need to see all the time) in your main window, and lots of less critical displays and controllers inside subpatches or instances of abstractions. When you need to check out or move a display or controller, you click on the subpatch (or even abstraction) to show up the controllers it contains. This is just not possible because when you do that, you suddenly get a second of silence (if the subpatch you open contains more than a couple of sliders), as audio processing holds on while drawing the gui. Do you know of any workarounds? Do you know if this is Windows-specific? This is indeed another example of what I was talking about in my previous message under the "puredata evolution" thread. Thanks m. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Prestiti Online. Scopri subito se sei finanziabile. in 24 ore senza spese nÃ© anticipi, clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2908&d=4-6

7 11

Re: [PD] switch~ & cputime climbing
by martin.peach＠sympatico.ca 06 Jun '07

06 Jun '07

That looks like the old denormal problem again, where the cpu goes into some kind of exception handling when a floating point value is between zero and the next smallest full-precision float, a number like 0.000000000000000001. Martin > I'm not positive about this, but I think I've traced the CPU-climb to > the [moog~] filter. It has an odd behavior that can be broken into > three phases: > > 1) no audio greater than zero amplitude has passed through it yet (since > patch load) > 2) audio of some amplitude >0 passes through > 3) audio passing through goes back to zero amplitude > > At 3) (or, more accurately, several seconds after), its CPU usage climbs > fairly dramatically, only to drop down again when the amplitude of the > audio goes up again. Something in the filter model doesn't like zero > amplitude, but only after it's first processed something greater than zero. > > I meant to test this more rigorously, but got sidetracked. At any rate, > when I switch~ the [moog~] filter out, CPU usage holds steady. To be > clear, I don't think this relates to [switch~]. I'm on a Macbook Pro, > currently running 0.39rc2. > > Phil > > > > Derek Holzer wrote: > > Hi Phil, > > > > just to keep this in people's minds... I have exact same problem > > described in these emails with my Particle Chamber granular synthesis > > patch. It has 32 "switch~ed" voices. Using one instance seems to be > > OK, but two or more leads to exponentially-growing CPU usage that > > eventually makes PD unresponsive to the GUI (and eventually would > > probably crash PD if I let it go on...) I guess this could relate to > > the "isn't the GUI supposed to have lower priority than process?" > > thread, since this particular problem makes PD a bit unusable for the > > kind of performances I want to be doing with it. The fact that PD > > lacks a usable voice-allocation method (i.e. CPU resources can be > > allocated and de-allocated to a voice, something which switch~ has a > > bug with, and which Nqpoly~ and so on does not do at all) means that I > > must start looking into SuperCollider to work with my polyphonic > > granular synthesis stuff. Sad but true... > > > > d. > > > > Phil Stone wrote: > >> Hi, > >> > >> I'm getting a slow-but-steady climbing CPU when running some > >> synthesis patches. I (like the poster below) have sub-modules that > >> can be switch~ed on and off. An archive search turned up the > >> following un-replied post: > >>> Hi all > >>> > >>> Okay. I'm stumped. > >>> > >>> Recently, I've noticed that my cpu meter has been steadily rising. > >>> I think I may have found the culprit. > >>> > >>> A while back I thought I'd put a power switch (just a switch~ > >>> object) on my poor-man's granular delay line, as my performance > >>> patches are getting a bit bulky. > >>> > >>> Try this (if you have the time): > >>> > >>> http://www.sideshowmedia.ca/cputest.zip > >>> > >>> cputest.pd: (needs expr, but I think that's all) > >>> > >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois" > >>> off. Watch the cpu meter climb (over a period of 5 minutes or so - > >>> the toggle prints the cputime every 10 seconds). On my computer > >>> (G4 Powerbook, HCS extended 0.38.4) it starts around 5% and hits > >>> 10% after 5 minutes. > >>> > >>> 2. Do the same with "lois" on. For me, cpu hovers around 13-14%. > >>> No increase. > >>> > >>> 3. Repeat step 1. After 10-15 minutes, cputime is higher than with > >>> "lois" on. Switch "lois" on, and cpu drops. Huh? > >>> > >>> I have no idea what's going on, but am I missing something > >>> important? Thanks in advance. > >>> > >>> cheers > >>> dafydd > >>> > >> > >> Does anybody have any insight on this? I don't remember this > >> happening until fairly recently, but don't know if it dates to when I > >> started switch~ing modules. I'm currently running 0.39.2-extended > >> RC1 on a MacBook Pro. > >> > >> > >> Phil Stone > >> > >> _______________________________________________ > >> PD-list(a)iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > >> > > > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >

1 0

[Pd-announce] A Hack A Night
by moritz 06 Jun '07

06 Jun '07

ello i've made a audio / video loop machine everything with pd and gem. i will perform with my machine at this event: ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ ________________________________________________________________________ Dock18 and !Mediengruppe Bitnik present ________________________________________________________________________ A Hack a Night: An Evening of Audio-Visual Hacks Sa, 09. Juni 2007, 21:30h Dock18 - Raum für Medienkulturen, Grubenstrasse 23, Zürich A night of noise & anger, ferocious joy & serious drinking mit Eric Bünger (.se), Bob Milosevic (.yu), Sven König (.de), Moritz Wettstein (.ch), Bit-Tuner (.ch) und DJs !Nik und La Bombe (.ch) Von Schizophonia über algoryhtmische Rhytmen, Scrambled Hacks, Errrror-Musik und lowtec analog Beats zu Miami Kiev Gangster Rave werden Musik und Bilder gehackt bis uns die Tränen kommen. Willkommen zu einer Nacht voller Lärm, Wut, Freude und Getränken! Eintritt: SFr. 10.- mehr Infos: http://www.dock18.ch/ahackaday.html

1 0

[PD-announce] Human Sequencer @ NIME
by Alexandre Quessy 06 Jun '07

06 Jun '07

Hi all, I will be presenting an audio installation done in Pd at NIME. It is called the Human Sequencer. It will be at Eyebeam.org during NIME 2007 in New York ! See http://itp.nyu.edu/nime/2007/installations.php This audio game is an interactive installation for collective musical creation. The challenge is to create together as a group interesting rhythmic patterns in a giant sequencer controlled with the visitors' feet on the floor. The music is generated with voices singing the scat, a vocal jazz improvisation technique using nonsense words. This work proposes to the anonymous passers to create transitory interactions by collaboration and laughter. -- Alexandre Quessy http://alexandre.quessy.net http://www.puredata.info/Members/aalex _______________________________________________ PD-announce mailing list PD-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

Re: [PD] pd-0.38 installation
by ruth mccracken 06 Jun '07

06 Jun '07

Hello Frank, performing ldd /usr/../pd-gui, I get: ldd /usr/local/lib/pd/bin/pd-gui linux-gate.so.1 => (0xffffe000) libtk8.4.so.0 => /usr/lib/libtk8.4.so.0 (0xb7c95000) libtcl8.4.so.0 => /usr/lib/libtcl8.4.so.0 (0xb7be0000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7bd6000) libjack-0.100.0.so.0 => /usr/lib/libjack-0.100.0.so.0 (0xb7bbd000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7a7c000) libvos3gcc3.so => not found libvcl680li.so => not found libsot680li.so => not found libutl680li.so => not found libtl680li.so => not found libcomphelp4gcc3.so => not found libuno_cppuhelpergcc3.so.3 => not found libuno_cppu.so.3 => not found libuno_sal.so.3 => not found libX11.so.6 => /usr/lib/libX11.so.6 (0xb7989000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7985000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb796e000) libstlport.so.5.1 => /usr/lib/libstlport.so.5.1 (0xb78d4000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb77e9000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb77c2000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb77b6000) /lib/ld-linux.so.2 (0xb7eff000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb77b3000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb77ae000) many thanks! Ruth --------------------------------- Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search.

4 4

[PD-announce] Pd-0.39.2-extended-rc2 released!
by Hans-Christoph Steiner 06 Jun '07

06 Jun '07

http://at.or.at/hans/pd/installers.html After a long pause, it's time for another release. That means Release Candidate 2!! Almost there! Yes, there are a couple known bugs, and most definitely unknown bugs. Let's find them and make a final release! * Bitstream Vera Sans Mono is now default font on Windows and GNU/Linux * Bitstream Vera Sans Mono is included in the Windows installer * Monaco is the default font on Mac OS X * fixed GUI size, should actually be the same size on all platforms now * pdp and pidip should support quicktime/mjpeg/png and theora now * pdp_ieee1394 included on Mac OS X * the Mac OS X package looks much better, thanks to Steffen <stffn(a)dibidut.dk> * default preferences are embedded into the Pd.app on Mac OS X * revamped font flags and added '-font-weight' flag A couple of known issues: * it's still missing Gem font support on Mac OS X :( * the delread~/sqrt~ bug is still not fixed :( Test away and file bugs in the bug tracker! http://puredata.org/dev/bugtracker. .hc ------------------------------------------------------------------------ ---- All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne _______________________________________________ PD-announce mailing list PD-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

8 18

Re: [PD] isn't the GUI supposed to have lower priority than process?
by Matteo Sisti Sette 06 Jun '07

06 Jun '07

Frank wrote: > Just a note: Many people all over the world are using Pd in live > performances, which proves that it is a suitable tool for this. > That's it's not bug-free and has room for improvements is a different > story. And also: > there is not a single piece of > free software in its realm that managed to be the tool of choice for > so many people for such a long time now Now you make me feel like I have somewhat been criticising PD. :$ That wasn't my intention. I obviously love it, and use it, and choose it (every day of my life -lol-), so I do think it's the best around - or at least the best I've been able to find around. And of course it is more than "usable" and "suitable" for live performance (though I must say that what many people do never proves anything). I do use it for live performance (well, more precisely the people I work for use it for live performance, I use it at home and in their studio so that they can use it in live performance), and that's where my frustration comes from. So what the hell was my point? My point was that I do think that those issues which make it unsafe to use it in realtime (I revert to the realtime terminology because I think it is irrelevant whether it is a performance or a studio session: what is relevant is that you're doing something in real time and you have some real-time requirements) should be considered SEVERE issues. So, the recent thread about evolution, future, and roadmaps came to my mind, and I just wanted to share (and submit to criticism) my opinion that I just can't imagine any roadmap that doesn't start with solving that kind of issues, since whatever the goal is, it passes thru solving them. I am glad to see that many of you reacted with indignation when I insinuated that PD is a prototyping tool. That's the reaction I hoped to provoke. My point is that if we don't accept that PD is meant for prototyping (and I hope we don't accept it), then we should consider as a severe issue anything that prevents "trivial" or "common" or "reasonable" or "possibly desirable" operations to be performed in real time (with a decreasing degree of severity while ranging from trivial to possibly desirable). "Severe issue" doesn't mean something that decreases our trust in PD, just something that shoud have a high rank in the to-do list. Regretfully I can't contribute in any way, as my C/C++ programming skills are at the hello-world level. Now just a note. Obviously it is just great that there exists a way to load a soundfile in zero logical time: if you do it at start up and don't care about the drop-out (inaudible on a zero output), it simplifies all those operations that need to be guaranteed to be done in a certain order. Changing the behaviour of sounfiler to threaded would be a disaster for backward compatibility, and the same goes for any object that suffers from similar limitations. Alternative threaded realtime-safe objects should be provided in those cases. Regarding the question "who said that" (i.e. who said that pd is a tool for prototyping), I couldn't find the original source, but I found this in the list archive (obviously I take it out of its context): On Wed, 21 Feb 2007 Kyle Klipowicz said: > I recall a quote from Miller that paraphrased said something to the > effect that Pd is like the bash shell in UNIX. You wouldn't write a > word processor in a bash script, but it's great for rapidly > prototyping a quick and useful solution. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Fai squillare la PANTERA ROSA sul tuo cellulare: e' in REGALO Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6613&d=6-6

3 2

Re: [PD] puredata Arduino and Ping
by Marko Timlin 06 Jun '07

06 Jun '07

hi kyle hi marius, I used the different delay times in the arduino code to avoid crosstalking between the sensors. my idea was: when the arduino board checks the response of the sensor signals after different time intervals each individual sensor won´t react to signals from other sensors. but seems that this doesn`t work. is it possible to assign a different frequency to each sensor, so the sensors can be placed quite close to each other? I play them with "my hands" so they are quite close to each other, approximately around 23 centimeters of distance. Best, Marko Yes, please describe the physical configuration of the 5 sensors Marko. I am working on a similar project using 6 sensors, but we have not done much testing in our proper configuration yet. My guess is that since all the sensors are hard wired with a specific ping frequency, they will detect each other's pings when placed in close proximity. ~Kyle On 6/3/07, marius schebella <marius.schebella(a)gmail.com> wrote: > Hi, > > your code and patch look good. It is not clear to me, why you are using > these delaytimes for the different sensors. but that should not affect > your results anyway. the minimum delaytime between two measurements is > only 200microseconds. but maybe it also depends on the length of the > impulse? would it be possible, that the sensing fields of the 5 sensors > overlap, and you get the crosstalk from that? > on the other hand, it may also be possible that the problem is in your > circuit. you could try to use 10k pulldown resistors. maybe that stops > the crosstalk. > > marius. > > > Marko Timlin wrote: > > I am working with several ultra sound sensors called Ping from Parallax > > wired to an Arduino board that is connected to puredata. > > currently I am working with 3 sensors and it works fine. > > > > now I want to work with 5 sensors and the following problem occurs: > > - I get "phantom" values on sensors that are not modified: if, for example, I change the value of sensor B, sensor C also changes its values, not exactely syncronized but it jumps to a simlar value range. very annoying indeed. > > is that a problem of my script for arduino or a problem of pd? > > does anybody already have experience with such a configuration? > > I am using Pd version 0.39.2-extended-RC1 on windows xp. > > > > attached you find the arduino and pd patch for that idea. > > > > thanks, > > marko > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PD-list(a)iem.at mailing list > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > PD-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > -- ----- ------------ ---- ----- ---- -------- - ------ http://perhapsidid.wordpress.com

2 1

PD piece at NIME
by dak2＠uwm.edu 06 Jun '07

06 Jun '07

Hello, On Saturday, June 9th at the Galapagos Art space Mr. Kevin Schlei will be performing his piece, Drop, at 9:00 o'clock. The piece uses a live microphone capturing the sound of dripping water and processes these sounds in a PD patch. The piece also uses the GEM environment to generate a real-time color wheel that changes in response to the sound. pictures and a longer description can be seen at http://www.kevinschlei.com/home/drop/ I will be in new york tommorow afternoon so if there are any PDer's out there that would like to get together please write back and maybe we can meet up. Hope to see you at the show Kevin

1 0

pdp_xv on pdp-0.12.4 (compiled to work with PWC)
by padovani 06 Jun '07

06 Jun '07

Hi, I've compiled PDP-0.12.4 with some alterations on the sources to get it running with my Quickcam 4000 without blinks. Previously I got it working on Ubuntu 6.10. But now, on Ubuntu-Studio (Feisty), I can't get the pdp_xv object running. The comtaries are the ones postes in the thread http://lists.saillard.org/pipermail/pwc/2006-January/000829.html... PDP is loading, but pdp_xv is not... I'm trying to understand better the code of the object but I have no Idea why it is not working. My video device supported it previously (I had to recompile it to have no blinks). I apreciate any help. tx, zÃ©

1 0

← Newer
1
...
19
20
21
22
23
24
25
26
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 June 2007