Pd-list September 2010

pd-list@lists.iem.at

138 participants
246 discussions

[PD-announce] dither8 (tramage)
by Mathieu Bouchard 28 Sep '10

28 Sep '10

http://gridflow.ca/gallery/dither8.png http://gridflow.ca/gallery/dither8b.png made with dither.pd (the new version found in GridFlow 9.12) _______________________________________________________________________ | Mathieu Bouchard ------------------------------ Villeray, Montréal, QC _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

2 1

Re: [PD] GUI speed
by Ivica Ico Bukvic 28 Sep '10

28 Sep '10

Another thing to consider is if you have large GUI objects that are updating quickly (e.g. number2 with huge fonts). This will also potentially tax the cpu. Bernardo Barros <bernardobarros2(a)gmail.com> wrote: >you can post your patch, so maybe we will discover the problem. >for the abstraction one solution is to change the name of your hacked >abstractions and send them as well. > >2010/9/27 András Murányi <muranyia(a)gmail.com>: >> well, i meant a bug in my patch... >> what i understood was that it overloaded the CPU on João's box too >> >> 2010/9/28 Bernardo Barros <bernardobarros2(a)gmail.com> >>> >>> maybe this is a bug od pd-gui? >>> (well, poor performance *is* a bug) >>> >>> 2010/9/27 András Murányi <muranyia(a)gmail.com>: >>> > On Mon, Sep 27, 2010 at 11:45 AM, João Pais <jmmmpais(a)googlemail.com> >>> > wrote: >>> >>> >>> >>> Well, it's not very exportable as i have modified/overwritten some >>> >>> abstractions made by others. Baaad practice! >>> >>> I'm trying to attach it now and i hope i works. Need pd-extended and >>> >>> many >>> >>> libs from it, moonlib for sure. >>> >> >>> >> not much, some abstractions are missing. >>> >> >>> >> anyway, even with the patch not working, I can see something is >>> >> definitively wrong. just by opening it with audio off, I get consistent >>> >> 50% >>> >> cpu usage - which means it's using a whole processor of my dual core. >>> >> unless >>> >> one of the missing abs is the problem, I would suggest you spend some >>> >> hours >>> >> bug tracking. >>> > >>> > yes, i've spent some nights bug tracking, and at one point i thought ask >>> > the >>> > list too... :o) >>> > something is definitely wrong! >>> > >>> > >>> >> On Mon, Sep 27, 2010 at 3:34 PM, Ivica Ico Bukvic <ico(a)vt.edu> wrote: >>> >> FWIW you may want to try to simply cut pieces of the patch while it is >>> >> running and observe the cpu load meter until it drops. That way you >>> >> should >>> >> be able to locate the problem quicker. >>> >> >>> > >>> > yes, i was trying thing like this, and will go on until i find what i >>> > messed >>> > up. >>> > I was just starting to think that it's normal and i have to live with it >>> > (or >>> > get a few more CPU cores) but now you guys reassured me that the bug is >>> > somewhere... in the haystack >>> > >>> > Andras >>> > >>> > _______________________________________________ >>> > Pd-list(a)iem.at mailing list >>> > UNSUBSCRIBE and account-management -> >>> > http://lists.puredata.info/listinfo/pd-list >>> > >>> > >> >> >> >> -- >> Muranyi Andras >> > >_______________________________________________ >Pd-list(a)iem.at mailing list >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

1 0

xrun-free file i/o using the coll external (SOLVED)
by Ivica Ico Bukvic 27 Sep '10

27 Sep '10

In hope to answer some of the questions I presented on the pd-list the other day, attached is the patch (diff -u against pd-extended svn 0.42.5) that converts miXed/cyclone/coll.c object into a threaded version which in turn does not trigger xruns every time one tries to open or save a file at runtime. This is particularly apparent when opening/closing large files using low latency audio buffers. This problem is also apparent in other similar objects (e.g. msgfile) and should be ostensibly solvable using the same principle. Additional lessons I learned from this exercise and am sharing them here in hope others may benefit from them as well are as follows: 1) Spawning a secondary thread within an external (detached or not) should in principle never result in an xrun, except in the coll object I discovered that always the first thread creation did result in an xrun which is why the code also does a bogus thread immediately following the creation time using clock_delay. I am not sure whether this is atom-CPU-specific or more widespread and/or whether this has to do with the way PD is designed. Any thoughts are most appreciated here. 2) Triggering clock_delay from a separate thread works fine and should be always used (rather than dealing with the outlet traffic directly) to prevent out-of-sync gui operations which may result in gui freezing/crashing. Cheers! Ico

2 4

odd key object behavior under Linux
by Ivica Ico Bukvic 27 Sep '10

27 Sep '10

In my recent troubleshooting saga dealing with xruns and coll object I identified one rather odd behavior that apparently stems from the [key] object. It all started when I noticed that my threaded version of coll object tended to freeze Pd at apparently random points. As it turns out, I was testing its robustness simply by passing a key into a read/write message and holding the key down to generate a large number of requests per second and the [key] object at times seemed to spit out (while autorepeat of the pressed key was taking place) two outputs at the same time which in turn crashed Pd as threaded coll object did not handle this gracefully. I've since fixed the coll object but the key behavior baffles me. The double redundant output is apparent in both rt and non-rt Pd (on Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is the simplest patch to invoke this. Basically, I am measuring the aforesaid time delta between broadcast strokes using timer object and printing it out to console. #N canvas 549 345 383 297 10; #X obj 162 83 key; #X obj 162 107 sel 32; #X text 208 108 space; #X obj 162 145 timer; #X obj 162 182 print; #X connect 0 0 1 0; #X connect 1 0 3 1; #X connect 1 0 3 0; #X connect 3 0 4 0; So, while certainly the fact that threaded version of coll wasn't handling gracefully multiple redundant requests at the same time was a bug (which I am hoping has been fixed now), I am wondering whether the aforesaid [key] behavior might be a bug as it seems to me that keystrokes of the same key, even if the key is autorepeating should never have a time delta of zero. Naturally, one can always put a speedlim after the [key] object but that might result in a truncated output of fast typing. I would greatly appreciate it if others can test this to see if they are getting the same results. FWIW, allowing this kind of key behavior in more complex patches did result in the pd<->gui communication tearing with the stderr reporting several truncated messages before crashing. Due to their complexity and unpredictability of a point where tearing would occur I am not sure where the problem might be stemming from but it is undoubtedly at least in part instigated by double redundant output from the key object possibly in conjunction with objects that may have not provided graceful handling of such requests. NB: I only tested the same patch on Win platform and there it does not exhibit this problem. Any thoughts would be most appreciated. Best wishes, Ico

2 1

Re: [PD] GUI speed
by Ivica Ico Bukvic 27 Sep '10

27 Sep '10

FWIW you may want to try to simply cut pieces of the patch while it is running and observe the cpu load meter until it drops. That way you should be able to locate the problem quicker. HTH Ico João Pais <jmmmpais(a)googlemail.com> wrote: >> Well, it's not very exportable as i have modified/overwritten some >> abstractions made by others. Baaad practice! >> I'm trying to attach it now and i hope i works. Need pd-extended and many >> libs from it, moonlib for sure. > >not much, some abstractions are missing. > >anyway, even with the patch not working, I can see something is >definitively wrong. just by opening it with audio off, I get consistent >50% cpu usage - which means it's using a whole processor of my dual core. >unless one of the missing abs is the problem, I would suggest you spend >some hours bug tracking. > >João > >_______________________________________________ >Pd-list(a)iem.at mailing list >UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

1 0

Re: [PD] jMax Phoenix
by Kim Cascone 27 Sep '10

27 Sep '10

> > you can make _very_ elegant super-readable control flow with the use of > [route] and friends. IOhannes I find this particular subject very interesting I was recently working on a patch using [expr] found the lack of being able to send the results of multiple 'if' statements to the same outlet frustrating - I am also used to using the Max/MSP [if] object for these sorts of tasks can point me to some examples of using [route] and friends as control statements to check out? thanks! KIM

3 4

pure data and fluid
by Luc Xation 26 Sep '10

26 Sep '10

hi i got a problem with flext and fluid~ in pure data. i followed this excellent tutorial to install flext library and pure data externals. http://samovar.tuxfamily.org/ateliers/doku.php?id=install_linux#thomas_gril… ( i use Ubuntu 10.04 LTS and gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 ). i tested flext with the patch ex-henon.pd with success. but when i created the fluid~ objet in pure data, i obtained this error /usr/lib/pd-extended/extra/fluid/fluid~.pd_linux: /usr/lib/pd-extended/extra/fluid/fluid~.pd_linux: undefined symbol: _ZN17flext_root_singlenwEj fluid~ Any ideas? Thanks for your help Luc sassion ps no problem with ldd ldd fluid~.pd_linux linux-gate.so.1 => (0x008c1000) libfluidsynth.so.1 => /usr/lib/libfluidsynth.so.1 (0x00110000) libreadline.so.6 => /lib/libreadline.so.6 (0x00963000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00698000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x004e8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00c2a000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x002fb000) liblash.so.2 => /usr/lib/liblash.so.2 (0x001cf000) libncurses.so.5 => /lib/libncurses.so.5 (0x00f3f000) libjack.so.0 => /usr/lib/libjack.so.0 (0x001da000) libasound.so.2 => /usr/lib/libasound.so.2 (0x001f4000) libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x004cb000) libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00455000) libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x002bc000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x008c5000) libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x0050e000) libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x005d8000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x0064a000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x007c8000) /lib/ld-linux.so.2 (0x00f78000) libuuid.so.1 => /lib/libuuid.so.1 (0x009e8000) libreadline.so.5 => /lib/libreadline.so.5 (0x00ecc000) libpulsecommon-0.9.21.so => /usr/lib/libpulsecommon-0.9.21.so(0x007e1000) libX11.so.6 => /usr/lib/libX11.so.6 (0x009ed000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00bd9000) libSM.so.6 => /usr/lib/libSM.so.6 (0x002c2000) libXtst.so.6 => /usr/lib/libXtst.so.6 (0x00b28000) libpcre.so.3 => /lib/libpcre.so.3 (0x00497000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x008ce000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00c49000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x0092f000) libogg.so.0 => /usr/lib/libogg.so.0 (0x002cb000) libwrap.so.0 => /lib/libwrap.so.0 (0x002d2000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x00d68000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x002db000) libXext.so.6 => /usr/lib/libXext.so.6 (0x009d1000) libXi.so.6 => /usr/lib/libXi.so.6 (0x004d0000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0x00f13000) libXau.so.6 => /usr/lib/libXau.so.6 (0x002f5000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x004de000)

1 0

pdp doc directory?
by Matteo Sisti Sette 26 Sep '10

26 Sep '10

Hi, I have Pd Extended 0.42.5 in Ubuntu. Browsing the help with the help browser (ehm) I've opened a pdp reference file called reference.txt located in /usr/lib/pd-extended/extra/pdp/manual which among other thing says: "Take a look at the patches in the doc/ directory for more info." Where is that doc/ directory? I can't find either a doc directory in the pdp directory, nor a pdp directory inside /usr/lib/pd-extended/doc, neither in manuals/ nor 5.reference/ It also mentions a test/ directory where "messy doc & test patches can be found" and I cannot find that either, though I'm less intererested in it. thanks m.

2 2

Re: [PD] How to make a buzz? (I'm no king bee)
by Collin 25 Sep '10

25 Sep '10

I recently noticed that there is a [pmpd~] object that lets you make a physical model that runs at audio rate, so I suppose you could make a little model of a mass that rattles against another mass when excited by the input signal and have that interaction trigger a proportional click with a little reverb maybe that would sound like a bottle cap. Collin > I m trying to make a patch for my guitar that would simulate the > buzzing > sound of beer bottle caps on mbiras

1 0

Re: [PD] Click Tracker software
by Collin 25 Sep '10

25 Sep '10

Congratulations, Joao! That's a nice piece of work, and I will use it the next time I need to work up Messiaen Quatuor pour la fin du temps, or Bartok Concerto for orchestra. I'll make my colleagues use it too! Collin Oldham

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
25
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 September 2010