Pd-list February 2013

pd-list@lists.iem.at

106 participants
200 discussions

Re: [PD] online video conferencing
by fls＠rendera.com.br 07 Feb '13

07 Feb '13

Hi Eldad! Recently we had a netmusic conference (http://netmusic2013.wordpress.com/) and we used jacktrip for audio streams and bluejeans (http://bluejeans.com/) to the video streams. Instead of some problems with bluejeans, it worked. Bests Schiavoni > Hi all, > I am looking for an accessible way to do a video conference with multiple > parties (4 or 5) for a telematic performance. > The bandwidth is there and visual latency is not an issue in this case. > Any ideas about a stable platform for this would be greatly appreciated. > > In the past I worked with Access Grid, which was quite stable, but is very > tricky to install on Snow Leopard and doesn't work at all on Lion and > later. It still works on Windows, but not all the parties can get a > Windows system, > Google Hangout should work (I haven't tested it yet) but it doesn't allow > you, to my knowledge, to separate the video windows and reorganize them on > the screen. > > There are some paid cloud-conferencing services that can work for this, > but as far as I know they work on subscription. If you know of such a > service that allows renting a video conferencing service temporarily that > could be helpful too. > > Many thanks for any help > Eldad

1 0

Re: [PD] Plugin auto install feature to Pure data
by fls＠rendera.com.br 07 Feb '13

07 Feb '13

Thanks Hans! Just one doubt: How does it work for different architectures? Should we pack windows, linux and Mac in different packages? Or can we include them in one package and the installer copies just the right one? cheers f schiavoni > This stuff is already pretty well defined in the library template and the > *-meta.pd file. I think the meta file would be the place to add things > like > dependencies also. > > http://puredata.info/docs/developer/Libdir > http://puredata.info/docs/developer/LibraryTemplate > > .hc > > On 02/05/2013 04:11 PM, fls(a)rendera.com.br wrote: >> I agree that depencencies should not install libs. Since it seems to be >> the biggest problem, maybe it should be postponed. >> >> Yes, the repository maintenance can be solved latter too. Let's first >> have >> a repository and then think about the best way to keep it on date. :-) >> >> I don't have skills with TCL but I agree that it is a good choice. Is >> there how to open zip/tar/something files in TCL? If it can open the >> package, it's perfect. >> >> IMO, the first step is to install locally. Define a package structure, a >> package header and the install script. Probably it can be used by the >> remote install. >> >> I suggest the following package structure: >> /content.txt >> /bin/files <-to compiled files (architecture dependent) >> /help/files <-to help files (architecture independent) >> /tcl/files <-to gui files (architecture independent) >> >> This structure should be compacted / grouped in a file with some name >> convention like package_name.version.pd_pkg. >> >> The content.txt can be as follow: >> name: >> author: >> version: >> key-words: >> web-site: >> license: >> flavor: >> dependencies: >> instructions: >> >> The install script should select a package, open it, copy the external >> to >> the external dir, copy the help and tcl files to the correct folder, >> rename the content.txt to the package name + version and copy it to an >> folder designed for this kind of file. >> >> Cheers >> >> f schiavoni

1 0

Re: [PD] Plugin auto install feature to Pure data
by fls＠rendera.com.br 07 Feb '13

07 Feb '13

I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files <-to compiled files (architecture dependent) /help/files <-to help files (architecture independent) /tcl/files <-to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni

2 1

RE : package system for Pd WAS: Plugin auto install feature to Pure data
by colet.patrice 07 Feb '13

07 Feb '13

I dont think the client is the first thing to head on, because I guess it will depend on server architecture. Anyway tcl seems to most suited for that, there would no need to add some more junk into pd bin folder... Envoyé depuis mon appareil mobile Samsung -------- Message d'origine -------- De : Hans-Christoph Steiner <hans(a)at.or.at> Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list(a)iem.at Objet : [PD] package system for Pd WAS: Plugin auto install feature to Pure data While I agree with all this, we don't need a full design spec to start coding. I think the next step is for someone to put together a rough prototype to start with, rather than get bogged down in the details of something that has been talked about for years, but never implemented :-) Then it can be implemented bit by bit as people have time and interest. So the first question to ask before starting it: which language? Is Tcl workable for people? .hc On 02/05/2013 10:36 AM, Charles Z Henry wrote: > I think that it's a great idea--but the devil's in the details. I think > you need to have a good guiding vision to help you make the decisions about > the implementation--a top-down design > > On the client side, you have to have information about what packages are > installed, where they're installed, what flavor of pd they are installed > for, version information, more? > Dependencies: within Pd, you could be distributing patches that require > some externals--I think it's best for a Pd package system to only reference > dependencies that include other abstractions or externals, not system > libraries. > Maintenance: a system like this needs to be *easy* to maintain---only a > few binary targets can be supported. The rest will need to compile from > source. > > I would start out like this.... make a list and argue point-by-point until > you have a clear plan. > Not that I'm much one to *complete* my projects... but I have a lot of > insight on failing :) > > > On Mon, Feb 4, 2013 at 3:10 AM, colet.patrice <colet.patrice(a)free.fr> wrote: > >> Hello, that's a quite interesting subject I've been thinking about for pdx >> since a time, thank you for the contribution... like you said it might be >> complicated to resolve all dependences required by an external, so I think >> that adding other dependences like php sql or json would make it even more >> complicated... Why not just using the native client interpreted langage, >> TCL-TK? With the help of a command line like wget included with the tcl >> script and a bunch of pkg files that should be enough, wouldn't it? >> >> >> >> >> >> >> >> -------- Message d'origine -------- >> De : fls(a)rendera.com.br >> Date : 03/02/2013 20:22 (GMT+00:00) >> A : pd-list(a)iem.at >> Objet : [PD] Plugin auto install feature to Pure data >> >> >> Hi list >> >> I would like to write before but unfortunately I couldn't. Some weeks ago >> people started to talk about the development of some auto install >> mechanism to Pure Data, like the apt-get. It is an amazing idea. I >> researched and developed some thing like it to my master degree and I >> would like to contrib with my 3 cents. >> >> I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm >> and my contribution is about it. Sorry if I am a little bit prolix. >> >> The first thing is to create a plugin package. A a single file to group a >> lot of files. It can be a zip package, tar, gzip or anything that already >> has some C open source API to pack / unpack. This way we can upload / >> download a single file and extract it localy. I will call it the package. >> >> Inside the package is necessary to have a package descriptor. It can be a >> XML file, CSV, txt, JSON or any kind of structured file to describe the >> content of the package. This file should have the information about the >> plugin like the author, version, website, license, OS, dependencies, >> compatibility with PD "flavors" (vanilla, extended, Lork ....), >> pre-installation script, post-installation script, uninstall script, key >> words, ... >> >> Pre and post installation script are used to create SQL tables, files or >> other things. Maybe it is not useful in PD. Uninstall script should clean >> the mess if you want to remove a plugin. Dependencies is a complex problem >> because it should care about libraries and circular dependencies. Maybe it >> is the hardest problem to solve. >> >> These two things will define the PD plugin: The package file and the >> plugin descriptor inside the package. The package structure should be >> defined as a standard. So we should agree, for example, about the name of >> the descriptor, the folder where the plugin will be and the name of the >> package file. Probably a package file can be the name of the >> external.version.something.pd_pkg. >> >> In PD we should have a list of installed plugins. It can be a directory >> with all the plugin descriptors. The user might be able to install new >> plugins manually. It means a local file in my machine that I choose. PD >> will open the package, copy the content to the correct folders and copy >> the descriptor the the correct folder. The uninstall option will do the >> oposite, delete the plugin descriptor and delete the plugin files. >> >> To update from the web, a plugin repository need to be defined. The client >> should have a list of repositories address. (It is good because different >> flavors can have their own plugin repositories and the users can choose >> which one they want to use.) >> >> The plugin server can be implemented with a HTTP server. It will publish >> the list of available plugins on the server. This list can be the list of >> package descriptors in a tar / zip file. Locally, PD will keep these >> lists, one for each server, and it will be used to look for new plugins. >> Add a new server means add the server to the repositories list and >> download the plugin list of the new server. >> >> Since PD has a list of local installed plugins, if you want to check for >> updates PD compares the servers plugin lists with your local list. Easy >> task. Different versions should can be shown and the user would be able to >> choose what to update. These descriptors can be useful also to search for >> plugins by author, version, key words, versions, ... >> >> Update a plugin means to create a list of update, download the packages to >> a temp directory and install them locally. >> >> Just to step foward, the server can have a web interface with some PHP >> programming, for instance, that automatically update a package, extract >> the descriptor, put it in the correct folder and put the plugins in the >> correct folder. Just to be easier to maintenance. >> >> Another tool can help developers to pack. Since I did a new plugin I can >> select the folder, fill a form with the meta-data and the tool will create >> the package automatically. >> >> That's it. Sorry if I wrote too much. >> >> cheers >> >> f schiavoni >> >> >> _______________________________________________ >> 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 >> >> > > > > _______________________________________________ > 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

3 3

Re: [PD] enhance pd-extended with pd-l2ork featues ?
by Fero Kiraly 06 Feb '13

06 Feb '13

if you are using arch linux, write to console yaourt -S pd-l2ork it will do all job for you ;) fk.

7 19

Fwd: Fwd: file format for GEM
by Stephan Elliot Perez 06 Feb '13

06 Feb '13

---------- Forwarded message ---------- From: Stephan Elliot Perez <dreamoftheshoreofanotherworld(a)gmail.com> Date: Wed, Feb 6, 2013 at 3:25 PM Subject: Re: [PD] Fwd: file format for GEM To: IOhannes m zmoelnig <zmoelnig(a)iem.at> Hi again, I have tried converting to .mov with the photo-jpeg and motion-jpeg codecs, but each time, whether it be with MPEG-Streamclip or Adobe Premiere, the conversion fails near the end. I thought that perhaps there might be be a limit to the space allowed to me on the school's computer, but I find that unlikely... So I still have the problem with some clips (and only with a few) that they are very laggy when played back as .mov files. In Adobe Premiere in the .mts format (AVCHD), this was not a problem. Then I converted them using the Apple Intermediary Codec. Does someone know the cause of this? Thanks, Stephan On Tue, Feb 5, 2013 at 9:13 AM, IOhannes m zmoelnig <zmoelnig(a)iem.at> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-02-04 22:29, Stephan Elliot Perez wrote: > > But with photo-jpeg, some of the files were getting to be over 20 > > GB. D= > > > > 20GB shouldn't be a big deal with todays harddisks. > if you care for speed, you might even want to get a (not so cheap) SSD > disk that holds all your videos. > > fgamsdr > IOhannes > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlEQvw8ACgkQkX2Xpv6ydvQrDwCcCnEoxQ4fWf5uitScHevieKWC > imYAni54KqBLg0NcVVc89vgaLBz68xXA > =VI7H > -----END PGP SIGNATURE----- > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

1 0

Freezes with Pd-Extended and Jack
by Esteban Viveros 06 Feb '13

06 Feb '13

Hello, I'm using pd-extended 0.43.4, installed via Hans-Cristoph Steiner ppa. I'm using this version because I can't install the stable version in Ubuntu 12.04. The problem is, when I start pd with Jack in -rt mode or wherever mode, if I turn on dsp, they work well, but if I turn off, and try to turn on yet dsp, pd-extended freeze... Closing Qjackctl (after some time ubuntu can close that) pd-extended returns to work, and I can use on alsa directly sucessfull.. Someone knows where I can comunicate this bug to the developers? Is here the place? Thanks a lot! -- Esteban Viveros (27) 8815 7170 (27) 3066 0359 (11) 95761 4125 (11) 2738 7868 www.bandpage.com/estebanviveros <http://soundcloud.com/estebanviveros> https://www.facebook.com/estebanviveros.art http://www.papodecompositor-es.blogspot.com.br/ http://expurgacao.art.br/

8 27

Re: [PD] Plugin auto install feature to Pure data
by colet.patrice 06 Feb '13

06 Feb '13

Here is the tcl module for untar http://tcllib.sourceforge.net/doc/tar.html -------- Message d'origine -------- De : fls(a)rendera.com.br Date : 05/02/2013 21:11 (GMT+00:00) A : pd-list(a)iem.at Objet : Re: [PD] Plugin auto install feature to Pure data I agree that depencencies should not install libs. Since it seems to be the biggest problem, maybe it should be postponed. Yes, the repository maintenance can be solved latter too. Let's first have a repository and then think about the best way to keep it on date. :-) I don't have skills with TCL but I agree that it is a good choice. Is there how to open zip/tar/something files in TCL? If it can open the package, it's perfect. IMO, the first step is to install locally. Define a package structure, a package header and the install script. Probably it can be used by the remote install. I suggest the following package structure: /content.txt /bin/files <-to compiled files (architecture dependent) /help/files <-to help files (architecture independent) /tcl/files <-to gui files (architecture independent) This structure should be compacted / grouped in a file with some name convention like package_name.version.pd_pkg. The content.txt can be as follow: name: author: version: key-words: web-site: license: flavor: dependencies: instructions: The install script should select a package, open it, copy the external to the external dir, copy the help and tcl files to the correct folder, rename the content.txt to the package name + version and copy it to an folder designed for this kind of file. Cheers f schiavoni _______________________________________________ Pd-list(a)iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

2 1

RE : Re: RE : Plugin auto install feature to Pure data
by colet.patrice 05 Feb '13

05 Feb '13

Wget and tar could be replaced with TCL http and tar module at client side, and for server side I'd use PHP and mySQL, or maybe python instead of PHP... One thing I'm wondering is how to share packages between several servers, would all http servers need a build farm? -------- Message d'origine -------- De : fls(a)rendera.com.br Date : 04/02/2013 17:57 (GMT+00:00) A : pd-list(a)iem.at,"colet.patrice" <colet.patrice(a)free.fr> Objet : Re: RE : [PD] Plugin auto install feature to Pure data I'm not used with TCL Tk but my guess it that it should be enough. In linux wget + tar + shell script can solve it. I don't know how portable is a solution like this. The PHP + SQL was just a suggestion of a tool to update the repository. Nothing about PD. About the dependencies, if the external uses only the ANSI C API, it will not be a problem. It is more confuse if it uses some special lib that should be installed with the external. As I would not like to install automatically a new library in my machine, I think the plugin descriptor can has a field called instruction where the author can specify how to install the dependencies. And that's it. cheers f schiavoni > Hello, that's a quite interesting subject I've been thinking about for pdx > since a time, thank you for the contribution...Â like you said it might be > complicated to resolve all dependences required by an external, so I think > that adding other dependences like php sql or json would make it even more > complicated... Why not just using the native client interpreted langage, > TCL-TK? With the help of a command line like wget included with the tcl > script and a bunch of pkg files that should be enough, wouldn't it? > > > > > > > -------- Message d'origine -------- > De : fls(a)rendera.com.br > Date : 03/02/2013 20:22 (GMT+00:00) > A : pd-list(a)iem.at > Objet : [PD] Plugin auto install feature to Pure data > > Hi list > > I would like to write before but unfortunately I couldn't. Some weeks ago > people started to talk about the development of some auto install > mechanism to Pure Data, like the apt-get. It is an amazing idea. I > researched and developed some thing like it to my master degree and I > would like to contrib with my 3 cents. > > I studied the plugin structure of Netbeans, Eclipse, Fire Fox, deb and rpm > and my contribution is about it. Sorry if I am a little bit prolix. > > The first thing is to create a plugin package. A a single file to group a > lot of files. It can be a zip package, tar, gzip or anything that already > has some C open source API to pack / unpack. This way we can upload / > download a single file and extract it localy. I will call it the package. > > Inside the package is necessary to have a package descriptor. It can be a > XML file, CSV, txt, JSON or any kind of structured file to describe the > content of the package. This file should have the information about the > plugin like the author, version, website, license, OS, dependencies, > compatibility with PD "flavors" (vanilla, extended, Lork ....), > pre-installation script, post-installation script, uninstall script, key > words, ... > > Pre and post installation script are used to create SQL tables, files or > other things. Maybe it is not useful in PD. Uninstall script should clean > the mess if you want to remove a plugin. Dependencies is a complex problem > because it should care about libraries and circular dependencies. Maybe it > is the hardest problem to solve. > > These two things will define the PD plugin: The package file and the > plugin descriptor inside the package. The package structure should be > defined as a standard. So we should agree, for example, about the name of > the descriptor, the folder where the plugin will be and the name of the > package file. Probably a package file can be the name of the > external.version.something.pd_pkg. > > In PD we should have a list of installed plugins. It can be a directory > with all the plugin descriptors. The user might be able to install new > plugins manually. It means a local file in my machine that I choose. PD > will open the package, copy the content to the correct folders and copy > the descriptor the the correct folder. The uninstall option will do the > oposite, delete the plugin descriptor and delete the plugin files. > > To update from the web, a plugin repository need to be defined. The client > should have a list of repositories address. (It is good because different > flavors can have their own plugin repositories and the users can choose > which one they want to use.) > > The plugin server can be implemented with a HTTP server. It will publish > the list of available plugins on the server. This list can be the list of > package descriptors in a tar / zip file. Locally, PD will keep these > lists, one for each server, and it will be used to look for new plugins. > Add a new server means add the server to the repositories list and > download the plugin list of the new server. > > Since PD has a list of local installed plugins, if you want to check for > updates PD compares the servers plugin lists with your local list. Easy > task. Different versions should can be shown and the user would be able to > choose what to update. These descriptors can be useful also to search for > plugins by author, version, key words, versions, ... > > Update a plugin means to create a list of update, download the packages to > a temp directory and install them locally. > > Just to step foward, the server can have a web interface with some PHP > programming, for instance, that automatically update a package, extract > the descriptor, put it in the correct folder and put the plugins in the > correct folder. Just to be easier to maintenance. > > Another tool can help developers to pack. Since I did a new plugin I can > select the folder, fill a form with the meta-data and the tool will create > the package automatically. > > That's it. Sorry if I wrote too much. > > cheers > > f schiavoni > > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >

3 2

Re: [PD] enhance pd-extended with pd-l2ork featues ?
by Ivica Bukvic 05 Feb '13

05 Feb '13

Step 1: go to http://l2ork.music.vt.edu/main/?page_id=56 Step 2: look for section that says the following: *Pd-L2Ork*1 - “Burrito Supreme” version of Pd-L2Ork (best option for newcomers) - 32-bit script-based installer<http://l2ork.music.vt.edu/data/pd/pd-l2ork-i686-20130126.tar.bz2> (v.20130126) - 32-bit deb<http://l2ork.music.vt.edu/data/pd/pd-l2ork-i686-20130126.deb> (v.20130126) - 64-bit script-based installer<http://l2ork.music.vt.edu/data/pd/pd-l2ork-x86_64-20130126.tar.bz2> (v.20130126) - 64-bit deb<http://l2ork.music.vt.edu/data/pd/pd-l2ork-x86_64-20130126.deb> (v.20130126 Step 3: Download the version of "script-based installer" you need (32-bit or 64-bit) Step 4: decompress downloaded file, for instance for a 32-bit version: tar -jxf pd-l2ork-i686-20130126.tar.bz2 Step 5: install it cd pd-l2ork* sudo make install Step 6: enter your sudo password to install Step 7: run pd-l2ork from the menu or command line --------------- If you need to compile it from scratch, please read instructions on the page above, the instructions are all there (including what I wrote above)... On Tue, Feb 5, 2013 at 2:18 PM, Esteban Viveros <emviveros(a)gmail.com> wrote: > Ok... That's nice... but I don't know how I can do it exactly.. > > Esteban Viveros > > soundcloud.com/estebanviveros > www.facebook.com/estebanviveros.art > > (27) 8815 7170 > (27) 3066 0359 > (11) 95761 4125 > (11) 2738 7868 > > Enviado por celular. > Em 05/02/2013 00:31, "Ivica Bukvic" <ico(a)vt.edu> escreveu: > > I indicated several times on this list that you can do binary install of >> pd-l2ork in/usr/local folder. In addition to debs, the website also >> provides both such prebuilt binaries as well as a one-command compile >> script. This allows the two to coexist without any problems... >> >> The pd-l2ork conflicts with 'puredata' and 'pd-extended' so you can't >> currently. >> >> .hc >> >> >> On 02/04/2013 05:59 PM, Esteban Viveros wrote: >> > Sorry to bring the dead... But I can install at this moment pd-l2ork and >> > pd-extended in the same OS (ubuntu 12.04) if it is possible how can I do >> > that exactly? >> > >> > >> > 2013/1/22 Hans-Christoph Steiner <hans(a)at.or.at> >> > >> >> >> >> pd-extended should use puredata-utils, but it doesn't yet. It will in >> the >> >> next release. Nothing requires puredata-utils, its optional. >> >> >> >> .hc >> >> >> >> On 01/22/2013 11:16 AM, Ivica Bukvic wrote: >> >>> AFAIK I use pd-l2ork exclusively, not pd. I f you find it anywhere >> that >> >> I'm >> >>> not using that please let me know so I can fix it. >> >>> >> >>> I need to check whether pdsend/receive is indeed identical before >> making >> >>> any calls on that matter. Even then if one has to uninstall pd-utils >> due >> >> to >> >>> conflict with pd-L2ork what would that mean to the rest of the >> install as >> >>> far as pd-extended is concerned? Would it still work, or is pd-utils a >> >>> dependency (as far as I can tell it should be a dependency because >> >>> otherwise pd wouldn't work without it)? >> >>> On Jan 22, 2013 10:46 AM, "IOhannes m zmoelnig" <zmoelnig(a)iem.at> >> wrote: >> >>> >> >>> On 2013-01-22 16:30, Ivica Ico Bukvic wrote: >> >>>>>> >> >>>>>> Pd-l2ork indeed has its own folder (including pd-l2ork-externals in >> >>>>>> home folder and settings file). The conflict is in the /usr/bin/ >> >>>>>> folder with binaries that share the same name but not necessarily >> >>>>>> code-base (I think pdsend/pdreceive and something else, >> >>>>>> IIRC--cannot remember off top my head). >> >>> >> >>> since i trust that you haven't done anything to pdsend/pdreceive, i >> >>> guess it is save to simple use the debian-package "puredata-utils" >> >>> instead of providing your own. >> >>> alternatively, you can make your package conflict with >> >>> "puredata-utils", in order to avoid the conflict. >> >>> >> >>> the other thing that comes to my mind is obviously "pd" itself. >> >>> i guess you are using "pd-l2ork" as binary name, so this wouldn't be a >> >>> problem. >> >>> (but if indeed you do use "pd" as the binary name, i suggest to switch >> >>> to "pd-l2ork" instead and eventually provide an alternative diversion >> >>> from pd to pd-l2ork, using the "update-alternatives" mechanism) >> >>> >> >>> fgamsdr >> >>> IOhannes >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>> >> >> >> >> _______________________________________________ >> >> 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

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 February 2013