Re: [PD] directory hierarchy solution ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-04 22:54, Hans-Christoph Steiner wrote: Currently that is implemented like this in the Debian packages: /usr/lib/pd (libraries shared among all Pd distros) small amendment: i think this should be explicitely only for libraries that are binary compatible with pd-vanilla. judging from a recent thread, this would rule out pd-l2ork. /usr/lib/puredata (Pd-vanilla) /usr/lib/pd-extended /usr/lib/pd-l2ork and i want to stress (in support of the above layout), that we/you shouldn't try to invent yet another fiel system layout, but rather stick to what we already have (mostly in debian) fgamsdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEQvVUACgkQkX2Xpv6ydvQR8QCg0RewUP3nSA6Mpu4Er7iZGOc1 msYAnjN7QKohUd4eVxWYjcmn5kPxPXOv =qW+K -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] file format for GEM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-04 21:38, Thomas Mayer wrote: I just wanted to state, that you cannot distribute arbitrary tasks in Pd to several threads, and therefore CPU cores without a) stating it explicitely via [pd~] (or [netsend]/[netreceive] or any other way of inter-instance communication), or b) using externals that support threading. seems like i missed b) in your original post. esp. since i think that b) and chris' comment on the CPU-meter are both important with resp. to the op's question. fgm,asdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEQvpYACgkQkX2Xpv6ydvQJsgCfU1bO98ZxmFnhHWOLZg0Lp+dm NzoAoJK/FPJkMj0PHl8WCm7Uc/ZkujJt =Iwj4 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: file format for GEM
-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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] RE : Re: RE : Plugin auto install feature to Pure data
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 : f...@rendera.com.br Date : 04/02/2013 17:57 (GMT+00:00) A : pd-list@iem.at,colet.patrice colet.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] Fwd: absolute vs relative filepath on oggread~
On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote: hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day! If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location). IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused. For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with. (or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [Patchingcirclebxl] Pure Data Patching Circle Brussels @ Variable #06
Here is the announce for the next session of the Pure Data Patching Circle in Brussels, Constant Variable place. welcome (please register) sorry for crossposting hello, voici l'annonce pour la prochaine session du Cercle de Developpement Pure Data à Bruxelles, Constant Variable. bienvenue (veuillez réserver svp) veuillez excuser pour la redite s'il en est... bien cordialement, Olivier Meunier http://patchingcircles.be http://ogeem.be -- _*Pure data patching circle Brussels @ Variable #06*_ *16th february 2013* *EN :* *//*The Patching Circles are open workshop session to learn and share about the pure-data software and other. This session will make us a loop, permitting us to revisit sound processing techniques as well as exploring more the RaspberryPi, with the presentation of the ongoing project of Pierre Massat of a pure-data guitar effect pedal. Pierre was one of our past attendees, and continued to work on his patches on the RaspberryPi, arriving at good result, with the help of recent focus of the pure-data community on this machine. Also, other have found ways to stream video from a webcam and sound with external usb audio input... http://guitarextended.wordpress.com the workshop will be held between*/13:00h and 19:00h on the 16th of February 2012/* session open and free to all, debuting as well as veteran, subscribe please: pdcirc...@ogeem.be _*mailing list: *_ to get updates and participate in the group discussion, you can join the mailing list here https://listes.domainepublic.net/cgi-bin/mailman/listinfo/patchingcirclebxl *FR* *//*Les Patching Circles sont des sessions d'ateliers ouverts pour apprendre et partager à propos du logiciel Pure-data et autres. *//* cette session nous fera faire une boucle, nous faisant revisiter les techniques de traitements du son tout en continuaunt d'explorer les capacités du RaspberryPi, avec la présentation du projet en cours de Pierre Massat : un module d'effet en pure-data pour guitare électrique. Pierre est un de nos précédents participants, et a continuer à travailler sur ses patches sur le RaspberryPi, arrivant à un bon résultat, soutenu par la récente attention de la communauté Pure-data pour cette petite machine. Aussi, nous avons trouvé des méthodes pour streamer son et video, développement commun en cours... http://guitarextended.wordpress.com l'atelier se tiendra le /*16 Février 2013 entre 13h et 19h*/. session gratuite et ouverte à tous, débutant comme confirmé, inscription svp : pdcirc...@ogeem.be *_mailing list : _* Pour avoir des infos et discussions sur le sujet avec le groupe de participants, rendez vous sur la mailing liste https://listes.domainepublic.net/cgi-bin/mailman/listinfo/patchingcirclebxl *direction* : Constant Variable Rue Gallait / Gallaitstraat 80 1030 Schaerbeek / Schaarbeek par Transport public: Tram 25, 55, 94: Liedt -- This project is supported by the Ministery of Culture of the Wallonia-Brussels Federation, Digital Arts -- -- Ce projet est supporté par le Ministère de la Culture de la Fédération Wallonie-Bruxelles, Arts Numériques-- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Range Slider Object
On 04/02/13 23:37, Simon Wise wrote: On 04/02/13 14:09, Jonathan Wilkes wrote: can set a boundary range within the slider. sort of like being able to select a range of a particular sample graphically. heres the max picture reference link: look at [pd edit] inside one of the helps for sliders .. [vslider-help] will do ... you can set the range of ordinary pd sliders via a message But the point is probably to get visual feedback for a range between two values, bounded within a min and max value. For that to work the indicator tick must be expandable while staying within the gui border. (Well, it does sometimes expand to 4 pixels wide right in the middle but that's a bug.) sure, the tick is not adjustable and if you want some visual feedback [cnv] will do the job ... here's another example, a bit more elaborate and all vanilla ... its mid summer here, way too hot for anything serious! here is another iteration, the end points and zoom adjustable plus some state saving ... just using sliders and canvases. open rangeslider.pd, it uses vrangeslider.pd Simon vrangeslider.pd Description: application/puredata rangeslider.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Path issue with Pd-extended 0.43.4 on Win7 x64
Ok, I found figured out a little more on this issue. I had installed using the windows installer to my d: drive, where I sequester my audio applications: D:\Program Files (x86) Using this program location, libraries do not load whether I use: C:\Users\rga\AppData\Roaming\Pd or C:\Program Files\Common Files\Pd But when I install to: C:\Program Files (x86) Then the libraries load, from either the AppData or Common Files path. I still get the error message on startup: Cannot read plugins folder: 'C:/Program Files (x86)/pd/%SystemRoot%/Fonts' This path looks malformed, since %SystemRoot% itself is: C:\Windows This would yield: 'C:/Program Files (x86)/pd/C:/Windows/Fonts' Which of course doesn't exist. Thanks for the help, now that I can load libraries I should be able to move ahead with 0.43.4 I am noticing several errors with trying out the various built in libraries. Would those be reported here, or to the library maintainer ? Regards, Randy On 2/4/2013 2:22 PM, Randall Alley wrote: After looking into the issue further, I found the help browser also failing, with the following error report: couldn't read directory C:/Users/rga/Application Data/*: permission denied couldn't read directory C:/Users/rga/Application Data/*: permission denied while executing glob -nocomplain -type d -path $dir * (procedure build_references line 15) invoked from within build_references (procedure ::helpbrowser::open_helpbrowser line 19) invoked from within ::helpbrowser::open_helpbrowser (procedure menu_helpbrowser line 2) invoked from within menu_helpbrowser (menu invoke) - I got the help browser working an I was able to fix a permissions error in the HomeUsers group that got rid of the the help browser error, and the read plugins folder error I mentioned previously: Cannot read plugins folder: 'C:/Users/rga/Application Data/' But, Pd is still not loading the Modal_Object_Library if I place it in C:/Users/rga/AppData/Roaming/Pd Randy On 2/4/2013 1:31 PM, Randall Alley wrote: Hi all, and thanks for the great work on Pd 0.43.4 ! I'm somewhat new to Pd, and am still learning how to get around, but I'm having a problem which I've seen mentioned by others, so I thought I'd report the issue. After installing 0.43.4 using the Windows installer, and launching Pd, I see the following error in the log window (log level 4): Cannot read plugins folder: 'D:/Program Files (x86)/pd/%SystemRoot%/Fonts' Cannot read plugins folder: 'C:/Users/rga/Application Data/' I have confirmed that the Windows 'junction' that redirects /Application Data/ references to c:/Users/rga/AppData/Roaming/ is present and seems to be working normally. I understand that to add a library on load, I should be able to drop it into /AppData/Roaming/Pd, where it should be found and loaded. This is not working. I did create a directory /AppData/Roaming/Pd, but that didn't help. Until this is fixed, can I load a library, in particular Model_Object_Library, in another way, or manually ? By the way, this problem was encountered by a more knowledgeable user regarding 0.43.1 Pd-extended back in April of 2012: http://puredata.hurleur.com/sujet-7111-path-issue-extended-win7-x64 Any help would be appreciated, and thanks ! Randy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RE : Plugin auto install feature to Pure data
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.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] 0.43.4 plugin~ - does it work 4 u?
The help patch doesn't crash for me, but I never use plugins or that object, so I'm not a good test case. In any case, if you find the issue file a bug report with info on how to reproduce it. .hc On 02/05/2013 12:07 AM, Billy Stiltner wrote: on ubuntustudio 12.10 from the help browser when opening plugin~ help pd poofs into thin air i can type plugin~ into an object box and click out of it with no problem have not relocated my plugin names list yet to try to load one ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] directory hierarchy solution ?
On 02/05/2013 03:05 AM, IOhannes m zmoelnig wrote: On 2013-02-04 22:54, Hans-Christoph Steiner wrote: Currently that is implemented like this in the Debian packages: /usr/lib/pd (libraries shared among all Pd distros) small amendment: i think this should be explicitely only for libraries that are binary compatible with pd-vanilla. judging from a recent thread, this would rule out pd-l2ork. /usr/lib/puredata (Pd-vanilla) /usr/lib/pd-extended /usr/lib/pd-l2ork and i want to stress (in support of the above layout), that we/you shouldn't try to invent yet another fiel system layout, but rather stick to what we already have (mostly in debian) fgamsdr IOhannes Strongly agree on both counts! .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
On 02/05/2013 04:30 AM, Roman Haefeli wrote: On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote: hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day! If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location). IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused. For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with. (or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way) Roman I agree, relative should be relative to the patch. Please file a bug report on that. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
Never done that before, excuse my idiocy and tell me how! Thanx! On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner h...@at.or.atwrote: On 02/05/2013 04:30 AM, Roman Haefeli wrote: On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote: hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day! If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location). IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused. For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with. (or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way) Roman I agree, relative should be relative to the patch. Please file a bug report on that. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Òscar Martínez Carmona ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] package system for Pd WAS: Plugin auto install feature to Pure data
The entire thing could easily be implemented in Tcl. Indeed I think Tcl is a good language for it since it is really easy to work with network communication and strings in Tcl. For a precedent, MacPorts is a large package management system written in Tcl. And currently, Pd always comes with Tcl, so we know its available on all platforms Pd runs on (except for mayvery obscure ones like iPodLinux for the first iPods). A Debian apt repo does not use any dynamic content in it (i.e. web pages generated by php, python, etc). The repo files are generated using tools, but then are completely static and can be served up by any web server. This is definitely the better approach for the server. I can't see anything gained by making the server dynamic, and it does add complexity and possible security issues. As for sharing packages across multiple servers, as long as there is a way to verify the authenticity and correctness of a package, they can be easily copied around. In Debian, this is done with by using sha256/sha1/md5 hashes for the packages and gpg signatures on the list of hashes. The real question remains: who is going to work on implementing this? I can contribute, but I don't have time to lead this effort. .hc On 02/05/2013 05:04 AM, colet.patrice wrote: 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 : f...@rendera.com.br Date : 04/02/2013 17:57 (GMT+00:00) A : pd-list@iem.at,colet.patrice colet.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] Fwd: absolute vs relative filepath on oggread~
In the Help menu, click on Report a bug. :-) .hc On 02/05/2013 11:08 AM, Òscar Martínez Carmona wrote: Never done that before, excuse my idiocy and tell me how! Thanx! On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner h...@at.or.atwrote: On 02/05/2013 04:30 AM, Roman Haefeli wrote: On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote: hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day! If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location). IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused. For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with. (or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way) Roman I agree, relative should be relative to the patch. Please file a bug report on that. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[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.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] Path issue with Pd-extended 0.43.4 on Win7 x64
Here's the bug report on this issue, could everyone add their experience and discoveries to the report so that they don't get lost? I'm happy to fix issues on Windows if there are good bug reports so I can easily reproduce them. But since that's the only time I ever use Windows, fixing Pd bugs, I have often have no idea what's a problem and how things should behave. https://sourceforge.net/tracker/index.php?func=detailaid=3601922group_id=55736atid=478070# As for reporting library issues, you can always bring them up on this list, but not everyone is on this list, so its probably also good to contact the author. .hc On 02/05/2013 10:27 AM, Randall Alley wrote: Ok, I found figured out a little more on this issue. I had installed using the windows installer to my d: drive, where I sequester my audio applications: D:\Program Files (x86) Using this program location, libraries do not load whether I use: C:\Users\rga\AppData\Roaming\Pd or C:\Program Files\Common Files\Pd But when I install to: C:\Program Files (x86) Then the libraries load, from either the AppData or Common Files path. I still get the error message on startup: Cannot read plugins folder: 'C:/Program Files (x86)/pd/%SystemRoot%/Fonts' This path looks malformed, since %SystemRoot% itself is: C:\Windows This would yield: 'C:/Program Files (x86)/pd/C:/Windows/Fonts' Which of course doesn't exist. Thanks for the help, now that I can load libraries I should be able to move ahead with 0.43.4 I am noticing several errors with trying out the various built in libraries. Would those be reported here, or to the library maintainer ? Regards, Randy On 2/4/2013 2:22 PM, Randall Alley wrote: After looking into the issue further, I found the help browser also failing, with the following error report: couldn't read directory C:/Users/rga/Application Data/*: permission denied couldn't read directory C:/Users/rga/Application Data/*: permission denied while executing glob -nocomplain -type d -path $dir * (procedure build_references line 15) invoked from within build_references (procedure ::helpbrowser::open_helpbrowser line 19) invoked from within ::helpbrowser::open_helpbrowser (procedure menu_helpbrowser line 2) invoked from within menu_helpbrowser (menu invoke) - I got the help browser working an I was able to fix a permissions error in the HomeUsers group that got rid of the the help browser error, and the read plugins folder error I mentioned previously: Cannot read plugins folder: 'C:/Users/rga/Application Data/' But, Pd is still not loading the Modal_Object_Library if I place it in C:/Users/rga/AppData/Roaming/Pd Randy On 2/4/2013 1:31 PM, Randall Alley wrote: Hi all, and thanks for the great work on Pd 0.43.4 ! I'm somewhat new to Pd, and am still learning how to get around, but I'm having a problem which I've seen mentioned by others, so I thought I'd report the issue. After installing 0.43.4 using the Windows installer, and launching Pd, I see the following error in the log window (log level 4): Cannot read plugins folder: 'D:/Program Files (x86)/pd/%SystemRoot%/Fonts' Cannot read plugins folder: 'C:/Users/rga/Application Data/' I have confirmed that the Windows 'junction' that redirects /Application Data/ references to c:/Users/rga/AppData/Roaming/ is present and seems to be working normally. I understand that to add a library on load, I should be able to drop it into /AppData/Roaming/Pd, where it should be found and loaded. This is not working. I did create a directory /AppData/Roaming/Pd, but that didn't help. Until this is fixed, can I load a library, in particular Model_Object_Library, in another way, or manually ? By the way, this problem was encountered by a more knowledgeable user regarding 0.43.1 Pd-extended back in April of 2012: http://puredata.hurleur.com/sujet-7111-path-issue-extended-win7-x64 Any help would be appreciated, and thanks ! Randy ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] directory hierarchy solution ?
of course, I dont want to invent something new. I am only trying to improve archlinux packages. previously I successfully finished pd-extended and pd-l2ork build scripts accessed via aur.. now my aim is to repair the situation that only one pd distro can installed.. so I am learning from you and from debian... Still I am not sure how to divide that packages into pd-utils (pdsend, pd receive) and other stuff... cheers fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] RE : package system for Pd WAS: Plugin auto install feature to Pure data
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 h...@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@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.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] [PD-announce] Pd vanilla 0.44-2 (update to fix denormal behavior for Raspberry Pi)
I'm not involved in the Pd linux distributions for Pi but new versions of Pd seem to trickle down to them after some delay. But if you want the newest, just grab it, un-tar it into your home directory, and in your .bashrc make an alias like alias pd=/home/pi/pd/bin/pd and you'll be able to type pd to new shell windows to get it started - that's how I do it anyhow. cheers Miller On Tue, Feb 05, 2013 at 02:54:52AM -0200, Alexandre Torres Porres wrote: how difficult to just get this version in the raspian repo so we can all just do apt-get? that's a good one since that's as far as my linux expertise goes so far, the RPI is my first linux ;) 2013/2/3 me.grimm megr...@gmail.com what would be the best practice for installing this? of course i could cd /to/pd/bin/ ./pd but better yet just pd from terminal would be swanky and maybe not just run pd from ~/Desktop or ~/ or whatever. how difficult to just get this version in the raspian repo so we can all just do apt-get? m On Fri, Feb 1, 2013 at 1:40 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, This is only of interest to Raspberry Pi users - I've fixed the denormal problem Katja reported and recompiled - you can get that and the new sources from the usual sources: http://crca.ucsd.edu/~msp/software.htm or git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd vanilla 0.44-2 (update to fix denormal behavior for Raspberry Pi)
That silent trickle down is mostly due to the diligent work of IOhannes, I want to point out. :-) He is doing the vast majority of the work for maintaining the 'puredata' suite in Debian. .hc On 02/05/2013 01:01 PM, Miller Puckette wrote: I'm not involved in the Pd linux distributions for Pi but new versions of Pd seem to trickle down to them after some delay. But if you want the newest, just grab it, un-tar it into your home directory, and in your .bashrc make an alias like alias pd=/home/pi/pd/bin/pd and you'll be able to type pd to new shell windows to get it started - that's how I do it anyhow. cheers Miller On Tue, Feb 05, 2013 at 02:54:52AM -0200, Alexandre Torres Porres wrote: how difficult to just get this version in the raspian repo so we can all just do apt-get? that's a good one since that's as far as my linux expertise goes so far, the RPI is my first linux ;) 2013/2/3 me.grimm megr...@gmail.com what would be the best practice for installing this? of course i could cd /to/pd/bin/ ./pd but better yet just pd from terminal would be swanky and maybe not just run pd from ~/Desktop or ~/ or whatever. how difficult to just get this version in the raspian repo so we can all just do apt-get? m On Fri, Feb 1, 2013 at 1:40 AM, Miller Puckette m...@ucsd.edu wrote: Hi all, This is only of interest to Raspberry Pi users - I've fixed the denormal problem Katja reported and recompiled - you can get that and the new sources from the usual sources: http://crca.ucsd.edu/~msp/software.htm or git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data cheers Miller ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.com _ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RE : package system for Pd WAS: Plugin auto install feature to Pure data
I think really the key is to find someone who is going to start working on this, then help them figure out the issues as they request it. I think its counterproductive if we set up too many conditions of starting if none of us are going to work on it :-) Then they can decide Tcl or something else, client or server first, or whatever else. Who wants to try the first sketch? We have a package format to start with, its something, but it'll surely need to be changed to support all the ideas: http://puredata.info/docs/developer/LibraryTemplate .hc On 02/05/2013 12:48 PM, colet.patrice wrote: 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 h...@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@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.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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
Re: [PD] enhance pd-extended with pd-l2ork featues ?
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 installerhttp://l2ork.music.vt.edu/data/pd/pd-l2ork-i686-20130126.tar.bz2 (v.20130126) - 32-bit debhttp://l2ork.music.vt.edu/data/pd/pd-l2ork-i686-20130126.deb (v.20130126) - 64-bit script-based installerhttp://l2ork.music.vt.edu/data/pd/pd-l2ork-x86_64-20130126.tar.bz2 (v.20130126) - 64-bit debhttp://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 emvive...@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 i...@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 h...@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 zmoel...@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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
if you are using arch linux, write to console yaourt -S pd-l2ork it will do all job for you ;) fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? On Feb 5, 2013 3:01 PM, Fero Kiraly fero.kir...@gmail.com wrote: if you are using arch linux, write to console yaourt -S pd-l2ork it will do all job for you ;) fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [Spam] RE : Re: RE : Plugin auto install feature to Pure data
Hi Colet I don't think so. We can think about several servers (repositories) that the user can choose. So pd-extended can have an official repository and I can have mine. f schiavoni 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 : f...@rendera.com.br Date : 04/02/2013 17:57 (GMT+00:00) A : pd-list@iem.at,colet.patrice colet.patr...@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 : f...@rendera.com.br Date : 03/02/2013Â 20:22Â (GMT+00:00) A : pd-list@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
Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com Cc: pd-list@iem.at pd-list@iem.at Sent: Sunday, February 3, 2013 1:41 PM Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!) [...] If you want I can put together a Kickstarter campaign that outlines all of this doc work that will be needed. I suspect it'd be about two or three months of full-time work. If people are willing to pay me to make these changes I'm happy to do them. As my resume I offer my work on PDDP, in which I contacted lib authors to accept my revisions, updated core docs, reworked the FLOSS manual to be consistent with core docs, and wrote a search plugin to make use of all the changes. (As well as testing that the results worked across platforms.) -Jonathan These things are all true, I think its worth it. I think you might be thinking that there will be more changed than there need to be. Most of the objects would not need documentation changes, or just small changes. Here's the doc work: 1) search plugin - for classes that are copied into the new libs, don't show duplicate results from the legacy library (which is only there for backwards compatability). Probably the best way to do this is add a legacy tag to the old lib stuff. 2) Change the relative pddp links for all 200+ PDDP help patches that points to stuff outside of 5.reference/ (probably can automate much of this process) 3) Find and change all the pddplinks and comments in docs of externals that refer to 5.reference (absolute and relative). (Somewhat automated) 4) Make a good faith effort to amend FLOSS references and other common PD learning materials to document new libs. (Otherwise new users read about legacy stuff while using new stuff, get confused, and write to the list to ask about why the same exact objects get different prefixes in different docs.) 5) Lots of iterative changes to places in the documentation that make a distinction between internal and external objects, including the search plugin, all about Pd patches, tutorials, the Pd manual, and probably a lot else that I'm not thinking of at the moment. 6) Create new documentation to explain _exactly_ how to use standard libs, explaining how to a) get the old behavior of just loading all libs in Pd-extended, b) how to use [import], c) how to use the lib prefix, and d) any other ways of loading libs and the benefits/drawbacks of those approaches. 7) Making a user-friendly doc or patch about legacy libs that explains the legacy author-oriented approach for new (and old) users, focusing esp. on the most popular legacy libs. Without this a lot of documentation on puredata.info-- and esp. on the user and dev list-- becomes difficult to understand and follow. 8) Find entry points into the common Pd learning materials and inject a note about the move from the legacy approach to the new approach, with a link to the doc from #7. 9) Keep a list of all easily translatable sources of documentation on this change, so that translations of the new approach can happen as soon as possible. 10) Check for cross-platform compatibility, to make sure none of the core doc changes or search-plugin changes introduce weirdness somewhere. However, after doing some initial research I see there's a bigger issue before any of this could even happen. Let's say I put up a Kickstarter for a month's worth of doc work on this. I'd have to schedule it for a date after the work is done deciding what names the standard libs should get and what code goes in those libs. That process will probably turn into bikeshedding where none of the real work actually gets done-- I can say this because _substantial_ preliminary discussions for this work already took place 4 years ago on the dev list and we don't have standard libs today. So here's my proposition: I'll work on compiling a list of classes that should have been included in vanilla but aren't yet. I'll exclude objects which are currently in a maintained, aptly-named library build around classes that share some core functionality in common, as those libraries are already standard libraries. I should end up with a list of classes which, in conjunction with the vanilla classes, make it possible to get substantially more work done without relying on hacks or workarounds. We can worry about libname and relationship with vanilla later-- the main point will be that these core objects can all be typed into an object box in Pd extended, without any namespace prefixes, and as long as nothing has been [import]ed or [declare]d it should all just work. If it goes the way I think it will, there won't be any need to have a bunch of new libs, just one that adds long-desired functionality to vanilla that's been missing for so long. None of this initial work requires any discussion whatsoever, since it all exists already on the user and dev lists. So this
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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
Here is the tcl module for untar http://tcllib.sourceforge.net/doc/tar.html Message d'origine De : f...@rendera.com.br Date : 05/02/2013 21:11 (GMT+00:00) A : pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
Ivica.. I don't have sucess... I have only a little window of pd-l2ork with nothing.. I try for terminal and I have this: esteban@Tattoine:~/pd-l2ork-x86_64-20130126$ pd-l2ork error in file /usr/local/lib/pd-l2ork/bin/pd.tk: can't find package tkpng while executing package require tkpng (file /usr/local/lib/pd-l2ork/bin/pd.tk line 583) tcl: /usr/local/lib/pd-l2ork/bin/pd.tk: can't open script 2013/2/5 Hans-Christoph Steiner h...@at.or.at FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- 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/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
I'm in Ubuntu 12.04.2 LTS amd64 2013/2/5 Esteban Viveros emvive...@gmail.com Ivica.. I don't have sucess... I have only a little window of pd-l2ork with nothing.. I try for terminal and I have this: esteban@Tattoine:~/pd-l2ork-x86_64-20130126$ pd-l2ork error in file /usr/local/lib/pd-l2ork/bin/pd.tk: can't find package tkpng while executing package require tkpng (file /usr/local/lib/pd-l2ork/bin/pd.tk line 583) tcl: /usr/local/lib/pd-l2ork/bin/pd.tk: can't open script 2013/2/5 Hans-Christoph Steiner h...@at.or.at FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- 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/ -- 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/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
You need tkpng package as indicated on the top of the website. sudo apt-get install tkpng On Feb 5, 2013 5:44 PM, Esteban Viveros emvive...@gmail.com wrote: I'm in Ubuntu 12.04.2 LTS amd64 2013/2/5 Esteban Viveros emvive...@gmail.com Ivica.. I don't have sucess... I have only a little window of pd-l2ork with nothing.. I try for terminal and I have this: esteban@Tattoine:~/pd-l2ork-x86_64-20130126$ pd-l2ork error in file /usr/local/lib/pd-l2ork/bin/pd.tk: can't find package tkpng while executing package require tkpng (file /usr/local/lib/pd-l2ork/bin/pd.tk line 583) tcl: /usr/local/lib/pd-l2ork/bin/pd.tk: can't open script 2013/2/5 Hans-Christoph Steiner h...@at.or.at FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- 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/ -- 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/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
Yes! Was only this... ;) Thanks a lot! That's the end of carousel of pd installations in my ubuntu.. Pd-extended and Pd-L2ork like the end of musical I see today Les Misérables huehuehuehuehue Sorry for Jokes... 2013/2/5 Ivica Bukvic i...@vt.edu You need tkpng package as indicated on the top of the website. sudo apt-get install tkpng On Feb 5, 2013 5:44 PM, Esteban Viveros emvive...@gmail.com wrote: I'm in Ubuntu 12.04.2 LTS amd64 2013/2/5 Esteban Viveros emvive...@gmail.com Ivica.. I don't have sucess... I have only a little window of pd-l2ork with nothing.. I try for terminal and I have this: esteban@Tattoine:~/pd-l2ork-x86_64-20130126$ pd-l2ork error in file /usr/local/lib/pd-l2ork/bin/pd.tk: can't find package tkpng while executing package require tkpng (file /usr/local/lib/pd-l2ork/bin/pd.tk line 583) tcl: /usr/local/lib/pd-l2ork/bin/pd.tk: can't open script 2013/2/5 Hans-Christoph Steiner h...@at.or.at FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- 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/ -- 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/ -- 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/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
Yay, I've just reported a bug! On Tue, Feb 5, 2013 at 5:13 PM, Hans-Christoph Steiner h...@at.or.atwrote: In the Help menu, click on Report a bug. :-) .hc On 02/05/2013 11:08 AM, Òscar Martínez Carmona wrote: Never done that before, excuse my idiocy and tell me how! Thanx! On Tue, Feb 5, 2013 at 4:59 PM, Hans-Christoph Steiner h...@at.or.at wrote: On 02/05/2013 04:30 AM, Roman Haefeli wrote: On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote: hey, still having problems with that, by now I'm doing it with the absolute filepath... maybe the solution it'll be making the main applicattion finding out the f*cking path and sending the whole thing to pd via OSC, or maybe trying it another day! If I am not mistaken, it hasn't been mentioned yet (though IOhannes assumed it very early) in this thread that [oggread~ ] oddly reads relative to Pd's start location (unlike many other classes like [textfile] or [readsf~ ] which read relative to the patch's location). IMHO, this makes it very difficult for a patch writer to use relative paths as the patch doesn't have any notion of where Pd was started from. I consider the whole idea of reading relative to Pd's start location flawed. A similar case is the 'open patch.pd path' message to [s pd]. Also this one reads relative to Pd's start location. However, considering that it was implemented this way, because it probably originates from the '-open' commandline flag, where it makes sense to use a path relative to the current working directory for loading a patch, this one is excused. For you, this means if your OSC application knows where Pd was started from, you need to make it use a path relative to that location. Otherwise you you're left with using absolute paths. When dealing with objects like [oggread~], I'd go for absolute paths, it's just seems safer and saner to deal with. (or someone fixes [oggread~ ], which I even wouldn't consider to break backwards compatibility as the current implementation doesn't really allow to use relativ paths in meaningful way) Roman I agree, relative should be relative to the patch. Please file a bug report on that. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Òscar Martínez Carmona ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
During build process, pd-l2ork gets it from: git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem Isn't this the most up-to-date version? On 02/05/2013 04:59 PM, Hans-Christoph Steiner wrote: FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Plugin auto install feature to Pure data
The tclVFS zip option sounds very nice: http://wiki.tcl.tk/12832 It basically makes a .zip file a virtual file system. .hc On 02/05/2013 06:37 PM, colet.patrice wrote: Here is the tcl module for untar http://tcllib.sourceforge.net/doc/tar.html Message d'origine De : f...@rendera.com.br Date : 05/02/2013 21:11 (GMT+00:00) A : pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
Yup, that's the one. .hc On 02/05/2013 07:04 PM, Ivica Ico Bukvic wrote: During build process, pd-l2ork gets it from: git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem Isn't this the most up-to-date version? On 02/05/2013 04:59 PM, Hans-Christoph Steiner wrote: FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
So, the question then is what is broken and what is the source of the problem... On Feb 5, 2013 8:40 PM, Hans-Christoph Steiner h...@at.or.at wrote: Yup, that's the one. .hc On 02/05/2013 07:04 PM, Ivica Ico Bukvic wrote: During build process, pd-l2ork gets it from: git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem Isn't this the most up-to-date version? On 02/05/2013 04:59 PM, Hans-Christoph Steiner wrote: FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RE : package system for Pd WAS: Plugin auto install feature to Pure data
sounds right up my alley but i have not a clue about how to write a line of code in tcl , python nor lua. i was trying to convert the big bunch of wafscript to just a simpl makefile for compiling pugl today and by the time i could get to the end of the spaghetti i realized i don't even remember how to write a make file haha. but i'm still chuggin away at it. On Tue, Feb 5, 2013 at 1:33 PM, Hans-Christoph Steiner h...@at.or.at wrote: I think really the key is to find someone who is going to start working on this, then help them figure out the issues as they request it. I think its counterproductive if we set up too many conditions of starting if none of us are going to work on it :-) Then they can decide Tcl or something else, client or server first, or whatever else. Who wants to try the first sketch? We have a package format to start with, its something, but it'll surely need to be changed to support all the ideas: http://puredata.info/docs/developer/LibraryTemplate .hc On 02/05/2013 12:48 PM, colet.patrice wrote: 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 h...@at.or.at Date : 05/02/2013 16:20 (GMT+00:00) A : pd-list@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.patr...@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 : f...@rendera.com.br Date : 03/02/2013 20:22 (GMT+00:00) A : pd-list@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,
