hi all
i'm very new to the list so maybe i can introduce myself, just a little.
my name is clement charmet, i work as a webdesigner in a french webzine, www.panoplie.org, and more or less as an artist, as i do audio-visual performances, mainly with my 'band' that's called thirtytwobit (http://32bit.free.fr), and participate in or produce various net.art pieces available on http://clemos.free.fr and http://cl3mos.free.fr.
so I got interrested in pure data about one or two years ago, as a student, and began to learn and experience it a very little. actually I ve really been focusing and really working on it for 2 month, programming stuff that outputs sound data to flash or other network related stuff, and using it during our live performances building and playing little crappy synths patches during the show.
my role in the performance is mainly to produce a kind of visual mix, and the originality is that I mainly use browser programming for that (php, javascript, some little flash stuff, soon proce55ing, etc)
i am quite fascinated by the possibilities of pure data, gem, framestein, etc in the fact that it's highly pluggable to other stuff, and really programmable at different skill levels.
i was wondering if there were projects of "pure data player" : as pure data file format is really simple and light, as it's text based, (ie you can generate pure data files easily with any server side language) i was dreaming of a kind of 'pure data player' that would be a kind of plugin only to execute pure data patches, gem or framestein graphics. the whole thing would be as interactive as pure data / gem / framestein patches can be, but there would be no possibility to modify the patch (the real pure data patch should be hidden, actually, and the actual pure data GUI would only be the GUI for programming, not for rendering). the point is that the player would make it possible to embed pure data patches or gem graphics into HTML pages. i was thinking about all this when I first experienced Gem, as the possibilities and way of rendering looked close to Proce55ing applets'.
have such a project even existed, does it seem possible to you ? i actually think it would really be a fucking great project (even if all the functions don't work in it, ie exemple the ones that need permissions or security issues; or the ones that are platform dependent ), but i have no idea if it is possible, and how...
i heard of proce55ing (and Java) synthesis possibilities and a little of this SEEYO Koan plugin, but doing it with pure data objects would be far more interresting to me
the other questions I have are related to the GUI and the Pd message system. did you hear of other pd GUIs that don't use the default tcl/tk stuff at all but only the pd main engine. did you hear of APIs that make pd patches and/or pd messages easier to handle with other programming languages (ie a set of PHP classes that would handle boxes and connections generation and alteration, Flash GUI able to build pd patches from scratch, etc... ) for exemple, maybe one of you coded a PHP/gd script to generate a pic of a patch directly from a pd file.
only questions anyway pure data's damn great as-it-is
all the best
clément
Hi Clément,
and welcome aboard!
clemos wrote:
i was dreaming of a kind of 'pure data player' that would be a kind of plugin only to execute pure data patches, gem or framestein graphics.
<snip!>
the whole thing would be as interactive as pure data / gem / framestein patches can be, but there would be no possibility to modify the patch (the real pure data patch should be hidden, actually, and the actual pure data GUI would only be the GUI for programming, not for rendering).
In the past, these kinds of requests have often started friendly little flamewars on the PD list. The reason being that most people in the PD community hold very close to the free software/open source ideology, and the idea of a closed, non-modifiable patch runs against their ideas of open-ness. Generally, people expect from PD what MAX does--i.e. that you can compile a closed, self-sufficient executable app from it.
The usual response is that since PD is free, there is no need to make an executable out of it. Anyone who wants to play with your patch can simply install PD. In theory, this is fine. In practice, it can be difficult, espc when externals are involved accross multiple platforms.
Another response is to distribute a "live CD" with a Linux base and PD plus all needed externals added on top of it. This may also be fine for some situations [espc gallery installations, etc], but not if you want to share small things on the web.
the point is that the player would make it possible to embed pure data patches or gem graphics into HTML pages.
A little bird whispered in my ear that someone is working on a PD browser plugin. I can neither confirm nor deny these rumors, but I'm curious how it would take externals into account.
I honestly think that the simplest way to get a web-active PD patch would be to make a front end in Proce55ing, Java, Flash or with some database function like PHP. The patch would run on the server, and the browser client coudl communicate with it and stream the results back as an ogg, mp3 or mpeg.
Have a look at Al-Jwarizmi/Gollum for an example of this kind of usage. It provides a web front end for a PDP/PiDiP video stream mixer:
http://www.hackitectura.net/aljwarizmi/screenshots.php
[Used to run live here: http://gollum.artefacte.org/ Maybe it's down???]
did you hear of other pd GUIs that don't use the default tcl/tk stuff at all but only the pd main engine.
http://crca.ucsd.edu/~jsarlo/gripd/
Also, plenty of people are using Java or other interfaces to run SuperCollider because it has a client/server kind of model. So there is no reason you couldn't use Java, Flash, Proce55ing, etc locally in the same way I described above for the web model for PD as well. The key is OSC [Open Sound Control], which allows communication between the clients mentioned, and many others [incl. MAX/MSP, Reaktor...]
best, d.
derek holzer wrote:
In the past, these kinds of requests have often started friendly little flamewars on the PD list. The reason being that most people in the PD community hold very close to the free software/open source ideology, and the idea of a closed, non-modifiable patch runs against their ideas of open-ness.
Generally, people expect from PD what MAX does--i.e. that you can compile a closed, self-sufficient executable app from it.
What I mean to say is that the people who request "executable" patches expect from PD what MAX does.
Sorry for my brain-fart! ;-)
d.
derek holzer wrote:
Hi Clément,
and welcome aboard!
clemos wrote:
i was dreaming of a kind of 'pure data player' that would be a kind of plugin only to execute pure data patches, gem or framestein graphics.
i completely agree with derek's opinion on freedom etc...
however, i think i should point out that there are 2 projects dealing with *browser*-plugins for pd that are somehow "pd player"s, as you do not see the pd-patches (and cannot modify them directly), although they are executed by pd on your local machine (this is something completely different from the gollum/hackitectura thing, which provides a web-front end to control a pd that is running on a server) but of course the pd-patches are pd-patches and are not "closed" or "binary" in any way.
links: http://www.iua.upf.es/~malonso/pdplugin/ (a self containing blugin; you do not need pd installed on your computer to be able to use pd-patches with this plugin)
http://iem.iaem.at/collab/iARS (this one starts an instance of pd, so pd has to be installed on the machine; and it supports Gem ;-) (but quite alpha)
mfg.a.sdr IOhannes
links: http://www.iua.upf.es/~malonso/pdplugin/ (a self containing blugin; you do not need pd installed on your computer to be able to use pd-patches with this plugin)
wow! that was a good question for i think that one has never been published ( or i know little of pd? ).
looks great, that's what we were expecting, i'm eager to test it.
sevy
looks great, that's what we were expecting, i'm eager to test it.
ok, i understand it's brand new and i would like to use it soon, so i'm sending my bug report ( hay solo un bugito de camino o algo ).
the plugins appears in my plugins list. i use mozilla 1.7.3 on fedora core 3. but when i try to load an example, it fails with the following log :
################################### priority 98 scheduling enabled. memory locking enabled. sh: non/pd-watchdog: No such file or directory priority 96 scheduling enabled. memory locking enabled. pd: watchdog process died ####################################
we're close, keep on trying.
suerte, sevy
hi all
thanks for all the answers and docs :)
I knew about all the net functions of pd, and used them quite often, so the hackitectura stuff is really interresting, but brings nothing new to me...
What I meant was not to output a 'closed' app that would not be modifiable, or to have a definetely opaque front view of some patch, but more to have an easy way to publish pd-patches on the web. as pd-patches are only text, they are easy to share over the web, etc, so they are perfect as they are ... the player would display them, you could play with it on a HTML page, and download the file if you want to modifiy it with the pd GUI... so that it's still open-source (more or less like svg stuffs)
the two plugin projects Iohannes sent are really interresting... I'm gonna study them a bit...
about gripd, I heard of it, but once again, it's not what I meant : with gripd, you can build a new GUI only for one patch, but there's no new interface to create the patch itself. seems to me that actually the gripd solution is more or less what I can do now with flash through flashserver or netreceive/send but maybe i'm wrong ?
the point is I'm mainly looking for a new interface to directly build patches, and not only to play pre-build patches... and this new interface (maybe I should say 'API' ) would ease the generation of pd patches. the actual pd-script interface looks quite limited as for exemple you can't get the error messages, you can't get the caracteristics of a function box you create with it (n of inlets/outlets, etc), etc... or maybe I'm wrong again...
what I do during my performances is to directly build pd patches from scratch, so i would like to be able to 'customize' the GUI to make it faster or more efficient for my use, and maybe more interresting graphically...
all the best
clement
On Fri, 19 Nov 2004 07:13:43 +0100, Yves Degoyon ydegoyon@free.fr wrote:
looks great, that's what we were expecting, i'm eager to test it.
ok, i understand it's brand new and i would like to use it soon, so i'm sending my bug report ( hay solo un bugito de camino o algo ).
the plugins appears in my plugins list. i use mozilla 1.7.3 on fedora core 3. but when i try to load an example, it fails with the following log :
################################### priority 98 scheduling enabled. memory locking enabled. sh: non/pd-watchdog: No such file or directory priority 96 scheduling enabled. memory locking enabled. pd: watchdog process died ####################################
we're close, keep on trying.
suerte,
sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
ok pd plug-in is definitely what I was looking for ... thanks a lot but it's quite a pity it's not more well known ...
best clement
clemos wrote:
ok pd plug-in is definitely what I was looking for ... thanks a lot but it's quite a pity it's not more well known ...
both of them (i guess you are referring more to marcos' one, but of course i have to promote iARS for reasons) are rather new. both come out of a rather "academic" environment (active pd-list posters seem to be involved rather indirectly (like günter and me)). both have been published on several conferences (icmc04, dafx04, pd04,...)
but it seems, that the developers do not try get involved with the pd-community too much (which is really a pity)
mfg.a.sdr IOhannes
Hi,
Seems that you started the plugin as user root. This does not work (yet).
We didn't announce the plugin because its not finished, so please be patient. Its coming soon ... :)
Guenter
On Fri, 19 Nov 2004, Yves Degoyon wrote:
looks great, that's what we were expecting, i'm eager to test it.
ok, i understand it's brand new and i would like to use it soon, so i'm sending my bug report ( hay solo un bugito de camino o algo ).
the plugins appears in my plugins list. i use mozilla 1.7.3 on fedora core 3. but when i try to load an example, it fails with the following log :
################################### priority 98 scheduling enabled. memory locking enabled. sh: non/pd-watchdog: No such file or directory priority 96 scheduling enabled. memory locking enabled. pd: watchdog process died ####################################
we're close, keep on trying.
suerte, sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
hey,
as always, you're right! de puta madre, tios!!
would it be a dream if that plugin could be delivered with some libraries ? hemm... pdp/pidip not for now, but simple ones first.
also, can we know which objects are already there?
saludos, sevy
guenter geiger wrote:
Hi,
Seems that you started the plugin as user root. This does not work (yet).
We didn't announce the plugin because its not finished, so please be patient. Its coming soon ... :)
Guenter
On Fri, 19 Nov 2004, Yves Degoyon wrote:
looks great, that's what we were expecting, i'm eager to test it.
ok, i understand it's brand new and i would like to use it soon, so i'm sending my bug report ( hay solo un bugito de camino o algo ).
the plugins appears in my plugins list. i use mozilla 1.7.3 on fedora core 3. but when i try to load an example, it fails with the following log :
################################### priority 98 scheduling enabled. memory locking enabled. sh: non/pd-watchdog: No such file or directory priority 96 scheduling enabled. memory locking enabled. pd: watchdog process died ####################################
we're close, keep on trying.
suerte, sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Sat, 20 Nov 2004, Yves Degoyon wrote:
would it be a dream if that plugin could be delivered with some libraries ? hemm... pdp/pidip not for now, but simple ones first.
It can be delivered with externals. The question is which ones. I am open for suggestions, but it only makes sense to include those that are really necessary.
also, can we know which objects are already there?
Yes, we still have to write docs. There are actually several things that can not be done with the plugin, like reading from the filesystem etc.
This is a serious limitation and we are thinking of including some streaming objects instead.
Another limitation is that you can only make one patch (no abstractions etc.). We thought about defining some sort of Pd-bundle format in order to get rid of that limitation. In this case we would create a virtual folder inside the plugin and the plugin would work more or less like a standard Pd (without externals still).
Well, lot of things left to do.
And then, a gem or pdp plugin on top of this would be cool, but thats another story :)
Guenter
saludos, sevy
guenter geiger wrote:
Hi,
Seems that you started the plugin as user root. This does not work (yet).
We didn't announce the plugin because its not finished, so please be patient. Its coming soon ... :)
Guenter
On Fri, 19 Nov 2004, Yves Degoyon wrote:
looks great, that's what we were expecting, i'm eager to test it.
ok, i understand it's brand new and i would like to use it soon, so i'm sending my bug report ( hay solo un bugito de camino o algo ).
the plugins appears in my plugins list. i use mozilla 1.7.3 on fedora core 3. but when i try to load an example, it fails with the following log :
################################### priority 98 scheduling enabled. memory locking enabled. sh: non/pd-watchdog: No such file or directory priority 96 scheduling enabled. memory locking enabled. pd: watchdog process died ####################################
we're close, keep on trying.
suerte, sevy
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
� wrote:
On Sat, 20 Nov 2004, Yves Degoyon wrote:
It can be delivered with externals. The question is which ones. I am open for suggestions, but it only makes sense to include those that are really necessary.
also, can we know which objects are already there?
Yes, we still have to write docs. There are actually several things that can not be done with the plugin, like reading from the filesystem etc.
This is a serious limitation and we are thinking of including some streaming objects instead.
but it is far more secure to not allow filesystem acess.
Another limitation is that you can only make one patch (no abstractions etc.). We thought about defining some sort of Pd-bundle format in order to get rid of that limitation. In this case we would create a virtual folder inside the plugin and the plugin would work more or less like a standard Pd (without externals still).
why not merge good ideas ? i think that the way the iARS-plugin handles this is quite ok: abstractions and needed externals are kept zipped on the server and are downloaded with the MAIN patch.
so you don't have to bundle pdp/Gem or whatever with the main plugin but with the application (patch)
mfg.ads.r IOhannes
Well, lot of things left to do.
And then, a gem or pdp plugin on top of this would be cool, but thats another story :)
but why ?
mfg.a.sdr IOhannes
On Mon, 22 Nov 2004, Johannes M Zmoelnig wrote:
Yes, we still have to write docs. There are actually several things that can not be done with the plugin, like reading from the filesystem etc.
This is a serious limitation and we are thinking of including some streaming objects instead.
but it is far more secure to not allow filesystem acess.
I meant streaming objects as in streaming from internet, they would not need file access.
Another limitation is that you can only make one patch (no abstractions etc.). We thought about defining some sort of Pd-bundle format in order to get rid of that limitation. In this case we would create a virtual folder inside the plugin and the plugin would work more or less like a standard Pd (without externals still).
why not merge good ideas ? i think that the way the iARS-plugin handles this is quite ok: abstractions and needed externals are kept zipped on the server and are downloaded with the MAIN patch.
so you don't have to bundle pdp/Gem or whatever with the main plugin but with the application (patch)
The zip file seems to be a good idea in order to be able to load several patches and subpatches.
I am not sure if this is a good idea for externals, though. We are planning to make the plugin secure in the future, if we would allow loading of uncontrolled externals and libraries, this would be impossible.
Guenter
mfg.ads.r IOhannes
Well, lot of things left to do.
And then, a gem or pdp plugin on top of this would be cool, but thats another story :)
but why ?
mfg.a.sdr IOhannes
� wrote:
On Mon, 22 Nov 2004, Johannes M Zmoelnig wrote:
Yes, we still have to write docs. There are actually several things that can not be done with the plugin, like reading from the filesystem etc.
This is a serious limitation and we are thinking of including some streaming objects instead.
but it is far more secure to not allow filesystem acess.
I meant streaming objects as in streaming from internet, they would not need file access.
yes, that's what i meant too. i just wanted to point out that it is good not to have local file access (as it already is)
The zip file seems to be a good idea in order to be able to load several patches and subpatches.
I am not sure if this is a good idea for externals, though. We are planning to make the plugin secure in the future, if we would allow loading of uncontrolled externals and libraries, this would be impossible.
true too. on the other hand it seems simpler to include externals too.
mfg.a.dr IOhannes
-
clemos -
derek holzer -
guenter geiger -
g�nter geiger
-
IOhannes m zmoelnig -
Johannes M Zmoelnig
-
Yves Degoyon