[PD] [PD-announce] Special issue of Wi: Journal of Mobile Media / Audio Mobility -
Wi:Journal of Mobile Media LOCUS SONUS 2015: Vol. 9 No. 2. Audio Mobility The editorial team at Wi:Journal of Mobile Media and Locus Sonus Lab are pleased to announce the release of the latest issue 2015 : Vol 9 No2 Audio Mobility / La revue scientifique canadienne Wi: Journal of Mobile Media et le laboratoire de recherche Locus Sonus ont le grand plaisir de vous annoncer la sortie du numéro spécial 2015 : Vol 9 No2 Audio Mobilité Guest-edited by / Sous la direction de : Peter Sinclair Elena Biserna / Locus Sonus With contributions by / Avec les contributions de : Romain Barthélémy Roland Cahen, Frauke Behrendt, Justin Bennett, Elena Biserna, Xavier Boissarie Emmanuel Guez, Samuel Bordreuil, Joel Cahen, Aisen Caro Chacin, Jean Cristofol, Owen Chapman, Laurent Di Biase, Steve Jones, Jérôme Joy, Fabrice Métais, Marie Muller, Gaëtan Parseihian, Sølvi Ystad, Mitsuko Aramaki Richard Kronland Martinet, Matthieu Saladin, Dom Schlienger, Peter Sinclair, Jessica Thompson, Aline Veillat. The issue can be found here / Lien vers la revue : http://wi.mobilities.ca/ http://wi.mobilities.ca/ (English French below) 1- AUDIO MOBILITY: INTRODUCTION 2- TABLE OF CONTENTS / SOMMAIRE 3- AKNOWLEDGEMENTS / REMERCIEMENTS /// 1- AUDIO MOBILITY: INTRODUCTION This special issue of the Canadian Journal Wi: Journal of Mobile Media is one of the outcomes of the research project Audio Mobility, started by Locus Sonus in 2013. The publication includes more than twenty texts by international artists, theorists and scholars exploring the relationships between mobile media and sound production in contemporary artistic, cultural and social practices. Originally presented at the Symposium # 8 Audio Mobility, organized by Locus Sonus (16-18 April 2014), the texts were revisited by the authors for this special edition. Le numéro spécial de la revue canadienne Wi: Journal of Mobile Media est le fruit du projet de recherche Audio Mobilité, commencé par Locus Sonus en 2013. La publication contient une vingtaine de textes d'artistes, théoriciens et historiens internationaux qui explorent la relation entre la production sonore et les médias mobiles dans les pratiques culturelles et sociales contemporaines. Initialement présentés au Symposium #8 Audio Mobilité, organisé par Locus Sonus (16-18 Avril 2014), les textes ont été revisités par les auteurs pour cette édition spéciale. 2- TABLE OF CONTENTS / SOMMAIRE Peter Sinclair and Elena Biserna: Audio Mobility: Introduction GB http://wi.mobilities.ca/locus-sonus-introduction/ http://wi.mobilities.ca/locus-sonus-introduction/FR http://wi.mobilities.ca/locus-sonus-introduction/%22#french http://wi.mobilities.ca/locus-sonus-introduction/%22#french Romain Barthélémy and Roland Cahen: Navigating by sound in my SmartCity http://wi.mobilities.ca/romain-barthelemy-and-roland-cahen-navigating-by-sound-in-my-smartcity/ http://wi.mobilities.ca/romain-barthelemy-and-roland-cahen-navigating-by-sound-in-my-smartcity/ Frauke Behrendt: Locative Media as Sonic Interaction Design: Walking through Placed Sounds http://wi.mobilities.ca/frauke-behrendt-locative-media-as-sonic-interaction-design-walking-through-placed-sounds/ http://wi.mobilities.ca/frauke-behrendt-locative-media-as-sonic-interaction-design-walking-through-placed-sounds/ Justin Bennett: Walking, Telling, Listening – Audio Walks http://wi.mobilities.ca/justin-bennett-walking-telling-listening-audio-walks/ http://wi.mobilities.ca/justin-bennett-walking-telling-listening-audio-walks/ Elena Biserna: Mediated Listening Paths: Breaking the Auditory Bubble http://wi.mobilities.ca/elena-biserna-mediated-listening-paths-breaking-the-auditory-bubble/ http://wi.mobilities.ca/elena-biserna-mediated-listening-paths-breaking-the-auditory-bubble/ Samuel Bordreuil: Between The Marching Band and The Sound Walk http://wi.mobilities.ca/samuel-bordreuil-between-the-marching-band-and-the-sound-walk/ http://wi.mobilities.ca/samuel-bordreuil-between-the-marching-band-and-the-sound-walk/ Joel Cahen: Strategies on Sound Based Augmented Reality Theatre http://wi.mobilities.ca/joel-cahen-strategies-on-sound-based-augmented-reality-theatre/ http://wi.mobilities.ca/joel-cahen-strategies-on-sound-based-augmented-reality-theatre/ Aisen Caro Chacin: Echolocation Headphones: Seeing Space with Sound http://wi.mobilities.ca/aisen-caro-chacin-echolocation-headphones-seeing-space-with-sound/ http://wi.mobilities.ca/aisen-caro-chacin-echolocation-headphones-seeing-space-with-sound/ Owen Chapman: Ecotones, Eco-territories and the Sonic Relationality of Space: An audio investigation of Montreal’s ‘Falaise St. Jacques’ http://wi.mobilities.ca/owen-chapman-ecotones-eco-territories-and-the-sonic-relationality-of-space-an-audio-investigation-of-montreals-falaise-st-jacques-2/
Re: [PD] pure data benchmark?
Hi, On 05/05/2015 18:12, martin brinkmann wrote: does something like this exist? afaik not, but i think it would be useful to have some more or less objective and comparable method to measure how well a system is suited for running pd. there was a test patch for rjdj on the ipod/phone which consisted of simply as much osc~-objects as the device could handle. that worked quite well for checking if a patch would run on the device or not, but i think it might not cover all possible properties of a system. One problem with (totally un-scientific) benchmarking I've seen on Linux (on laptops and with Jack Audio) is that there are a few factors sucha as cpu scaling, wifi on/off, swappiness.. and of course type od soundard used i.e. all the 'audio on linux' stuff which an influence performance. I'm talking here mostly about 'audio benchmarking' more thn CPU etc. which means for instance how low latency you can get with a rather CPU intensive patch without (too many) xruns etc. With heavy patches I have also noticed dramatic performance differences with different gui activity: e.g. the more number boxes, sliders etc. being 'continuously' updated (in the order of milliseconds) the worst performance is. Very hard to benchmark though because there are many factors. Add GEM (and video cards, drivers.. ) and 'benchmarking' probably becomes a sort of black magic. This doesn't really answer the question but thought it would be useful to throw in some additional complexity :) Lorenzo. ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd course in Lisbon, Portugal @ IADE / Curso de Pd em Lisboa
Hallo everybody, this is an announcement for a Pd course in Lisbon so the information will follow in also Portuguese. The first 20 hours workshop in Creative programming with Pd starts this week at the Creative University IADE. More info here: http://www.iade.pt/unidcom/uxlab/academia/programacao-criativa-com-pure-data/ ~ Olá a todos os portugueses ou residentes em Portugal! O primeiro curso de 20 horas de Programação Criativa com Pure Data começa esta semana no IADE. Para mais informações http://www.iade.pt/unidcom/uxlab/academia/programacao-criativa-com-pure-data/ Cheers! Bem hajam! Mick -- mickmengucci.bandcamp.com facebook.com/mickmengucci3 facebook.com/Labio.pt http://WWW.MISTURAPURA.NETMISTURAPURA.NET http://WWW.MISTURAPURA.NET pure mixture vibration since 1995 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Move a file from within Pd?
Hi, AFAICT neither [shell] nor [popen] results in portable Pd code, i.e. the specific shell commands are OS-dependent. In any case, I decided to write a new external for the job. In case anyone is interested: [copy] can be used to copy files portably from Pd: http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/postlude/copy/ best, Jamie On 28 April 2015 at 00:18:35, tim vets (timv...@gmail.com) wrote: [shell] or [popen] ? On 28 Apr 2015 00:47, Jamie Bullock ja...@jamiebullock.com wrote: Can anyone suggest a way to move a file in the user's filesystem from within Pd without loading it into memory? My use case is that I am using [writesf~] to record audio to disk, and I want to allow users to “save” the audio file to somewhere else. Clearly the audio could be very large, so I want to avoid using soundfiler to read into memory and then write back out again. This is from an application that uses Pd as a backend so expecting the user to manually move the file is not an option. Any solutions (including use of externals) welcome. Thanks. Jamie -- http://jamiebullock.com @jamiebullock ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Move a file from within Pd?
On 05/11/2015 12:18 PM, Jamie Bullock wrote: Hi, AFAICT neither [shell] nor [popen] results in portable Pd code, i.e. the specific shell commands are OS-dependent. In any case, I decided to write a new external for the job. In case anyone is interested: [copy] can be used to copy files portably from Pd: http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/postlude/copy/ just wondering whether [copy] is a too generic name. probably [filecopy] would be more apt. gmsadr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pure data benchmark?
On 05/11/2015 10:48 AM, Lorenzo Sutton wrote: One problem with (totally un-scientific) benchmarking I've seen on Linux (on laptops and with Jack Audio) is that there are a few factors sucha as cpu scaling, wifi on/off, swappiness.. and i'm wondering about swapiness...if your system does start to swap during performance, than you are f*ed anyhow. but yes, there are some easy to fix (as in fixate) parameters, that should be mentioned when doing anything benchmark-like. Add GEM (and video cards, drivers.. ) and 'benchmarking' probably becomes a sort of black magic. no, it's not black magic; it simply does not make much sense. it's plain impossible to design a benchmark that yields a single comparable number that can be applied to all use cases. if we want to do proper benchmarking, then we need a set of patches that tests for different aspects of your system. it's also hard to design a benchmark that tests (say) multichannel audio I/O (i'm imagening something like 64 channels) and that should provide meaningful results on a stereo system. gfmards IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Vanilla object for sort
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just make this abstraction (sorting number in one direction). It works with array objects. Seems promising compare to list-sort. ++ Jack Le 10/05/2015 03:21, Jonathan Wilkes via Pd-list a écrit : On 05/09/2015 05:54 PM, Miller Puckette wrote: On Sat, May 09, 2015 at 05:30:14PM -0400, Jonathan Wilkes via Pd-list wrote: On 05/09/2015 11:29 AM, Frank Barknecht wrote: Hi, the list-sort.pd abstraction in the [list]-abs is Pd vanilla and uses data structures to do the sorting. The actual sorting is fast, but first the list is copied into a data structure [struct f float x] and into a subpatch, which takes a moment. Then you just sort the subpatch with the message sort to it. In my benchmarks four yers ago it was faster than the other sorting algorithms available at the time, which are also included in the collection. That's probably because the other sorting algorithms spend a significant amount of time copying lists. To get anything close to the speed of the canvas sort method you'd have to have an object that manipulates an incoming list in place. However, that'd have serious side effects, which is why I suppose no objects do that kind of thing. -Jonathan But I believe Frank's method (which is, by the way, ingenious!) also requires copying the objects to be sorted. So I think one could do just as well some other way. I haven't looked, but I'd guess that: a) converting the list to scalars requires either no list copying operations, or a single list copy operation b) converting sorted scalars back to a list uses the add2 method So even though there may be copying to convert the data, the number of list copy operations isn't going to grow with the size of the list. My point is that if you try to devise abstraction to sort lists using Vanilla objects (without relying on canvas' sort method), you will most likely end up needing to do a list copy operation on each iteration of the algorithm. And that will be substantially slower than doing it in C. I might be wrong about that, but the only non-trivial list-abstraction I've seen that doesn't copy lists is list-drip. And it's so difficult to reason about its data-flow that I highly doubt anyone has used it as a model for solving more difficult problems. Here are three things I could imagine doing for some future release: a [list sort] built-in that outputs two lists, one the sorted numbers or symbols, and the other giving the indices of the items in order an [array sort] object - I guess that should write its outputs into two other arrays, yuck a [text sort] object that would act like unix sort: just sort all the lines of the text object. I don't know which of these would be the most useful. The only use case that I've run into personally is my desire to do triage on sigmund~ outputs to find, say, the peaks best fitting a user-defied criterion about freqency and amplitude (example: Fletcher-Munson loudness; or other example: the peaks that best continue a collection of pre-existing tracks). For that, the [list sort] solution would be best I think. I don't know which of those would be most useful, either. But I think there's a general issue with dataflow languages to be teased out here. There was also a thread on the list for Noflo (a flo-based programming language that can run in a browser) about the difficulties of implementing quicksort. I can't quite put my finger on what the issue is-- I don't think it's message-passing overhead, because Pd gets around that to some extent by passing references under the hood. I believe it has more to do with those times where I get to the bottom of an object chain and think, Hm, I really want some of that data from the top of the chain, but I really don't want to draw yet another line and box just to prepare a copy of it. I think sometimes I just want a single vertical tube, with syringes stuck in the sides that mutate the data in order from top to bottom. So the data flowing through the tube would be like a t_binbuf onto which I can append and/or remove atoms (or change their values). So if you get Luigi going down the tube, you get Luigi coming out of the tube. (Though he may look very different by that point. :) -Jonathan cheers Miller ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVUKhjAAoJEOuluecjw8GUglQH/iXi1Gm9S/LVuo+o11u1zXIz HlWS6x+TW3ei2PhD/KLDwLKgfzD4NjT62goM2NFWW4FV1XdCrne758ht5/N40Rg9 8EZBF3GzIX4FzFuqNA+pKv1GsUfHxSKg4bDCQ0sIiAVMGoHOZgMjdWY+57Oj2Ibi DdzUp2W+aEMFVE4js6GEXNm+aLIiPa6eaf9RE9v5aJY/N3JwmzYlrUHotBO359kt PAlNxtKzxWGuOLEAVpB9gyXO1CtrBApqW1VNrlloo1A8FIHwnpnSrBc/PR33isAN Pjl/yl+Eo/XS8btjIcnmBsMpXhSyCrQRRzFYNgZNe2MFkgD3UkwZjQ4HJzylr18= =e1IK
Re: [PD] 0.46 for Ubuntu 14.04?
I tried to follow step by step, but I had some troubles...
$ PDVER=0.46.6-1
$ sudo apt-get install devscripts
$ dget -u
http://http.debian.net/debian/pool/main/p/puredata/puredata_${PDVER}.dsc
$ cd puredata-${PDVER%-*}
$ mk-build-deps
$ sudo dpkg -i puredata-build-deps_${PDVER}_amd64.deb
Everything went Ok. But here, I have this error (sorry the language),
mario@circo3d:~/puredata-0.46.6$ sudo dpkg -i
puredata-build-deps_${PDVER}_amd64.deb
Seleccionando el paquete puredata-build-deps previamente no seleccionado.
(Leyendo la base de datos ... 589109 ficheros o directorios instalados
actualmente.)
Preparing to unpack puredata-build-deps_0.46.6-1_amd64.deb ...
Unpacking puredata-build-deps (0.46.6-1) ...
dpkg: problemas de dependencias impiden la configuración de
puredata-build-deps:
puredata-build-deps depende de portaudio19-dev; sin embargo:
El paquete `portaudio19-dev' no está instalado.
puredata-build-deps depende de libjack-dev; sin embargo:
El paquete `libjack-dev' no está instalado.
dpkg: error al procesar el paquete puredata-build-deps (--install):
problemas de dependencias - se deja sin configurar
Se encontraron errores al procesar:
puredata-build-deps
but, supposedly, it is fixed with the next command:
$ sudo apt-get -f install
This does not install anything, but it remove puredata-build-deps (I
don't think it is good...)
mario@circo3d:~/puredata-0.46.6$ sudo apt-get -f install
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Corrigiendo dependencias... Listo
Los paquetes indicados a continuación se instalaron de forma automática
y ya no son necesarios.
autopoint dh-autoreconf libportaudiocpp0
Use 'apt-get autoremove' to remove them.
Los siguientes paquetes se ELIMINARÁN:
puredata-build-deps
0 actualizados, 0 se instalarán, 1 para eliminar y 190 no actualizados.
1 no instalados del todo o eliminados.
Se liberarán 26,6 kB después de esta operación.
¿Desea continuar? [S/n]
(Leyendo la base de datos ... 589112 ficheros o directorios instalados
actualmente.)
Removing puredata-build-deps (0.46.6-1) ...
But I continued...
$ dpkg-buildpackage -r fakeroot
This command is wrong, after googling, I think it is
dpkg-buildpackage -rfakeroot
But this commands says:
mario@circo3d:~/puredata-0.46.6$ dpkg-buildpackage -rfakeroot
dpkg-buildpackage: paquete fuente puredata
dpkg-buildpackage: versión de las fuentes 0.46.6-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: fuentes modificadas por IOhannes m zmölnig
(Debian/GNU) umlae...@debian.org
dpkg-buildpackage: arquitectura del sistema amd64
dpkg-source --before-build puredata-0.46.6
dpkg-checkbuilddeps: Dependencias de construcción no satisfechas:
portaudio19-dev libjack-dev
dpkg-buildpackage: aviso: Las dependencias y conflictos de construcción
no están satisfechas, interrumpiendo
dpkg-buildpackage: aviso: (Use la opción «-d» para anularlo.)
By seeing this... I don't think it is working... but I continued.
$ sudo dpkg -i ../*${PDVER}_*.deb
mario@circo3d:~/puredata-0.46.6$ sudo dpkg -i ../*${PDVER}_*.deb
dpkg: error al procesar el archivo ../*0.46.6-1_*.deb (--install):
no se puede acceder al archivo: No existe el archivo o el directorio
Se encontraron errores al procesar:
../*0.46.6-1_*.deb
I was right, it didn't work.
Did I do something wrong? Any help... ?
Thank you very much.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Move a file from within Pd?
On 11 May 2015 at 12:06:24, IOhannes m zmölnig (zmoel...@iem.at) wrote: On 05/11/2015 12:18 PM, Jamie Bullock wrote: Hi, AFAICT neither [shell] nor [popen] results in portable Pd code, i.e. the specific shell commands are OS-dependent. In any case, I decided to write a new external for the job. In case anyone is interested: [copy] can be used to copy files portably from Pd: http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/postlude/copy/ just wondering whether [copy] is a too generic name. probably [filecopy] would be more apt. Agreed. I’ve just renamed it in svn as you suggest. best, Jamie___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Vanilla object for sort
Hi Jack, On Mon, May 11, 2015 at 03:02:27PM +0200, Jack wrote: Just make this abstraction (sorting number in one direction). It works with array objects. Seems promising compare to list-sort. That's very cool: Using a 1000-element list created with [list-random 1e+06 1000] it's more than 3 times faster: list-sort: 13.026 array-sort: 4.016 list-sort: 13.109 array-sort: 4.036 list-sort: 13.188 array-sort: 4.024 But what's even better: It's very simple code. Unlike the data structure implementation, this is something, one could quickly type into a subpatch. Ciao -- Frank Barknecht _ __footils.org__ ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] 0.46 for Ubuntu 14.04?
On 05/11/2015 02:57 PM, Mario Mey wrote:
mario@circo3d:~/puredata-0.46.6$ sudo dpkg -i
puredata-build-deps_${PDVER}_amd64.deb
Seleccionando el paquete puredata-build-deps previamente no seleccionado.
oh i forgot an important step:
$ export LANG=C
before all the other things.
it helps a lot if you want to have people understand the errors you get
on your vietnamese installation.
dpkg: error al procesar el paquete puredata-build-deps (--install):
problemas de dependencias - se deja sin configurar
Se encontraron errores al procesar:
puredata-build-deps
but, supposedly, it is fixed with the next command:
yep, that was the plan...
$ sudo apt-get -f install
This does not install anything, but it remove puredata-build-deps (I
don't think it is good...)
...but it didn't work out.
probably it would have been better to simply use:
$ sudo mk-build-deps -f
which should automatically install the build-deps package and its
dependencies, thus making the dpkg and apt-get steps unnecessary.
dpkg-checkbuilddeps: Dependencias de construcción no satisfechas:
portaudio19-dev libjack-dev
you can also install these two packages manually.
(and then re-run the steps starting with `dpkg-buildpackage`)
fgards
IOhannes
signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
