Pd-list October 2009

pd-list@lists.iem.at

143 participants
207 discussions

another question about the threaded design in pd
by Ivica Ico Bukvic 21 Oct '09

21 Oct '09

Hi all, Another question regarding the threaded design (in follow-up to my earlier posts re: disis_wiimote object. When redesigning the threaded version, what I found out is something rather odd. Basically, I have two threads (see my previous email from a couple days ago for the source files). One is the main thread where all PD-related stuff happens and another thread that deals with offending calls to wiimote (by offending I mean they cause dropped samples in the audio thread). The two threads do not write into each other's variable pool but rather second thread compares its internal variables to the ones from the main thread to figure out what needs to be done, plus usleeps in the interim. Everything works fine and in the destructor, I set the flag for the second thread to exit the while loop and reach pthread_exit(NULL); call. Then I do pthread_join() call in the destructor of the main thread to allow time for the second thread to close and that is the end of the destructor. To the best of my knowledge this should just work. However in practice I found out that after several connects/disconnects, the wiimote would connect but not broadcast any data (or at least the external would not perceive any). This was not the case with the non-threaded version so something must be amiss in the current threaded implementation. What perplexes me is if I add half-second usleep after pthread_join in the *main* thread's destructor, this problem goes away making external rock solid (same seemed to help in an earlier implementation that had more than 2 threads), almost as if Pd does not want to wait for objects whose destructors so it makes them close prematurely. Yet, usleep seems to fix it despite the fact that the pthread_join should wait for the completion/exit of the other thread. Any ideas? Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) ico(a)vt.edu http://www.music.vt.edu/faculty/bukvic/

1 0

Re: [PD] call for snow leopard test
by Dan Wilcox 21 Oct '09

21 Oct '09

> From: Hans-Christoph Steiner <hans(a)at.or.at> > Date: October 20, 2009 1:28:30 AM GMT+02:00 > To: Pd List <pd-list(a)iem.kug.ac.at> > Subject: [PD] call for snow leopard test > > > > Are there any early adopters out there who could do a quick test on > Mac OS X 10.6/Snow Leopard for me? Its pretty easy: > > 1) download this: > http://autobuild.puredata.info/pdlab/Pd-0.43.0-devel-20091019.app.zip > 2) unzip it and run it (its a test build for Snow Leopard) > 3) try using it and see if the menubar goes crazy, open and close > some patches, etc. > 4) delete the Frameworks inside (right-click on the Pd-0.43.0- > devel-20091019.app and choose "Show Package Contents", then delete > the "Frameworks" folder > 5) try using it again and see if the menubar goes crazy, open and > close some patches, etc. I have 10.6.1 as well and didn't notice any menu problems problems other then the audio/midi menu items being in an "Apple" (text, not symbol) menu located after "Help" -------- Dan Wilcox danomatika.com robotcowboy.com

1 0

wacom external on os x
by Rich E 20 Oct '09

20 Oct '09

Hi list, I switched to mac. Now I'm trying to get my tablet working somewhat like my setup in linux land. Thomas Grill wrote an object for OS X using the new wacom API, no? I looked for this on the list but couldn't find a working link. Anyone have it or source code that they could pass to me? Rich

5 10

[PD-announce] Fwd: Invitation: Pure Data Focus Group, with Natacha Diels, Friday, 10/30, 4-6pm (rescheduled)
by Hans-Christoph Steiner 20 Oct '09

20 Oct '09

Begin forwarded message: > From: "library" <library(a)exchange.tc.columbia.edu> > Date: October 20, 2009 1:01:31 PM EDT > Subject: Invitation: Pure Data Focus Group, with Natacha Diels, > Friday, 10/30, 4-6pm (rescheduled) > > The Gottesman Libraries & New Blankets invites you to attend a > > Pure Data Workshop > > Led by Natacha Diels, Flautist & Composer > > Friday, October 30, 4:00 - 6:00 pm > > The Gottesman Libraries > Room 305 > Teachers College, Columbia University > 525 West 120th Street > > RSVP by Wednesday, October 28 to library(a)tc.edu > > Flautist and composer Natacha Diels was born in Los Angeles in 1981 > and spent most of her childhood in New Mexico. She holds a BM in > flute performance from New York University and a MPS from the > Interactive Telecommunications program at Tisch School of the Arts, > New York University. > > In 2002 Natacha founded the new music group Ensemble Pamplemousse > (non-profit inc. 2004), with the purpose of commissioning and > performing electroacoustic works for chamber ensemble. Natacha also > performs in contemporary, classical, and improvised contexts, > including such ensembles as On Stucture, Tall Brown Boots, and Red > Light New Music. She has participated as performer and composer in > new music and art festivals all over the world. Natacha is dedicated > to helping others incorporate technology and music and has taught > workshops at the School of the Art Institute of Chicago; the > Montessori School of Raleigh; the Upper Catskill Community Center > for the Arts; and Hartwick College. She is currently developing a > Montessori program in contemporary music with Corinne Sigel. > > This workshop is co-sponsored by the Gottesman Libraries and New > Blankets, a non profit organization spear-headed by Joseph Deken of > the University of California San Diego to develop new collaborative > technologies and innovative projects. For this workshop you may > bring your own laptop and headphones, or use equipment provided by > the Gottesman Libraries. > > Individuals with disabilities are invited to request reasonable > accommodations including, but not limited to sign language > interpretation, Braille or large print materials, and a campus map > of accessible features. Address these requests to the Office of > Access and Services for Individuals with Disabilities at (212) > 678-3689, keller(a)tc.edu, or Deaf and Hard of Hearing Services at > (212) 678-3853 V/TTY, jaech(a)tc.edu. > > http://library.tc.columbia.edu/news.php?id=484 > > ---------------------------------------------------------------------------- If you are not part of the solution, you are part of the problem. _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

[PD-announce] Taller de Algoritmia Noviembre 2009
by Correa Diego 19 Oct '09

19 Oct '09

Técnicas en música electroacústica, circuitos electrónicos, bioelectrónica y procesamiento de señal digital en tiempo real. http://labormedia.cl/algoritmia Resumen: La orientación del taller es la integración de conocimientos prácticos de medios musicales, electrónicos, informáticos, bioelectrónicos y matemáticos para la formulación de proyectos estéticos. Los participantes deberán imaginar un cauce de acción con las herramientas entregadas en cada módulo, para luego dirigirlo a una presentación donde podrán debatir y formular alternativas en torno a las formas de lógica disponibles para la realización concreta: su estructura, función y experiencia. Duración de cada módulo: 8 horas pedagógicas de 45 min. El método formativo utilizado (esquema CUATRO) consta de diversos módulos temáticos con una duración total por módulo de 8 horas pedagógicas de 45 min. equivalentes a 4 sesiones de 90 min. para un máximo de 4 personas. El expositor guía cada sesión al estudio representativo de la técnica para luego llevar a la práctica la aplicación mediante la construcción de una obra. - Lugar: dōjō 道場. Matucana 151 (Metro Quinta Normal), Santiago, Chile. - Valor por módulo: $40.000.- - Fechas y horario: del 2 al 30 de noviembre; para horarios por módulo, consultar. - Modo de pago: vía depósito bancario, transferencia electrónica o en efectivo. - Inscripciones: al correo algoritmia(a)labormedia.cl o al teléfono (562) 8805476. Módulos para octubre: + Introducción a Sensores Análogos para Interfaces Interactivas. + Introducción a Pure Data (Pd). + Introducción a Sensores con Microcontroladores + Instrumentación Bioelectrónica. + Introducción a Métodos en Música y Video-Performance con Pd. + Introducción a Open Sound Control (OSC). + Sensores Inalámbricos. + Controladores Digitales. + Introducción a Métodos en Música Electrónica con Pd. + Introducción a Open Computer Vision. -- http://labormedia.cl/algoritmia _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

pdpedia and spam
by Philip Potter 19 Oct '09

19 Oct '09

Dear all, I'm the only active wikiadmin of pdpedia (at http://wiki.puredata.info/). It is a persistent target of spam and I put quite a bit of effort into cleaning it up. Unfortunately my life is now busier than it once was and I have begun to ask myself: is it worth keeping clean? Is pdpedia a useful resource? Do people here use it much, or at all? The recent changes shows how much work is involved: http://wiki.puredata.info/en/Special:Recentchanges I would say that my spamfighting edits outnumber regular content edits by about 50 to 1. Given that it doesn't seem to be used much, I am considering stepping down and leaving it to the spam fiends. But of course I can only see information about editors -- I don't know how many readers there are. There are plenty of other pd documentation projects -- the FLOSS manual, the articles at http://puredata.info/docs, the online help -- will pdpedia be missed? Philip

7 10

Re: [PD] problem making an audio-thread-safe external
by Ivica Ico Bukvic 19 Oct '09

19 Oct '09

OK, So here's an implementation that apparently is as stable as it gets. Basically, disconnect/connect had to remain where they are in order to spawn callbacks within the main Pd thread. The three remaining problematic messaging systems have been encapsulated into a single thread (LED, Rumble, and SetReportMode). It appears to be pretty much rock solid as far as stability is concerned with minimal CPU overhead. Would something like this be acceptable or am I still missing something? 2 complaints about this implementation are: 1) connect brings pd to a screeching halt until either wiimote connects or fails to do so (before in a threaded implementation this was not a problem but had other issues, particularly with the callback running in a separate thread, and also had issues by reporting "post" messages in a different thread thus breaking compliance with Pd as pointed here earlier). The rationale is you would want to do this before actually performing hence it may be seen as passable. disconnect likewise drops samples (albeit for a split second) 2) messaging from the other thread regarding problems with execution of the three calls are currently commented out and as such users potentially will never be notified of their occurrence. Any examples of how this could be handled through a sys_lock or whatever it is, would be most appreciated. Best wishes, Ico On Sun, 2009-10-18 at 20:30 -0400, Ivica Ico Bukvic wrote: > One small fix to the callback seem to have improved stability (now at > least the thing loads and runs). The trick is when object is closed > without explicitly disconnecting and loaded again and closed the same > way (in both cases destructor ought to take care of things), the second > time pd freezes. Closing object by clicking disconnect first and then > closing the patch has no adverse effects. > > Any ideas? > > Also, as I learn more about pthreads, is the following a good/healthy > approach to threaded design: > > main wiimote/pd thread changes x->connection to a state that requests > action from the manageConnections thread, which then in turn updates > that state to something different. Since these are atomic changes and > the code is to the best of my knowledge designed in such a way that only > one of these can write to it at any given time (pd thread to change > state but only if the manageConnections thread has finished its change > of state, and manageConnections only changes its state when invoked > during which time regular pd thread cannot access it). > > Does this kind of design still require mutex implementation? Is this the > source of instability? > > Many thanks to all for your help in this matter! > > Best wishes, > > Ico > > On Sun, 2009-10-18 at 20:22 -0400, Ivica Ico Bukvic wrote: > > The problem is however that this is not the case. Whenever issuing > > rumble/led commands and/or toggling various features (enable ir, acc, > > nunchuk, etc.), cwiid call causes a dropout in audio thread. It's > > obvious that the initial threaded implementation done by one of my > > students should've been brought to closer scrutiny by myself (rather > > than assuming it actually works). Now, that I've been messing with it > > myself, I am learning a lot about pthreads and have arrived at an > > implementation that might seem (at least to my own limited understanding > > of pthreads) more feasible, except now I am getting random crashes and > > instabilities. > > > > The basic premise is to wrap select functionalities in separate threads > > (e.g. rumble on/off) as follows: > > > > the main struct wiimote has a variable that is set only through the main > > Pd thread (via incoming messages), so that whenever a rumble on message > > is requested, it sets this variable to 1 and when the rumble off is > > requested, it sets this variable to 0. > > > > Another thread is spawned at creation time with a while loop whose > > variable is changed in free call (destructor) and whose thread is then > > exited and joined with the main thread in the free call. This thread > > also has usleep instruction to ensure that it does not hog CPU. Inside > > the while loop (apart from the usleep) it monitors the aforesaid > > variable in the main loop to see whether it has been changed (by > > comparing it to an internal variable) and if so acts upon it. Once it > > has acted upon it it adjusts its internal variable to match that of the > > external rumble variable. this way at least theoretically one would not > > have to deal with mutex stuff (or at least as far as I could gather), > > yet the thing crashes left and right. Attached is the ugly hack of a > > code I have so far. > > > > Below is also code relevant to example cited above: > > > > //this is the separate thread that is spawned at creation > > //x->rumble is variable from the main wiimote struct that is not changed > > //here but rather through external messages that call the function below > > //in the free() function x->rumble is set to -1 and at that point > > //pthread is joined before deleting the object > > void cwiid_pthread_setRumble(void *ptr) > > { > > threadedFunctionParams *rPars = (threadedFunctionParams*)ptr; > > t_wiimote *x = rPars->wiimote; > > t_floatarg f = rPars->f; > > > > while(x->rumble > -1) { > > if (f != x->rumble) { > > f = x->rumble; > > if (cwiid_command(x->wiimote, CWIID_CMD_RUMBLE, f)) { > > //post("wiiremote error: problem setting rumble."); > > } > > } else { > > usleep(10000); > > } > > } > > pthread_exit(0); > > } > > > > //this function is called when an external message arrives requesting > > change in rumble status > > void cwiid_setRumble(t_wiimote *x, t_floatarg f) > > { > > if (x->connected) { > > x->rumble = f; > > } > > } > > > > Any help in this is most appreciated. > > > > Best wishes, > > > > Ico > > > > On Sun, 2009-10-18 at 17:04 -0400, Hans-Christoph Steiner wrote: > > > I think a thread is likely just going to add complication here. The > > > HID stuff is all without threads and works well. If cwiid is already > > > threaded, then chances are you should be able to get data from its > > > threads using non-blocking calls. If it already buffers the data, > > > then you don't need your own thread, just get the data from cwiid's > > > buffer in a non-blocking way. > > > > > > This is how the Linux input API works, IIRC. > > > > > > .hc > > > > > > On Oct 17, 2009, at 10:33 PM, Ivica Ico Bukvic wrote: > > > > > > > Hi all, > > > > > > > > I am currently working on a threaded implementation of a wiimote > > > > external. The reason I was hoping threaded design would help is to > > > > avoid > > > > dropped samples when issuing commands to wiimote (e.g. rumble/led > > > > status > > > > change). So far, it seems that reading from wiimote, no matter how > > > > fast, > > > > has no impact on the audio thread. However, writing even when such > > > > action is generated through a separate thread seems to cause drop-outs > > > > in the audio thread. The external (which was not originally built by > > > > me) > > > > uses cwiid to communicate with wiimotes and my understanding is that > > > > cwiid is heavily threaded in and of itself. An example of a threaded > > > > code is below: > > > > > > > > void *cwiid_pthread2_setRumble(void *ptr) > > > > { > > > > > > > > threadedFunctionParams *rPars = (threadedFunctionParams*)ptr; > > > > t_wiimote *x = rPars->wiimote; > > > > t_floatarg f = rPars->f; > > > > > > > > if (x->connected) > > > > { > > > > if (cwiid_command(x->wiimote, CWIID_CMD_RUMBLE, f)) post("wiiremote > > > > error: problem setting rumble."); > > > > } > > > > } > > > > > > > > void cwiid_pthread_setRumble(t_wiimote *x, t_floatarg f) > > > > { > > > > threadedFunctionParams rPars; > > > > rPars.wiimote = x; > > > > rPars.f = f; > > > > > > > > pthread_t thread; > > > > int iret1; > > > > > > > > iret1 = pthread_create( &thread, NULL, cwiid_pthread2_setRumble, > > > > (void*) &rPars); > > > > pthread_join(thread, NULL); > > > > } > > > > > > > > So, cwiid_pthread_setRumble is called from Pd and then it in turn > > > > creates a thread that sends info to cwiid library against which the > > > > external is linked. I am confused as to why the new thread once it has > > > > been created still affects the Pd's audio thread. Any ideas? > > > > > > > > Best wishes, > > > > > > > > Ico > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pd-list(a)iem.at mailing list > > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > > > > "[W]e have invented the technology to eliminate scarcity, but we are > > > deliberately throwing it away to benefit those who profit from > > > scarcity." -John Gilmore > > > > > >

1 0

[PD-announce] GridFlow 0.9.5
by Mathieu Bouchard 18 Oct '09

18 Oct '09

http://gridflow.ca/download/gridflow-0.9.5.tar.gz version 0.9.5 (2009.10.18): * added [gf.print] (aliased to [print]) * added [cv/#Ellipse], [cv/#HarrisCorner], [cv/#KMeans] * renamed goop.pd to surface_tension.pd * [#in quicktime]: "get" also produces messages "framerate", "height", "width", "depth", "codec". * added [#draw_hpgl], [#reinterval], [#cluster_avg] * added [norecurse], [gf.error] * [#color]: added bang * [#inner]: fixed infinite loop bug with large right-inlet grids. * [#transpose]: fixed crash with zero-sized grids. * [receives]: "empty" prefix automatically turned into "" (no prefix). * [#in grid] and [#out grid]: fixed several bugs * [#make_cross] can make rectangular crosses * [demux] alias removed (please use [shunt]) * renamed every [cv.Something] to [cv/#Something] to avoid any future nameclashes with Loïc's library. * automatically removes artificial stacksize limits of the OS that may have caused segfaults in the last year or so, if you didn't use ulimit -s unlimited or somesuch * added [# c2p] and [# p2c] (polar transforms) * added new examples: polar.pd, radial_blur.pd * fixed more OSX bugs * fixed [#grade] bug (thanks to mescalinum) * removed support for gem 0.89 and some 0.90 versions _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801 _______________________________________________ Pd-announce mailing list Pd-announce(a)iem.at http://lists.puredata.info/listinfo/pd-announce

1 0

founders of computer music, about past and future...
by Fernando Gadea 18 Oct '09

18 Oct '09

2 1

Re: [PD] "computer music" WAS: Re: Pd at a livecoding event on the BBC
by Fernando Gadea 18 Oct '09

18 Oct '09

Sory for the big delay, but I was really busy. I will try to answer in between lines: Mathieu Bouchard escribió: > On Tue, 8 Sep 2009, Fernando Gadea wrote: > >> So they say that good piano players play with the whole body (same >> for guitar or any physical instrument, I guess). > > Is it because it makes the music any better, or because what musicians > are after is not just the music but also the dance that a musician > makes with the instrument? In a physical instrument the position of the body when playing modifies the dynamics of movements, so variations in the dynamics of movement produce also diferent dynamics of sound. If you press a key with a strong movement it will almost shurelly be different if you do it sitting on a chair, with your head and back aiming behind your gravitational center, that if you do it whith your body aiming foreward or if you do it standing on your feet. Your finger´s pressing movement will be affected, and also the strength with which you keep pressing after that. Being able to administrate this variations gives the musician a wider sound palette (Sorry, I am not shure if this is the word). This expands the expressive possibilities of the performer as he then is able to subjetively transfer the meanings he gives to his body movements to the sound dynamics. In the following text please note that it says "from the performer side" and "what music should express", not what it DOES express, neither from an objective view. I mean, I am trying not to take the subject to the interpretation from an observer-in-the-public point of view, and, I must say it again, this is not what everybody should do, but those that feel that they need to. "...different performances of the same piece can communicate different expressive inten- tions. Most music performances involve expressive inten- tions from the performer’s side, regarding what the mu- sic should “express” to the listeners. Consequently, in- terpretation involves assigning some kind of meaning to the music. " (http://smc.afim-asso.org/smc05/papers/LucaMion/mapping.pdf) > >> Art is suposed to be a free environment, meaning that it should be >> guided or conditioned only by the artist. > > According to whom? This subject is treated in aesthetic since the enlightement and romanticism, and maybe even before. You can read about this subject´s history (treated secondarily) in Simón Marchán Fiz´s "La estética en la cultura moderna", from chapter III till the end. Other related subject might be "Ludic Aesthetics". I don´t remember a more specific book. Marchan Fiz is related to the Frankfurt school. I don´t know how the freedom subject is treated by Analytic Aesthetics, but as a more-science-philosophy-related aesthetic perhaps it just does not treat it. Also in Post structuralist´s philosophy Freedom becomes an important subject that implies relationships with art, and of course in Existentialism, before that, so you might find usefull reading Heidegger or Sartre, or triyng to understand Foucault´s, Deleuze´s and Guattari´s art-related works. Furthermore, any statement about being required from the artist to give his own truth implies the concept of being the artist free. Anyway, as any definition of art is possible while it must be contextualized, I agree that we could talk of other kinds of art where freedom is not important or does not exist at all. >> If you answer yes to the third, the probabilities are that your mind >> is twisted after years of taking drugs, and maybe it was already >> twisted before you studied art or started taking drugs. Sorry, I was >> joking... > > Drugs usually come relatively late in the picture. They don't tend to > make art more twisted, just more defective. They also don't have much > to do with being twisted. I was just joking and being metaphoric and rethoric. Besides that, There have existed circunstances when drugs have been part of the creative environment and I wouldn´t agree that the results were defective. And I would say that "defective" is another relativable concept. > >> Of course in these three questions I was only having fun while being >> retoric, because relativity dismantles concepts as "making a >> difference", "quality", "being emotionally involved" and even >> "academic" or "popular" (history shows lots of examples that would >> complicate the difference between the last two). > > Dismantling and complicating are not the same thing. Being conscious > of the relativity doesn't make those concepts less important and it > doesn't break them. It just breaks down a lot of talk that uses those > concepts: that which is vague, makes undue assumptions, etc. > >> At the end, anything could be poetic, as it mostly depends on who we >> are at that right moment. It ends as a matter of self-perception. > > Right. > >> And as perception is not transferable, neither is poetic or aesthetic >> experience. > > Well, despite our frustrations with it, plain talking goes a long way > transferring a lot of perception, experience, and other ideas. Calling > perception non-transferable comes from either taking conversation as > so much for granted that it doesn't count in the picture, or being > very pessimistic about how well it can be effectively transferred. I understand what you mean, but the fact is that perception is not fully transferable. If it was, there would be no difference between any sound/image and a description of it. > >> That gives us a lot of possibilities, none better than other, only >> differents. > > It's only all the same if you just don't care about the possibilities > (or if you are trying to be diplomatic). In practice, people get > involved in aesthetics because they are passionate about them, and > they judge a lot. There is no absoluteness, no central authority, but > there's still a lot of judgements and impressions of what is better > and what is worse, and that's a necessity. Maybe yes, but what I am trying to say is that I believe that those discussions about better-worse are also relativables, and then they shouldn´t end in duality (unless it is stated that this duality is related to the speaker), because when they do it probably means that a part of the true will be left out, and maybe that´s not an implicit necessity of the art world. > >> It is also supposed that someone not educated would be more able to >> find poetic in anything, because for him anything would be different >> from anything he knows. > > People don't enter university as blank slates. I agree. > >> That is why we commonly despise the creations of early students, >> forgetting that in history teachers stole several times the concepts >> of students that "weren´t clever enough to realize the jewel they had >> in hands". > > Students are at a disadvantage here. They are not knowledgeable in the > research-wise artistic discourse of profs, that is what profs are > bathing in constantly, and so they don't know what is valuable to the > profs. What is valuable to the profs doesn't make much sense to an > outsider. It's probably more whim-oriented than most any other > discipline (?). > > it was an interesting read. Thankyou for reading. > > _ _ __ ___ _____ ________ _____________ _____________________ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801

3 3

← Newer
1
...
8
9
10
11
12
13
14
...
21
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 October 2009