Re: [PD] general questions on externals
altern wrote: hi The uni i am collaborating with has an engineer that did a image analisys tool on C couple of years ago. Now they want to port parts of it to PD creating an external. The engineer that does the job is checking the documentation about externals but he was getting some error. He doesnt have internet at home, doesnt like it. And does not use email much, on top of this he does not speak english ... :( so this might end up like japanese whispers ... As far as I understood he was trying to do a hello world example and was able to compile but the PD was not able to create the object despite of being placed into a folder within the PD path. He is using Visual Studio to compile. He was checking Flext as well. He was confused and he was asking which is the best way to go about creating externals under windows. I think he is using Visual Studio to compile. the externals-howto (if he is referring to that) is pretty complete as far as it goes to writing externals. it does say nothing about compiling externals though. most likely this is the problem your engineer is experiencing. so here some tips: - they should have a look at the makefiles for the externals that come with Pd (pd/extra/makefile), it has a relevant esection for building with M$VC (but only using commandline tools) - alternatively, the examples of my externals-HOWTO are also checked into CVS (./doc/tutorials/externals-howto/), and there you will find Makefiles (still: using cmdline tools, also for M$VC) - if they insist on building only from within the IDE (no cmdline tools), they could also have a look at the M$VC project for zexy. (this is shameless self-advertising i admit; but it is the simplest M$VC project i know well); just use zexy.dsw / zexy.dsp (or whatever is there) and upgrade to their version of M$VC (the IDE should handle this automatically); then build from this project (rename the probject; remove all files from the project; add your own files) if they want to create the project on their own: - an external is a .dll (something you have to tell M$VC pretty early when you create a new project) - the external must link against pd.lib - an external MUST export one certain function (it MAY export more; but this one is obligatory): void externalname_setup(void) use - the external must reside in a file of its name:: [myobj] (pd objectclass) - myobj.dll (external-file) - myobj_setup() (entry point) mfgas.dr IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Thomas Grill wrote: There must be other externals using proxy inlets, probably zexy or other iem-based stuff. right: e.g. zexy's [mulitplex] (aka [mux]) uses proxy-inlets. there are 2 reasons why it is not in the externals-howto: #1 it would have complicated the howto needlessly #2 when i wrote the howto, i had no idea about proxy inlets and/or how to use them. having said that, i think it is usually a bad idea to all right-hand inlets accept arbitrary messages for _most_ objects (not for all). a message with a (nonstandard) selector selects a method of the object to be called and makes this explicit. e.g. it tells the object to do something (and eventually provides auxiliary data, to complete this task). if you are just passing around data to be collected by the object, there is already a certain type of message to do so: list. it is possible to create a right-hand list inlet using the methods described in the externals-howto (iirc :-)) while i basically agree with matju, that a consistent use of the data-flow paradigm should not be made the holy grail (if we don't want to end up fighting green knights), i do think that we should bear data-flow (as opposed to control-flow) in mind and design objects accordingly. mfg.adsf IOhannes ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] xml-rpc client
Hallo! Thanks I looked at that but it wasn't clear to me how I could connect to an external server such as http://xmlrpc-c.sourceforge.net/api.sample.php with this. Do I need to run a python script along with the patch? Is there a help file some where? Well, there is an help pach: look in /externals/iem/iemxmlrpc (I think not a help patch, but an example patch). And you should be able to use that with any other language than python ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Jamie Bullock wrote: Then I persuaded him that passing the queries as a list to the inlet would be more flexible. It also greatly reduces the number of objects required to send a query, if you have more than one query. I don't understand the latter part. How does it work? I'm talking about putting any number of queries together in a single object and passing the arguments of those queries all together in a list. How can you reduce the number of objects more than that? The way you are suggesting always requires at least 2 objects per query: an object to build the query and a message to send it. So if you have 5 different queries (I mean with different statements not just different data), then you would need at least 10 objects. This would be the case even if there was no variable data in the queries. Using the [psql] way of doing things, provided that the queries have no variable atoms, only 6 objects would be required, one for the database connection, and 5 containing the queries, which when passed to the connection object also trigger the sending. Your way takes at least two objects instead of one and it does not provide any protection against SQL injection because it can't distinguish between a symbol passed as a SQL argument and a symbol representing part of the statement syntax itself. True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Sun, 2007-12-09 at 16:47 -0500, Hans-Christoph Steiner wrote: The addcomma, addsemi, adddollar messages are a workaround, for sure, but yeah, I suppose a more pd-ish one. I think that if SQL gets submitted only on the right/cold inlet, then we would not need those messages. They might come in handy though, so they could be added later. I think we would still need 'addsemi' to act as a statement delimiter as you showed in the subpatch of your example. bang for submit sounds good too. As for clever hacks, I can't think of any with regexs too. Plus from my experience, clever hacks can often lead to really strange and difficult bugs. IMHO, we'd better off with something simple that might be a bit harder to start on, but doesn't have odd conditions that could trigger bugs. I agree. I don't much like the idea of maintaining a list of SQL statements for use in regex matches! Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] general questions on externals
On Mon, 2007-12-10 at 09:27 +0100, IOhannes m zmoelnig wrote: altern wrote: hi The uni i am collaborating with has an engineer that did a image analisys tool on C couple of years ago. Now they want to port parts of it to PD creating an external. The engineer that does the job is checking the documentation about externals but he was getting some error. He doesnt have internet at home, doesnt like it. And does not use email much, on top of this he does not speak english ... :( so this might end up like japanese whispers ... As far as I understood he was trying to do a hello world example and was able to compile but the PD was not able to create the object despite of being placed into a folder within the PD path. He is using Visual Studio to compile. He was checking Flext as well. He was confused and he was asking which is the best way to go about creating externals under windows. I think he is using Visual Studio to compile. the externals-howto (if he is referring to that) is pretty complete as far as it goes to writing externals. it does say nothing about compiling externals though. Last summmer, I wrote a small how-to about this, for people using Dev-C ++. Maybe that can help. It can be found on: http://youngmusic.org/wiki/index.php/PD-linking-tutorial There is also one about compiling a library of externals: http://youngmusic.org/wiki/index.php/PD-library-tutorial yvan vander sanden ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote: it's unfortunate that you are not thrilled using flext. Since flext uses the PD api to get lists or other messages into secondary inlets there's nothing to stop you from doing the same in psql. The magic words are proxy objects which you might find in the mailing list archive (or the flext source code, if you prefer that). Needless to say flext saves you from coding these things yourself in a time consuming manner and makes other things really easy, once you got it running. You could also compile pool then. The Python and Lua objects also support arbitrary messages on their inlets. Both languages have DB modules for just about every DB, compilation of these externals only has to be done only once. But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Frank Barknecht schrieb: But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Right. Over and out gr~~~ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] array indirection
Hi, I have tried to change graph-on-parents settings by message for displaying different arrays, it seems to work.. I did'nt test it with large tables. (included patch : switchingGOPtables.pd). Jean Yves Gratius http://jy.gratius.free.fr Chuckk Hubbard a crit : On Dec 9, 2007 10:50 PM, Phil Stone [EMAIL PROTECTED] wrote: Hi Chuck, I think you're right; there's no way to avoid the copying. It's good to dream, though. :-) I have done some experimenting, and I think I'm on to something. If you create a graph from the put menu, then right-click and select Open; and then Put an array on the opened subpatch, you can see the red outline where you can decide what will be graphed-on the parent graph. It would not be too hard to send editmode and mouse movement messages to that canvas to move arrays around inside it; and it probably would actually be more efficient than copying. But I also notice that the graph subpatch has, in its options, an x and y margin, which moves the red outline. IF it's possible to change these values with messages, it could be trivial to move that red outline to cover several well-placed arrays, meaning that the graph would indeed switch arrays like you want. I started to look at the Pd code to see if I can find such a message mentioned; if I find it I'll let you know. -Chuckk Chuckk Hubbard wrote: It would be possible, if not CPU-efficient, to have them all hidden in table objects, and simply use tabread and tabwrite to copy them to the skeleton array when you want to switch. You would only need one tabread and tabwrite pair, just different ways to specify the target of tabread. I would envision binding the tab key to page through them. But it is possible to put several arrays in one graph which makes me wonder if there might even be a pure GUI way to do it. Kind of makes me want to take a look... -Chuckk On Dec 8, 2007 10:26 PM, Phil Stone [EMAIL PROTECTED] wrote: This probably fits into the category of a wish for PD; I think there's no way to do it currently, but I'd love to be proven wrong! I'd like to be able to change the data an array points to rather than actually change the data in the array. The scenario which me think of this is, I'd like to have a display of a currently-selected waveform (which could be one of many pre-allocated arrays). It would be wonderful to have a level of indirection where the display-array can be given a new address [object reference?] to one of the various pre-allocated arrays, after which it redraws itself. I suppose this unleashes all the evils of pointers (multiple references to memory, etc.), but it would a serious advantage, performance-wise, for the scenario I'm envisioning. I also think it would be very cool if arrays could act as buttons...but that's a different subject. Phil Stone pkstonemusic.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 303 9 704 687 10; #N canvas 0 524 610 502 subpatch 0; #X obj 201 120 cnv 15 200 150 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 200 321 cnv 15 200 150 empty empty empty 20 12 0 14 -233017 -66577 0; #N canvas 0 0 450 300 graph4 0; #X array table2 100 float 1; #A 0 0 0 0 0.0714288 0.157143 0.171429 0.257144 0.314287 0.342858 0.42 0.457145 0.514288 0.557145 0.62 0.657145 0.73 0.714288 0.757146 0.757146 0.771431 0.785717 0.785717 0.785717 0.83 0.83 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.83 0.757146 0.614288 0.514287 0.414287 0.378573 0.342858 0.257144 0.21 -0.471431 -0.52 -0.62 -0.62 -0.62 -0.62 -0.62 -0.62 -0.585717 -0.571431 -0.557145 -0.542859 -0.514288 -0.52 -0.485716 -0.47143 -0.450002 -0.428573 -0.414287 -0.42 -0.392859 -0.385716 -0.357144 -0.328573 -0.285715 -0.21 0.114286 0.142858 0.228572 0.242858 0.27143 0.31 0.314287 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.31 0.257144 0.171429 0.142858 0.128572 0.114286 0.128572 0.171429 0.228572 0.242858 0.257144 0.257144 0 0 0; #X coords 0 1 99 -1 200 140 1; #X restore 200 330 graph; #N canvas 0 0 450 300 graph3 0; #X array table1 100 float 1; #A 0 0 0 0 0 0 0 0 0 0.0142856 0.0571424 0.071428 0.114285 0.157142 0.164284 0.171427 0.214284 0.271426 0.28 0.35714 0.37 0.442854 0.471425 0.46 0.528567 0.557138 0.557138 0.528567 0.46 0.478568
Re: [PD] [psql] object hand-holding
Mike McGonagle schrieb: On 12/9/07, *Thomas Grill* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Mike McGonagle schrieb: I know and it has been on my todo list for a long time. The point is that it hasn't made it to the top of this list since i don't need it. On the other hand it doesn't seem so important in general that any other person has cared to do it although i consider it a trivial task and i offered my support for any questions that might arise. Well, this is not something that is within reach of many people. We need to understand not just PD's internals, but how flext uses them, and we also need to know how to integrate these things with the extended nightly builds. Not quite certain how many people know ALL of these things. Probably only a handful, and it would appear that none of them are interested in getting flext working. It's not like that. It's certainly not a precondition to understand the inner workings of pd, flext or the operating system to compile an external. Integrating flext or anything else into the pd-extended build system, needs knowledge of the pd-extended build system and not much more. It's absolutely not necessary to understand flext to do this integration. I don't have sufficient knowledge of the pd-extended build system and i'm not going to spend time on dealing with it, but whoever is interested in the integration can dive into it, write the necessary make files (i could even provide skeletons for this) and stuff it into the build system in the usual free-style manner. I also downloaded the latest version of flext, and will try again to see if I can get this working. That being said, if we do go the route of using flext, then we should decide now if we should continue developing an SQL interface, or just use 'pool'. I would be very interested what exactly isn't working with flext for you. I just sshd into linux, checked out flext, pool and pd from cvs and compiled flext and pool without a single warning. I did exactly as described in the readme.txt files and it took about 2 minutes. I have heard it doesn't work many many times, but it's completely non-constructive to say that without saying why or what. gr~~~ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
Thanks for posting this Chris...it is quite a loss. 2007/12/10, Chris McCormick [EMAIL PROTECTED]: Hi, I haven't seen anyone post on the list about this, so I thought I'd mention it. http://www.nytimes.com/2007/12/08/arts/music/08stockhausen-1.html?_r=1ref=obituariesoref=slogin Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Eric Labelle [EMAIL PROTECTED] Disques Dubearth - www.dubearth.com F_actorvisuals - www.f-actorvisuals.net King Tubby's Heritage Dub Foundation ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
Sad news, This is worth reading and it ties into recent discussions on this list. http://www.music.princeton.edu/~ckk/smmt/scientific.commentary.2.html Of course he will always be remembered as an avant garde composer, but much of Stockhausens greatness is missed by artists who saw him as a pseudo-scientist and scientists who dismissed him as an artist. He was both at different times. A lack of rigor and precise voclabulary hides his contribution to psychoacoustics, he basically provided experimental support to Gabors theories, yet he is not mentioned once in critcal textbooks like McAdams and Bigand. On Mon, 10 Dec 2007 12:45:35 + eric labelle [EMAIL PROTECTED] wrote: Thanks for posting this Chris...it is quite a loss. 2007/12/10, Chris McCormick [EMAIL PROTECTED]: Hi, I haven't seen anyone post on the list about this, so I thought I'd mention it. http://www.nytimes.com/2007/12/08/arts/music/08stockhausen-1.html?_r=1ref=obituariesoref=slogin Best, Chris. --- http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Eric Labelle [EMAIL PROTECTED] Disques Dubearth - www.dubearth.com F_actorvisuals - www.f-actorvisuals.net King Tubby's Heritage Dub Foundation -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding (fwd)
On Dec 9, 2007, at 8:27 PM, Mathieu Bouchard wrote: -- Forwarded message -- Date: Sun, 9 Dec 2007 20:23:16 -0500 (EST) From: Mathieu Bouchard [EMAIL PROTECTED] To: Mike McGonagle [EMAIL PROTECTED] Subject: Re: [PD] [psql] object hand-holding On Sun, 9 Dec 2007, Mike McGonagle wrote: On 12/7/07, Mathieu Bouchard [EMAIL PROTECTED] wrote: [sql select * from candies where flavour=? and colour=?] I am actually considering going back to this idea, as I can't seem to figure out why my current version of [sqlite] is crashing. Try valgrind... best development tool of the decade, imho. Could you post some instructions on how to use valgrind to debug Pd related things on the dev docs wiki? It would be very useful: http://puredata.info/docs/developer .hc I wish there were some sort of tutorial on troubleshooting problems like this, mostly because I don't really know where to start with something like 'gdb'. Gdb is also useful, but often not, because it's too late: e.g. your [psql] might be corrupting pd or something used by pd, and thus pd might not be able to work properly anymore. This is why I thought of this in the first place. You generally don't modify the SQL, except to insert data. Yes. Now when it comes to modifying the command at runtime, i don't know what to do, because commas and semicolons are not evaled by objectboxes, whereas they are double-trouble in messageboxes. Yet I wouldn't enjoy the long-winded addcomma everytime a comma is used (most often INSERT but also SELECT that has a join). Currently backslashes are not typable in messageboxes but they would solve the problem in a less ugly way if they worked (as escape character). SQL injection is a big security issue, and it's hard to get it figure out all holes. This is especially why one must use SQL placeholders. The other main reason is so that one doesn't even have to think about strings. The other other main reason is because the DB can precompile a statement for multiple uses. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 9, 2007, at 9:41 PM, Mathieu Bouchard wrote: On Sat, 8 Dec 2007, Hans-Christoph Steiner wrote: I'm not a big fan of [expr]'s syntax since it is custom syntax that is not used anywhere else in Pd. A precedent has to start somewhere :) I believe that the goal is to make an interface that is effortless to use rather than try to be more dataflowish than the pope. The goal is not to pass more messages and use more objects and connections just to show off what's the concept of dataflow and how deeply pd follows it. The goal is still to make patches work with as little effort as possible. I also believe that there are plenty of pd classes that have at least one element of syntax that is not used anywhere else in pd. It also depends on how you look at pd: are two occurrences in two very related classes, counting as one occurrence, or as two? and why would it be counted that way? Too often reducing effort is equated with typing shortcuts and things along that line. I think putting everything into the [psql] object box is version of this. Things are a bigger concerns in the push to reduce effort are: - reducing bugs! - reducing time spent learning new objects - reducing time spent remembering how to use objects - making flexible programming easier rather than basic programming faster .hc Instead, you could achieve the same result by using the interface I described, then embedded your SQL statements with [sql] into a subpatch or an abstraction. This just about any regular Pd user knows how to do. But it's better to not have to do that. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote: Frank Barknecht schrieb: But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Right. Over and out Basically, only C and Pd externals have proven easy to manage. If you only care about your own machine, and people who like building things from source, that's one thing. But most people want to make new things rather than spend time building software. That's not to say that it is impossible to make the lua, python, etc. well supported. It is just a matter of someone doing the work, and committing to maintain it. So far, no one has. .hc ¡El pueblo unido jamás será vencido! ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] again, the pdcon in brazil issue
So guys, I will get back to you after the 18th, when we`ll have a meeting here, then I will have some stuff to say... I am about to move to Sao Paulo and maybe get into the doctorate at the State University of sao Paulo, which is interested in sediating and supporting the event. Any great questions or some expectations so far? cheers Alexandre Torres Porres [EMAIL PROTECTED] - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007 2:40 AM, IOhannes m zmoelnig [EMAIL PROTECTED] wrote: Thomas Grill wrote: There must be other externals using proxy inlets, probably zexy or other iem-based stuff. right: e.g. zexy's [mulitplex] (aka [mux]) uses proxy-inlets. there are 2 reasons why it is not in the externals-howto: #1 it would have complicated the howto needlessly #2 when i wrote the howto, i had no idea about proxy inlets and/or how to use them. Yeah, I kind of figured that was the case. having said that, i think it is usually a bad idea to all right-hand inlets accept arbitrary messages for _most_ objects (not for all). a message with a (nonstandard) selector selects a method of the object to be called and makes this explicit. e.g. it tells the object to do something (and eventually provides auxiliary data, to complete this task). if you are just passing around data to be collected by the object, there is already a certain type of message to do so: list. it is possible to create a right-hand list inlet using the methods described in the externals-howto (iirc :-)) Well, there are a couple of issues at hand. The first is making the text look as much like SQL as possible. And the other is in dealing with commas. Having to prepend each SQL statement with 'list', while not a big deal, isn't really required. So why use it? This is why we need it to be an arbitrary selector inlet. while i basically agree with matju, that a consistent use of the data-flow paradigm should not be made the holy grail (if we don't want to end up fighting green knights), i do think that we should bear data-flow (as opposed to control-flow) in mind and design objects accordingly. As we are still in discussion about this, I just want to see if we can get what Hans is suggesting implemented, and then we can see if it is more/less cumbersome than what we have already. Only way to find out is to do it... Mike -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 6:47 AM, Thomas Grill wrote: Mike McGonagle schrieb: On 12/9/07, *Thomas Grill* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Mike McGonagle schrieb: I know and it has been on my todo list for a long time. The point is that it hasn't made it to the top of this list since i don't need it. On the other hand it doesn't seem so important in general that any other person has cared to do it although i consider it a trivial task and i offered my support for any questions that might arise. Well, this is not something that is within reach of many people. We need to understand not just PD's internals, but how flext uses them, and we also need to know how to integrate these things with the extended nightly builds. Not quite certain how many people know ALL of these things. Probably only a handful, and it would appear that none of them are interested in getting flext working. It's not like that. It's certainly not a precondition to understand the inner workings of pd, flext or the operating system to compile an external. Integrating flext or anything else into the pd-extended build system, needs knowledge of the pd-extended build system and not much more. It's absolutely not necessary to understand flext to do this integration. I don't have sufficient knowledge of the pd-extended build system and i'm not going to spend time on dealing with it, but whoever is interested in the integration can dive into it, write the necessary make files (i could even provide skeletons for this) and stuff it into the build system in the usual free-style manner. If flext had a autoconf build system, it would be trivial to add, just like Gem, PDP, PiDiP, zexy, etc.. The issue now is a custom build system that is difficult to script to work automatically cross- platform. (or maybe it's not difficult, but it's custom so noone knows how). Basically all it would take to add an autoconf system to Pd-extended is changing the paths here: PDP_NAME=pdp $(externals_src)/pdp/configure: $(externals_src)/pdp/configure.ac cd $(externals_src)/pdp autoconf $(externals_src)/pdp/Makefile.config: $(externals_src)/pdp/ Makefile.config.in cd $(externals_src)/pdp ./configure PD_CPPFLAGS=-I$(pd_src)/src \ --enable-quicktime $(externals_src)/pdp/pdp.$(EXTENSION): $(externals_src)/pdp/configure \ $(externals_src)/pdp/Makefile.config $(MAKE) -C $(externals_src)/pdp PD_EXECUTABLE=$(pd_src)/bin/pd pdp: $(externals_src)/pdp/pdp.$(EXTENSION) pdp_install: pdp # install -d $(objectsdir)/$(PDP_NAME) # $(scripts_src)/generate-libdir-metafile.sh $(objectsdir) $(PDP_NAME) \ # --author Tom Schouten \ # --description Pure Data Packet \ # --license GNU GPL install -p $(externals_src)/pdp/*.$(EXTENSION) $(objectsdir) # install -p $(externals_src)/pdp/abstractions/*.pd $(objectsdir)/$ (PDP_NAME) install -p $(externals_src)/pdp/abstractions/*.pd $(objectsdir) # install -d $(helpdir)/$(PDP_NAME) install -p $(externals_src)/pdp/doc/objects/*.* $(helpdir) install -d $(manualsdir)/$(PDP_NAME) install -p $(externals_src)/pdp/doc/reference.txt $(manualsdir)/$ (PDP_NAME) install -p $(externals_src)/pdp/doc/introduction/*.* \ $(manualsdir)/$(PDP_NAME) install -d $(examplesdir)/$(PDP_NAME) install -p $(externals_src)/pdp/doc/examples/*.* \ $(examplesdir)/$(PDP_NAME) .hc I also downloaded the latest version of flext, and will try again to see if I can get this working. That being said, if we do go the route of using flext, then we should decide now if we should continue developing an SQL interface, or just use 'pool'. I would be very interested what exactly isn't working with flext for you. I just sshd into linux, checked out flext, pool and pd from cvs and compiled flext and pool without a single warning. I did exactly as described in the readme.txt files and it took about 2 minutes. I have heard it doesn't work many many times, but it's completely non-constructive to say that without saying why or what. gr~~~ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007 3:21 AM, Jamie Bullock [EMAIL PROTECTED] wrote: On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Jamie Bullock wrote: Then I persuaded him that passing the queries as a list to the inlet would be more flexible. It also greatly reduces the number of objects required to send a query, if you have more than one query. I don't understand the latter part. How does it work? I'm talking about putting any number of queries together in a single object and passing the arguments of those queries all together in a list. How can you reduce the number of objects more than that? The way you are suggesting always requires at least 2 objects per query: an object to build the query and a message to send it. So if you have 5 different queries (I mean with different statements not just different data), then you would need at least 10 objects. This would be the case even if there was no variable data in the queries. Using the [psql] way of doing things, provided that the queries have no variable atoms, only 6 objects would be required, one for the database connection, and 5 containing the queries, which when passed to the connection object also trigger the sending. Well, Jamie, at the same time, I think that Mathieu might be refering how the output is handled from the 'sql' external. That is the part that would make having just a single instance of a database object difficult at best to work with. From some of the early tests that I have done, I have pretty much always assumed that each instance would be outputing a different result set. If you only used one database object, you would have to figure out how to route all the result sets. Your way takes at least two objects instead of one and it does not provide any protection against SQL injection because it can't distinguish between a symbol passed as a SQL argument and a symbol representing part of the statement syntax itself. True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. Could someone please explain that IMPORTANCE of worrying about SQL injection? Just how would it effect users of PD? Mike Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Mike McGonagle wrote: Well, this is not something that is within reach of many people. We need to understand not just PD's internals, but how flext uses them, and we also need to know how to integrate these things with the extended nightly builds. Not quite certain how many people know ALL of these things. Probably only a handful, and it would appear that none of them are interested in getting flext working. GridFlow also uses proxy inlets. There are simpler examples of proxy inlets within pd itself. E.g. all [list] objects have it. Basically you need to create another object that will be the slave of your main object, and then create an inlet that will use that object. The second argument of inlet_new is for that: the inlet appears on the first argument's box, but messages will be sent to the second argument's object. In that case you pass 0,0 for the other arguments (which are usually symbols, but here are null pointers to mean not applicable) I started a pdpedia page on the topic, please add anything useful: http://wiki.puredata.info/en/proxy_objects .hc I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hans, I still have yet to learn about the WIKI stuff, but I posted a Inlet Proxy example on my page ( http://puredata.info/Members/mjmogo ). I don't know if you want to just put a link, or move the file to the Proxy page you created, either way works for me. Thanks, Mike On Dec 10, 2007 10:05 AM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Mike McGonagle wrote: Well, this is not something that is within reach of many people. We need to understand not just PD's internals, but how flext uses them, and we also need to know how to integrate these things with the extended nightly builds. Not quite certain how many people know ALL of these things. Probably only a handful, and it would appear that none of them are interested in getting flext working. GridFlow also uses proxy inlets. There are simpler examples of proxy inlets within pd itself. E.g. all [list] objects have it. Basically you need to create another object that will be the slave of your main object, and then create an inlet that will use that object. The second argument of inlet_new is for that: the inlet appears on the first argument's box, but messages will be sent to the second argument's object. In that case you pass 0,0 for the other arguments (which are usually symbols, but here are null pointers to mean not applicable) I started a pdpedia page on the topic, please add anything useful: http://wiki.puredata.info/en/proxy_objects .hc I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Inlet Proxy object example
Hello everyone, Over the weekend, I was given a huge lesson in both PD and humility... Anyway, what this is is an example of how to create an inlet proxy object to handle arbitrary list input on a cold right inlet. It is something that was extracted from the 'x_list.c' source, and generalized to be just a raw object. The example is not a useful object, but illustrates how the C source framework is designed. I posted the files to ( http://puredata.info/Members/mjmogo ). Feedback is welcome and expected... Mike -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote: Frank Barknecht schrieb: But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Right. Over and out Basically, only C and Pd externals have proven easy to manage. lua is a C external (or rather a loader) and it's very easy to manage. Once the lua loader is built for your system (trivial on Linux and probably just as trivial on OS-X and MS-Windows, but I don't have access to these systems) a lua objectclasses is the equivalent to an abstraction, which especially means, that it's just as easily changed and edited by its users without every needing to recompile anything. Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 4:21 AM, Jamie Bullock wrote: On Sun, 2007-12-09 at 21:47 -0500, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Jamie Bullock wrote: Then I persuaded him that passing the queries as a list to the inlet would be more flexible. It also greatly reduces the number of objects required to send a query, if you have more than one query. I don't understand the latter part. How does it work? I'm talking about putting any number of queries together in a single object and passing the arguments of those queries all together in a list. How can you reduce the number of objects more than that? The way you are suggesting always requires at least 2 objects per query: an object to build the query and a message to send it. So if you have 5 different queries (I mean with different statements not just different data), then you would need at least 10 objects. This would be the case even if there was no variable data in the queries. Using the [psql] way of doing things, provided that the queries have no variable atoms, only 6 objects would be required, one for the database connection, and 5 containing the queries, which when passed to the connection object also trigger the sending. Your way takes at least two objects instead of one and it does not provide any protection against SQL injection because it can't distinguish between a symbol passed as a SQL argument and a symbol representing part of the statement syntax itself. True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. For a place where you are expecting a number, you can protect against a SQL injection attack by merely putting a [float] before the message box with the SQL in it. In other situations, I think that Perl has a pretty decent idea: a SQL quote function. This could easily be a Pd object, [sqlquote], which would work with all of the SQL objects. This would probably be the easiest to implement. SQL Placeholders seem like a good idea, and SQL already has a defined, documented, and supported syntax for SQL placeholders. Ruby, Perl, Java, PHP and others use it, and I think we should use it too. Since we already have an inlet that is designed to accept only SQL. There seems to be two defined as part of SQL, ? for generic, and :name for named placeholders. - the ? could be supported by sending lists to the hot inlet. So if there were three ? in the SQL statement, then you'd send a [5 Joe 1239.2( to the hot inlet. - the names ones could be supported as selectors to the hot inlet: [insert into table (name,age) values (:name,:age) ( --- cold inlet [name Lila( --- hot inlet [age 12(--- hot inlet Then the SQL quoting would be handled internally to the Pd object. I added examples of this to the interface sketch, it's attached. This part could be safely implemented later, I think. sql-interface.pd Description: Binary data This way, the object represents the database itself, the object's arguments can represent the connection to the database, then different queries are represented using messages sent to the database object. That seems to mirror conceptually what's actually happening. Lastly, I know that this is getting more complicated to implement, but I think it'll pay off in the end. I'll happily help out with the implementation if either of you want me too. Also, once this is ironed out, I'd like to port the Max/MSP [mysql] object to whatever interface we come up with. .hc Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote: Frank Barknecht schrieb: But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Right. Over and out Basically, only C and Pd externals have proven easy to manage. lua is a C external (or rather a loader) and it's very easy to manage. Once the lua loader is built for your system (trivial on Linux and probably just as trivial on OS-X and MS-Windows, but I don't have access to these systems) a lua objectclasses is the equivalent to an abstraction, which especially means, that it's just as easily changed and edited by its users without every needing to recompile anything. Not quite as easy as abstractions - you still have to restart Pd. Howver, there is also a [luax] object, though, that loads the Lua code on each object creation rather than just once for all time, but you still have to recreate each object by hand if you change the script. Ciao Claude -- http://claudiusmaximus.goto10.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote: Too often reducing effort is equated with typing shortcuts and things along that line. I think putting everything into the [psql] object box is version of this. Things are a bigger concerns in the push to reduce effort are: - reducing bugs! - reducing time spent learning new objects - reducing time spent remembering how to use objects - making flexible programming easier rather than basic programming faster add this: - reducing risk of accidental SQL injection vulnerability - reducing risk of intentional SQL injection vulnerability - reducing to zero the effort required to protect against SQL injection vulnerability And if SQL injection vulnerabilities are assumed to have to be addressed in the first place, then your interface is increasing likelihood of bugs, increasing time spent learning how to use objects _correctly_, increasing how much there's to remember about how to get a SQL query right, and making flexible programming harder (compared to a version that would work the way I say except support replacing a placeholder-based query by another placeholder-based query in case anyone ever needs this) _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 10 Dec 2007, Jamie Bullock wrote: The way you are suggesting always requires at least 2 objects per query: an object to build the query and a message to send it. I assumed that there would always be one variable part per query, so that there's always a float or symbol or list coming from somewhere to trigger the query. Some queries take no arguments but in my experience they are rather exceptional. So in the usual case it takes 1 object per query, and if the statement is completely non-variable, it takes a bang coming from somewhere, which could be counted as a bang messagebox or not, depending on how you count. Using the [psql] way of doing things, provided that the queries have no variable atoms, This almost *never* happens. As long as what you do in Pd is regular read-write activities involving tables that contain data that you only want to see a small part of at a time, you need variable atoms in almost any query: select person from attendance where chatroom=? select chatroom from attendance where person=? select * from users where user=? select * from chatrooms where chatroom=? apps more likely to have invariable queries are apps that started small, stayed small, and will never be expanded. True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. checking the number of statements is not enough: what about a value like: (including quotes) 'or'1 put inside this statement: delete from users where username='$1' this query will delete the complete table. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Hallo, Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote: Not quite as easy as abstractions - you still have to restart Pd. Well, yes. But still the lua loader allows users to get the same power as developers have without the need to learn and setup all the stuff that's required to compile exernals. That's where the similarity between lua and abstractions is. And as Lua is *designed* as an embedded language, it can be shipped as a tiny binary without any dependencies easily. lua.pd_linux statically built with Lua included is 220 KB. Pd-extended is between 15 and 22 MB, zipped. What's easier to manage? But who am I telling this? ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] OT more pd muzik segmentation fault !!!
hi list ! more pd muzik drum n' drones nvisible.taz features segmentation fault programming and muzik noish~+daax! enjoy :P :: ..: ::: ::: :: :. ... . :: :: . : : :. : . . : . :: /*segmentation fault*/* *is a research xperimental audio-software project, based on the fusion of drones and percutive broken rythms, programmed in Pd-patches. /*sf*/ emerges from the work-in-progress in the 'nerd-core' underground of barcelona, in openlabs like 'hangar' or 'csoa la fibra'. Spontanously we mixed the patches in two xperimental-jam-sessions first at [EMAIL PROTECTED] http://hangar.org/nitcasm/ (centre Santa monica), and after at Distorsion Festival (La Fibra) http://delcorp.org/distorsionfest/?page_id=18 patching resources granular synthesis, asymetric sequencer, phasevocoder, physycalmodelling applied to AudioFX, Fibonacci sequencer, and lots of noise. The 3 tracks that you can download at: http://pitchvolley.com/nvisible.taz/segmentationfault.html are recorded and composed in live, letting flow the freequencies and feed'bugs',..all trakks are made under UbuntuStudio Gnu/linux, and licensed in cc. kontakkt isnotoursegmentationfault_at_gmail_dot_com http://pitchvolley.com/nvisible.taz/segmentationfault.html .::: : : :: : :: :: : . . .. : :: : : : :: : ... .. ___ 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] [psql] object hand-holding
On Mon, 10 Dec 2007, Mike McGonagle wrote: Could someone please explain that IMPORTANCE of worrying about SQL injection? Just how would it effect users of PD? We don't know what pd users will do with [psql]. Do you? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding (fwd)
-- Forwarded message -- Date: Mon, 10 Dec 2007 11:52:25 -0500 (EST) From: Mathieu Bouchard [EMAIL PROTECTED] To: Mike McGonagle [EMAIL PROTECTED] Subject: Re: [PD] [psql] object hand-holding On Mon, 10 Dec 2007, Mike McGonagle wrote: While I think I understand what you are getting at, I think that is something we should leave to version 2 of this. Basically, what I am understanding is that you want to be able to compile an SQL statement, and then insert new data by making another call that only sends the data. Is that right? Yes. Imho that should be version 1. Else it reminds me of working in web programming and thinking up funny titles for items in the web app, such as: '; drop database web; select * from whatever where 'dummy'=' Which inserts nicely into pretty much any simple query statement of a dumb enough web app. do you want any pd patches to be dumb enough? _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: This almost *never* happens. As long as what you do in Pd is regular read-write activities involving tables that contain data that you only want to see a small part of at a time, you need variable atoms in almost any query: select person from attendance where chatroom=? select chatroom from attendance where person=? select * from users where user=? select * from chatrooms where chatroom=? apps more likely to have invariable queries are apps that started small, stayed small, and will never be expanded. I take your point, but I think you are exaggerating slightly. I just looked at the code for a database driven web app I worked on recently. It uses 30 queries, 3 of which have no variables. Out of these three only one doesn't 'overlap' with other queries and therefore can't be refactored. Maybe 1 in 30 is almost never? Anyhow - I agree that I probably can't argue the case for the [psql]-style of operation on the grounds of reduced object count :-| True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. checking the number of statements is not enough: what about a value like: (including quotes) 'or'1 put inside this statement: delete from users where username='$1' this query will delete the complete table. Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On 12/10/07, Mathieu Bouchard [EMAIL PROTECTED] wrote: On Mon, 10 Dec 2007, Mike McGonagle wrote: Could someone please explain that IMPORTANCE of worrying about SQL injection? Just how would it effect users of PD? We don't know what pd users will do with [psql]. Do you? I guess what I am getting at is that I don't see how we can prevent people from using this maliciously. If they are creating the SQL and putting the data into it, how can we stop them from being idiots? Are you saying that we need to do data checking prior to the data being sent to the server? Or maybe I am not understanding what you are getting at... Mike _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Fwd: [psql] object hand-holding
-- Forwarded message -- From: Mike McGonagle [EMAIL PROTECTED] Date: Dec 10, 2007 1:07 PM Subject: Re: [PD] [psql] object hand-holding To: [EMAIL PROTECTED] On 12/10/07, Jamie Bullock [EMAIL PROTECTED] wrote: Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. One of the things that I have been reading on this is that when you use these 'pre-complied' SQL statements, you need to 'bind' each of the variables with their types to a specific function. (Also, I kind of like the ':' syntax, as it puts a name to the data within the statement.) I also think that we would need to do something like [insert into table (id, name) values (:id, :name) ( -- sent to the cold inlet [bind :id float( -- sent to hold inlet [bind :name symbol( -- sent to hold inlet [:id 1 ( -- sent to hold inlet [:name john ( -- sent to hold inlet [bang ( -- sent to hold inlet and then we would be able to put all the data into the database with the expected types. At least SQLite and libdbi use these 'bind' functions to associate the expected datatype with the input data. Mike Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 2007-12-10 at 09:55 -0600, Mike McGonagle wrote: Well, Jamie, at the same time, I think that Mathieu might be refering how the output is handled from the 'sql' external. That is the part that would make having just a single instance of a database object difficult at best to work with. From some of the early tests that I have done, I have pretty much always assumed that each instance would be outputing a different result set. If you only used one database object, you would have to figure out how to route all the result sets. Fair enough, I think I was probably stretching the point about using the [psql]-style of database connectivity requiring less objects. However, it's perfectly possible to have multiple [psql] instances connected to the same database, so the routing problem is a bit of a moot point. Could someone please explain that IMPORTANCE of worrying about SQL injection? Just how would it effect users of PD? It is certainly important in any situation where you would want to do variable substitution on queries using data sent to your Pd instance over a network. Some people might use Pd in this way via a web interface for example. Jamie -- www.postlude.co.uk ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On 12/10/07, Jamie Bullock [EMAIL PROTECTED] wrote:
PREPARE uses the '$' character as its placeholder identifier, and '$1'
Jamie, after thinking about this, I don't think we should worry about the
specifics of the characters that we use, as long as we can agree on what
gets entered into a PD message box, the specific instance of the external
('sqlite', 'psql', etc.) can handle the conversion to what the specific
database uses.
From what I have seen on this thread, is it right that the '?' syntax does
NOT have an identifier following it? I think it would be very helpful if we
use identifiers in the SQL if only to make the binding to the proper
datatypes easier, as per my last email.
Mike
--
Peace may sound simple—one beautiful word— but it requires everything we
have, every quality, every strength, every dream, every high ideal.
—Yehudi Menuhin (1916–1999), musician
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] array indirection
Well-done, that looks like the perfect solution. I did notice these functions mentioned in the code, with xmargin and ymargin as arguments of a longer function call, but I hadn't followed up to see what else went in the message. I believe this is your answer, Phil. Another one for msg-docs, I think. -Chuckk On Dec 10, 2007 1:11 PM, Jean-Yves GRATIUS [EMAIL PROTECTED] wrote: Hi, I have tried to change graph-on-parents settings by message for displaying different arrays, it seems to work.. I did'nt test it with large tables. (included patch : switchingGOPtables.pd). Jean Yves Gratius http://jy.gratius.free.fr Chuckk Hubbard a écrit : On Dec 9, 2007 10:50 PM, Phil Stone [EMAIL PROTECTED] wrote: Hi Chuck, I think you're right; there's no way to avoid the copying. It's good to dream, though. :-) I have done some experimenting, and I think I'm on to something. If you create a graph from the put menu, then right-click and select Open; and then Put an array on the opened subpatch, you can see the red outline where you can decide what will be graphed-on the parent graph. It would not be too hard to send editmode and mouse movement messages to that canvas to move arrays around inside it; and it probably would actually be more efficient than copying. But I also notice that the graph subpatch has, in its options, an x and y margin, which moves the red outline. IF it's possible to change these values with messages, it could be trivial to move that red outline to cover several well-placed arrays, meaning that the graph would indeed switch arrays like you want. I started to look at the Pd code to see if I can find such a message mentioned; if I find it I'll let you know. -Chuckk Chuckk Hubbard wrote: It would be possible, if not CPU-efficient, to have them all hidden in table objects, and simply use tabread and tabwrite to copy them to the skeleton array when you want to switch. You would only need one tabread and tabwrite pair, just different ways to specify the target of tabread. I would envision binding the tab key to page through them. But it is possible to put several arrays in one graph which makes me wonder if there might even be a pure GUI way to do it. Kind of makes me want to take a look... -Chuckk On Dec 8, 2007 10:26 PM, Phil Stone [EMAIL PROTECTED] wrote: This probably fits into the category of a wish for PD; I think there's no way to do it currently, but I'd love to be proven wrong! I'd like to be able to change the data an array points to rather than actually change the data in the array. The scenario which me think of this is, I'd like to have a display of a currently-selected waveform (which could be one of many pre-allocated arrays). It would be wonderful to have a level of indirection where the display-array can be given a new address [object reference?] to one of the various pre-allocated arrays, after which it redraws itself. I suppose this unleashes all the evils of pointers (multiple references to memory, etc.), but it would a serious advantage, performance-wise, for the scenario I'm envisioning. I also think it would be very cool if arrays could act as buttons...but that's a different subject. Phil Stone pkstonemusic.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 303 9 704 687 10; #N canvas 0 524 610 502 subpatch 0; #X obj 201 120 cnv 15 200 150 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 200 321 cnv 15 200 150 empty empty empty 20 12 0 14 -233017 -66577 0; #N canvas 0 0 450 300 graph4 0; #X array table2 100 float 1; #A 0 0 0 0 0.0714288 0.157143 0.171429 0.257144 0.314287 0.342858 0.42 0.457145 0.514288 0.557145 0.62 0.657145 0.73 0.714288 0.757146 0.757146 0.771431 0.785717 0.785717 0.785717 0.83 0.83 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.814289 0.83 0.757146 0.614288 0.514287 0.414287 0.378573 0.342858 0.257144 0.21 -0.471431 -0.52 -0.62 -0.62 -0.62 -0.62 -0.62 -0.62 -0.585717 -0.571431 -0.557145 -0.542859 -0.514288 -0.52 -0.485716 -0.47143 -0.450002 -0.428573 -0.414287 -0.42 -0.392859 -0.385716 -0.357144 -0.328573 -0.285715 -0.21 0.114286 0.142858 0.228572 0.242858 0.27143 0.31 0.314287 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.328573 0.31 0.257144 0.171429 0.142858 0.128572 0.114286 0.128572 0.171429 0.228572 0.242858 0.257144 0.257144 0 0 0; #X coords 0 1 99 -1 200 140 1; #X restore 200 330 graph; #N canvas 0 0 450 300 graph3 0; #X array table1 100 float 1; #A 0 0 0 0 0 0 0 0 0 0.0142856 0.0571424 0.071428 0.114285 0.157142 0.164284 0.171427 0.214284 0.271426 0.28 0.35714 0.37 0.442854 0.471425 0.46 0.528567 0.557138
Re: [PD] [psql] object hand-holding
On a different note, has anyone given any thought to handling Blobs? I know that in SQLite, they store the data as binary strings, but I am not quite certain how the external would handle the actual data going into and coming out of it. Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 10 Dec 2007, Mike McGonagle wrote: I guess what I am getting at is that I don't see how we can prevent people from using this maliciously. Using true placeholders or other form of automatic quoting. If they are creating the SQL and putting the data into it, how can we stop them from being idiots? If you have automatic quoting, you don't even have to think about who is an idiot and who isn't. I don't want to think about who's an idiot and who isn't. I don't want you to think about it. Are you saying that we need to do data checking prior to the data being sent to the server? If you quote your data properly then you don't need to check whether the data will garble the query's syntax or not. Therefore, no, I don't think what you need to do on the data is a check... though at the character level, you have to check in order to know which chars have to be replaced. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] symbolatom: why does it not allow to type spaces?
hi why does the symbolatom not allow the user to enter spaces? or in other words: why is there a restriction, if it can be circumvented by using [makefilename]? people do it anyway, so why prohibit it in the first place? roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
If you have applied the add string support patch you can use the blob atom, which is essentially a pointer to, and the length of, a binary string. The string can be anything at all. Martin Mike McGonagle wrote: To: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 13:29:16 -0600 On a different note, has anyone given any thought to handling Blobs? I know that in SQLite, they store the data as binary strings, but I am not quite certain how the external would handle the actual data going into and coming out of it. Mike ___ 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] [psql] object hand-holding
On Mon, 10 Dec 2007, Jamie Bullock wrote: On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: This almost *never* happens. I take your point, but I think you are exaggerating slightly. Not in this context. We're only looking at the average query; I don't even mean an actual query, but statistics about queries. If only 10% of them don't have arguments, then unless there's a huge difference in object count (which there is not), it doesn't make much of a difference on the total object count. And that is only supposing that you need something like an extra [bang] before your sql query to prevent [psql] from getting non-bang messages. I just looked at the code for a database driven web app I worked on recently. It uses 30 queries, 3 of which have no variables. Out of these three only one doesn't 'overlap' with other queries and therefore can't be refactored. Maybe 1 in 30 is almost never? Yes. to contrast this, 3% wouldn't be almost never if, for example, the issue was whether to support something at all, or not. In that case, if the cost of a workaround is 50x the wanted feature, or if a workaround is impossible, it can weigh a lot in the design priorities. Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. The '?' notation is either MySQL-specific or PerlDBI-specific or both. By PerlDBI I mean any database interface (in any language) following's Perl DBI package closely enough. I guess that if you use DBI-over-Postgres, then it replaces all ? by $ automatically. $ alone can be used in pd as long as it is not followed by a digit, but I wouldn't encourage that, if it's not used in a [expr] way, because the use of '$' alone would prevent you from later supporting an [expr] syntax in a way compatible with yourself. Using $f1 or $s1 in [expr] style, or perhaps $e1 to mean any atom (e stands for element), would be useful, though less required than the placeholder feature itself. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 10 Dec 2007, Jamie Bullock wrote: Fair enough, I think I was probably stretching the point about using the [psql]-style of database connectivity requiring less objects. However, it's perfectly possible to have multiple [psql] instances connected to the same database, so the routing problem is a bit of a moot point. But it requires multiple logins, perhaps many at once, which might be wasteful. For sharing database connections between several [psql] objects, what do you think would be the best ways to do it? This is supposing that several different database connections can still be used at once, as specified in the patches. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 11:43 AM, Frank Barknecht wrote: Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: On Dec 10, 2007, at 6:14 AM, Thomas Grill wrote: Frank Barknecht schrieb: But as everyone knows that I don't really understand why a DB external has to be a C/C++ external, I'll better be quiet now. ;) Right. Over and out Basically, only C and Pd externals have proven easy to manage. lua is a C external (or rather a loader) and it's very easy to manage. Once the lua loader is built for your system (trivial on Linux and probably just as trivial on OS-X and MS-Windows, but I don't have access to these systems) a lua objectclasses is the equivalent to an abstraction, which especially means, that it's just as easily changed and edited by its users without every needing to recompile anything. From what I hear from Marius' struggles with pdlua, it's definitely not trivial, and I would say, I probably wouldn't call it easy either. I intend to help Marius get pdlua into Pd-extended, then it'll be easy and hopefully even trivial to use. .hc Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you. - Richard M. Stallman ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
On Mon, 10 Dec 2007, Roman Haefeli wrote: why does the symbolatom not allow the user to enter spaces? or in other words: why is there a restriction, if it can be circumvented by using [makefilename]? people do it anyway, so why prohibit it in the first place? I don't know. In DesireData, if I connect a symbolbox to a [print], and type something, I get something like this in the console: print: symbol real\ people\ want\ to\ use\ spaces! _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Is this something that is part of PD Vanilla? I would like to be able to have this external running there. Thanks, Mike On 12/10/07, Martin Peach [EMAIL PROTECTED] wrote: If you have applied the add string support patch you can use the blob atom, which is essentially a pointer to, and the length of, a binary string. The string can be anything at all. Martin Mike McGonagle wrote: To: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 13:29:16 -0600 On a different note, has anyone given any thought to handling Blobs? I know that in SQLite, they store the data as binary strings, but I am not quite certain how the external would handle the actual data going into and coming out of it. Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote: print: symbol real\ people\ want\ to\ use\ spaces! definitely. the first question i hear from people using netpd/pd the first time is: 'how can i type spaces?' yet i decided to not add another dependency for netpd just because of this rather silly restriction. but since it seems, that the lack of spaces is really troubling users, i am unsure, whether i should change that policy. since one can even open a file containing spaces in the path from pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?). before i change my policy about using externals in netpd, i would like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [psql] object hand-holding
On Dec 10, 2007, at 2:07 PM, Mike McGonagle wrote: -- Forwarded message -- From: Mike McGonagle [EMAIL PROTECTED] Date: Dec 10, 2007 1:07 PM Subject: Re: [PD] [psql] object hand-holding To: [EMAIL PROTECTED] On 12/10/07, Jamie Bullock [EMAIL PROTECTED] wrote: Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. One of the things that I have been reading on this is that when you use these 'pre-complied' SQL statements, you need to 'bind' each of the variables with their types to a specific function. (Also, I kind of like the ':' syntax, as it puts a name to the data within the statement.) I also think that we would need to do something like [insert into table (id, name) values (:id, :name) ( -- sent to the cold inlet [bind :id float( -- sent to hold inlet [bind :name symbol( -- sent to hold inlet [:id 1 ( -- sent to hold inlet [:name john ( -- sent to hold inlet [bang ( -- sent to hold inlet and then we would be able to put all the data into the database with the expected types. At least SQLite and libdbi use these 'bind' functions to associate the expected datatype with the input data. (What is the hold inlet, by the way?) It would be really nice to be able to have inlets for the sql placeholders, but I couldn't think of a clean way to do it. We could try the dynamic allocation like you say here, I don't know if I have a specific objection to it, but it could get weird. Since the SQL inlet has to be cold to support the comma hack, then these dynamic inlets shouldn't be hot since they are the right of a cold inlet. But that's not a big deal. Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. I figure that you can easily make a subpatch or abstraction around the SQL message generation, then manage the inlets there. Perhaps not ideal, but it's not difficult to do and follows existing practice. As for the SQL binding, I was thinking it would happen inside of the object, binding the placeholder names to the selectors. As long as there wasn't any new input on the SQL inlet, then the SQL statement wouldn't need to be recompiled. Another question I just thought of it how to handle returning multiple results from s single query. If it followed the [textfile] style, then you would have to bang to get each individual result, then keep banging until you get a bang on the status/second outlet, meaning the query was done. I think this could work. .hc There is no way to peace, peace is the way. -A.J. Muste ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On 12/10/07, Mathieu Bouchard [EMAIL PROTECTED] wrote: But it requires multiple logins, perhaps many at once, which might be wasteful. For sharing database connections between several [psql] objects, what do you think would be the best ways to do it? This is supposing that several different database connections can still be used at once, as specified in the patches. In one of the early prototypes I wrote for this, I set it up so that the connections were shared. Basically, when an object tried to open a connection, it would check if there was already one open, and if so, it would use that. Else it would create a new connection, which would then get stored in the global connection object. One thing that I would be curious about would be any collisions in using a shared object, but I also think that should be something left to think about in building the PD patch. Mike _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
Very nice, thanks for making the example, I linked to it from the wiki page. .hc On Dec 10, 2007, at 11:30 AM, Mike McGonagle wrote: Hans, I still have yet to learn about the WIKI stuff, but I posted a Inlet Proxy example on my page ( http://puredata.info/Members/ mjmogo ). I don't know if you want to just put a link, or move the file to the Proxy page you created, either way works for me. Thanks, Mike On Dec 10, 2007 10:05 AM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: On Dec 9, 2007, at 9:53 PM, Mathieu Bouchard wrote: On Sun, 9 Dec 2007, Mike McGonagle wrote: Well, this is not something that is within reach of many people. We need to understand not just PD's internals, but how flext uses them, and we also need to know how to integrate these things with the extended nightly builds. Not quite certain how many people know ALL of these things. Probably only a handful, and it would appear that none of them are interested in getting flext working. GridFlow also uses proxy inlets. There are simpler examples of proxy inlets within pd itself. E.g. all [list] objects have it. Basically you need to create another object that will be the slave of your main object, and then create an inlet that will use that object. The second argument of inlet_new is for that: the inlet appears on the first argument's box, but messages will be sent to the second argument's object. In that case you pass 0,0 for the other arguments (which are usually symbols, but here are null pointers to mean not applicable) I started a pdpedia page on the topic, please add anything useful: http://wiki.puredata.info/en/proxy_objects .hc -- -- I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [psql] object hand-holding
On 12/10/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: (What is the hold inlet, by the way?) It's a hot inlet that has been misspelled... It would be really nice to be able to have inlets for the sql placeholders, but I couldn't think of a clean way to do it. We could try the dynamic allocation like you say here, I don't know if I have a specific objection to it, but it could get weird. Since the SQL inlet has to be cold to support the comma hack, then these dynamic inlets shouldn't be hot since they are the right of a cold inlet. But that's not a big deal. And if you want placeholders to have inlets, then we are back to putting the SQL into the object creation arguments, like: [sqlite insert into table (id, name) values (:id, :name)] While I don't think it is a bad idea, it does restrict a particular instance of a database object to only a single type of message, and it would have to be done at creation time of the object. Should we allow both methods of entering SQL? One done at creation time, the other one done on the fly? Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. I figure that you can easily make a subpatch or abstraction around the SQL message generation, then manage the inlets there. Perhaps not ideal, but it's not difficult to do and follows existing practice. I would think that an object having the ability to change its inlets on the fly would NOT be possible, as the inlets may change so much, as to lose a connection when it is recreated. OR, could we possibly do something like this [sqlite :id(f) :name(s)] Which would create an instance with 4 inlets, the first 'hot' inlet would accept all the control messages, the next (x number) would represent the bound inlets for the placeholders, and the last would be the inlet for the incoming SQL statement. Would it be an error if the incoming SQL statement didn't have the same placeholders defined in it? Or should it be allowed to operate as any other? As for the SQL binding, I was thinking it would happen inside of the object, binding the placeholder names to the selectors. As long as there wasn't any new input on the SQL inlet, then the SQL statement wouldn't need to be recompiled. My thought too... Another question I just thought of it how to handle returning multiple results from s single query. If it followed the [textfile] style, then you would have to bang to get each individual result, then keep banging until you get a bang on the status/second outlet, meaning the query was done. I think this could work. This is already what I have been doing. Basically, as we are working now, the SQL would get input on the right inlet, then if any binding were needed, that would be done, and when the next bang occurs, the query is submitted, and the first result set is returned. Any subsequent bang would return the next result set. And when the result sets have been exhausted, it would send a bang out the status outlet to indicate the sets are done. Mike .hc There is no way to peace, peace is the way. -A.J. Muste -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [psql] object hand-holding
On 12/10/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: (What is the hold inlet, by the way?) It's a hot inlet that has been misspelled... It would be really nice to be able to have inlets for the sql placeholders, but I couldn't think of a clean way to do it. We could try the dynamic allocation like you say here, I don't know if I have a specific objection to it, but it could get weird. Since the SQL inlet has to be cold to support the comma hack, then these dynamic inlets shouldn't be hot since they are the right of a cold inlet. But that's not a big deal. And if you want placeholders to have inlets, then we are back to putting the SQL into the object creation arguments, like: [sqlite insert into table (id, name) values (:id, :name)] While I don't think it is a bad idea, it does restrict a particular instance of a database object to only a single type of message, and it would have to be done at creation time of the object. Should we allow both methods of entering SQL? One done at creation time, the other one done on the fly? Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. I figure that you can easily make a subpatch or abstraction around the SQL message generation, then manage the inlets there. Perhaps not ideal, but it's not difficult to do and follows existing practice. I would think that an object having the ability to change its inlets on the fly would NOT be possible, as the inlets may change so much, as to lose a connection when it is recreated. OR, could we possibly do something like this [sqlite :id(f) :name(s)] Which would create an instance with 4 inlets, the first 'hot' inlet would accept all the control messages, the next (x number) would represent the bound inlets for the placeholders, and the last would be the inlet for the incoming SQL statement. Would it be an error if the incoming SQL statement didn't have the same placeholders defined in it? Or should it be allowed to operate as any other? As for the SQL binding, I was thinking it would happen inside of the object, binding the placeholder names to the selectors. As long as there wasn't any new input on the SQL inlet, then the SQL statement wouldn't need to be recompiled. My thought too... Another question I just thought of it how to handle returning multiple results from s single query. If it followed the [textfile] style, then you would have to bang to get each individual result, then keep banging until you get a bang on the status/second outlet, meaning the query was done. I think this could work. This is already what I have been doing. Basically, as we are working now, the SQL would get input on the right inlet, then if any binding were needed, that would be done, and when the next bang occurs, the query is submitted, and the first result set is returned. Any subsequent bang would return the next result set. And when the result sets have been exhausted, it would send a bang out the status outlet to indicate the sets are done. Mike .hc There is no way to peace, peace is the way. -A.J. Muste -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 1:43 PM, Mike McGonagle wrote: On 12/10/07, Mathieu Bouchard [EMAIL PROTECTED] wrote: On Mon, 10 Dec 2007, Mike McGonagle wrote: Could someone please explain that IMPORTANCE of worrying about SQL injection? Just how would it effect users of PD? We don't know what pd users will do with [psql]. Do you? I guess what I am getting at is that I don't see how we can prevent people from using this maliciously. If they are creating the SQL and putting the data into it, how can we stop them from being idiots? Are you saying that we need to do data checking prior to the data being sent to the server? Or maybe I am not understanding what you are getting at... Using the placeholder stuff will stop SQL injection attacks. The interfaces we've discussed shouldn't make a difference in terms of security as long as the placeholder stuff is properly implemented. .hc Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 1:42 PM, Jamie Bullock wrote: On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: This almost *never* happens. As long as what you do in Pd is regular read-write activities involving tables that contain data that you only want to see a small part of at a time, you need variable atoms in almost any query: select person from attendance where chatroom=? select chatroom from attendance where person=? select * from users where user=? select * from chatrooms where chatroom=? apps more likely to have invariable queries are apps that started small, stayed small, and will never be expanded. I take your point, but I think you are exaggerating slightly. I just looked at the code for a database driven web app I worked on recently. It uses 30 queries, 3 of which have no variables. Out of these three only one doesn't 'overlap' with other queries and therefore can't be refactored. Maybe 1 in 30 is almost never? Anyhow - I agree that I probably can't argue the case for the [psql]-style of operation on the grounds of reduced object count :-| True, this is a good argument for the [expr]-style SQL object. Although there may be other ways to provide some protection against injection like allowing the user to lock the number of statements in the query. checking the number of statements is not enough: what about a value like: (including quotes) 'or'1 put inside this statement: delete from users where username='$1' this query will delete the complete table. Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. So PostgreSQL doesn't support placeholders in normal SQL queries? That's a bummer. It seems that those languages that I sited chose the Oracle standard for placeholders (? and :name). According to this, MySQL uses ?name and MS SQL Server uses @name. MySQL can use @name if $old_syntax is turned on. MySQL should use plain ? but I don't know about MS SQL Server (who's really going to use that with Pd anyway ;) http://forums.mysql.com/read.php?38,122041,122187#msg-122187 So the syntax seems to be less standard than I thought. Man, SQL is a mess. .hc [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
On Mon, 10 Dec 2007, Roman Haefeli wrote: since one can even open a file containing spaces in the path from pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?). It would only break externals that rely on lack of spaces in any way, and only if supposing that you weren't already using some other way of producing the spaces. about spaces, those that break are: [netsend], [print], [textfile], ... anything using atom_string(). _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Mon, 10 Dec 2007, Mike McGonagle wrote: In one of the early prototypes I wrote for this, I set it up so that the connections were shared. Basically, when an object tried to open a connection, it would check if there was already one open, and if so, it would use that. Else it would create a new connection, which would then get stored in the global connection object. I think that the first argument of [psql] could be a receive-symbol, followed by the query itself. Then [psql] would not use the receive-symbol to send messages to, it would look at the receiver directly, checking that it's a [psql.connection] object, and then calling a function of that object directly, and get called back when a response is received. This is quite close to how [tabread] works except it inserts a [delay] before the result. It's how [tabread] would work if it were trying to access an array on another computer. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] array indirection
A glorious hack, Jean-Yves! This should work well for what I am envisioning. One strange thing, though: if you move the subpatch (that displays the selected array), the other array is visible underneath it. I wonder what's up with that? Thanks for the solution, Jean-Yves (and Chuck for suggesting it was possible in the first place). Phil Chuckk Hubbard wrote: Well-done, that looks like the perfect solution. I did notice these functions mentioned in the code, with xmargin and ymargin as arguments of a longer function call, but I hadn't followed up to see what else went in the message. I believe this is your answer, Phil. Another one for msg-docs, I think. -Chuckk On Dec 10, 2007 1:11 PM, Jean-Yves GRATIUS [EMAIL PROTECTED] wrote: Hi, I have tried to change graph-on-parents settings by message for displaying different arrays, it seems to work.. I did'nt test it with large tables. (included patch : switchingGOPtables.pd). Jean Yves Gratius http://jy.gratius.free.fr Chuckk Hubbard a écrit : On Dec 9, 2007 10:50 PM, Phil Stone [EMAIL PROTECTED] wrote: Hi Chuck, I think you're right; there's no way to avoid the copying. It's good to dream, though. :-) I have done some experimenting, and I think I'm on to something. If you create a graph from the put menu, then right-click and select Open; and then Put an array on the opened subpatch, you can see the red outline where you can decide what will be graphed-on the parent graph. It would not be too hard to send editmode and mouse movement messages to that canvas to move arrays around inside it; and it probably would actually be more efficient than copying. But I also notice that the graph subpatch has, in its options, an x and y margin, which moves the red outline. IF it's possible to change these values with messages, it could be trivial to move that red outline to cover several well-placed arrays, meaning that the graph would indeed switch arrays like you want. I started to look at the Pd code to see if I can find such a message mentioned; if I find it I'll let you know. -Chuckk Chuckk Hubbard wrote: It would be possible, if not CPU-efficient, to have them all hidden in table objects, and simply use tabread and tabwrite to copy them to the skeleton array when you want to switch. You would only need one tabread and tabwrite pair, just different ways to specify the target of tabread. I would envision binding the tab key to page through them. But it is possible to put several arrays in one graph which makes me wonder if there might even be a pure GUI way to do it. Kind of makes me want to take a look... -Chuckk On Dec 8, 2007 10:26 PM, Phil Stone [EMAIL PROTECTED] wrote: This probably fits into the category of a wish for PD; I think there's no way to do it currently, but I'd love to be proven wrong! I'd like to be able to change the data an array points to rather than actually change the data in the array. The scenario which me think of this is, I'd like to have a display of a currently-selected waveform (which could be one of many pre-allocated arrays). It would be wonderful to have a level of indirection where the display-array can be given a new address [object reference?] to one of the various pre-allocated arrays, after which it redraws itself. I suppose this unleashes all the evils of pointers (multiple references to memory, etc.), but it would a serious advantage, performance-wise, for the scenario I'm envisioning. I also think it would be very cool if arrays could act as buttons...but that's a different subject. Phil Stone pkstonemusic.com ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [psql] object hand-holding
On Mon, 10 Dec 2007, Hans-Christoph Steiner wrote: Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. It's possible, and I've done it, except for the bit of disconnecting every wire connecting to deleted inlets. I think that it's just 2 more lines of code, but I haven't tried, especially as we don't have any use for it anymore, as we are replacing LtiLib support by OpenCV support, which doesn't need that trick. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
Andy Farnell wrote: Of course he will always be remembered as an avant garde composer, but much of Stockhausens greatness is missed by artists who saw him as a pseudo-scientist and scientists who dismissed him as an artist. He was both at different times. A lack of rigor and precise voclabulary hides his contribution to psychoacoustics, he basically provided experimental support to Gabors theories, yet he is not mentioned once in critcal textbooks like McAdams and Bigand. And of coruse we must not forget he came from sirius to explain us all that :-) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
On Dec 10, 2007, at 3:25 PM, Roman Haefeli wrote: On Mon, 2007-12-10 at 15:03 -0500, Mathieu Bouchard wrote: print: symbol real\ people\ want\ to\ use\ spaces! definitely. the first question i hear from people using netpd/pd the first time is: 'how can i type spaces?' yet i decided to not add another dependency for netpd just because of this rather silly restriction. but since it seems, that the lack of spaces is really troubling users, i am unsure, whether i should change that policy. I think it would be awesome to have a real IRC or Jabber client in Pd and use it in netpd. That's why I am writing the tkwidgets library, so that we can have nice, familiar, OS-native widgets in Pd. netpd's chat would be a great test case for the new [entry], which isn't written yet, but wouldn't take long. You could try [tkwidgets/text] it works pretty well now, and is quite customizable (there is still a couple bugs tho). .hc since one can even open a file containing spaces in the path from pd, it would actually make sense, if symbolatom would support that. i can't think of a case, where supporting spaces would break anything (or am i overseeing something?). before i change my policy about using externals in netpd, i would like to ask (probably miller?), if there is a chance, that symbolatom is changed accordingly in the future? roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
It probably would end up in vanilla if there was a demand for it, although Miller doesn't seem to like the idea, needs more convincing ;) Martin Mike McGonagle wrote: To: Martin Peach [EMAIL PROTECTED] CC: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 14:17:20 -0600 Is this something that is part of PD Vanilla? I would like to be able to have this external running there. Thanks, Mike On 12/10/07, Martin Peach [EMAIL PROTECTED] wrote: If you have applied the add string support patch you can use the blob atom, which is essentially a pointer to, and the length of, a binary string. The string can be anything at all. Martin Mike McGonagle wrote: To: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 13:29:16 -0600 On a different note, has anyone given any thought to handling Blobs? I know that in SQLite, they store the data as binary strings, but I am not quite certain how the external would handle the actual data going into and coming out of it. Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simpleone beautiful word but it requires everything we have, every quality, every strength, every dream, every high ideal. Yehudi Menuhin (19161999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 3:30 PM, Mike McGonagle wrote: On 12/10/07, Mathieu Bouchard [EMAIL PROTECTED] wrote: But it requires multiple logins, perhaps many at once, which might be wasteful. For sharing database connections between several [psql] objects, what do you think would be the best ways to do it? This is supposing that several different database connections can still be used at once, as specified in the patches. In one of the early prototypes I wrote for this, I set it up so that the connections were shared. Basically, when an object tried to open a connection, it would check if there was already one open, and if so, it would use that. Else it would create a new connection, which would then get stored in the global connection object. One thing that I would be curious about would be any collisions in using a shared object, but I also think that should be something left to think about in building the PD patch. It is useful to represent the pieces in Pd space, so you can understand what's going on. That's one reason why I advocate having the core object represent the connection to the database rather than a query. Otherwise, it's starts to become more like Max/MSP's mega- objects (coll, zl, etc) that are really like mini-applications than programming. There still can be query objects, they would just be designed to feed to the core database objects. These query objects would then be usable if we maintain the same interface. .hc News is what people want to keep hidden and everything else is publicity. - Bill Moyers ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
On Dec 10, 2007, at 2:55 PM, Mathieu Bouchard wrote: On Mon, 10 Dec 2007, Jamie Bullock wrote: On Mon, 2007-12-10 at 12:18 -0500, Mathieu Bouchard wrote: This almost *never* happens. I take your point, but I think you are exaggerating slightly. Not in this context. We're only looking at the average query; I don't even mean an actual query, but statistics about queries. If only 10% of them don't have arguments, then unless there's a huge difference in object count (which there is not), it doesn't make much of a difference on the total object count. And that is only supposing that you need something like an extra [bang] before your sql query to prevent [psql] from getting non-bang messages. I just looked at the code for a database driven web app I worked on recently. It uses 30 queries, 3 of which have no variables. Out of these three only one doesn't 'overlap' with other queries and therefore can't be refactored. Maybe 1 in 30 is almost never? Yes. to contrast this, 3% wouldn't be almost never if, for example, the issue was whether to support something at all, or not. In that case, if the cost of a workaround is 50x the wanted feature, or if a workaround is impossible, it can weigh a lot in the design priorities. Good point! I think Hans' recent suggestion addresses the problem. It also occurs to me that for Postgres at least, we have the PREPARE statement, which addresses the optimisation and injection issues you have raised. Technically [psql] already supports PREPARE except that PREPARE uses the '$' character as its placeholder identifier, and '$1' can't be passed around as a symbol in Pd. I think it might be interesting to use the '?' notation currently under discussion as an interface to PREPARE though. The '?' notation is either MySQL-specific or PerlDBI-specific or both. By PerlDBI I mean any database interface (in any language) following's Perl DBI package closely enough. I guess that if you use DBI-over-Postgres, then it replaces all ? by $ automatically. The other somewhat common style that I saw in my searches was printf patterns (%s, %f, etc). In Pd, [makefilename], [makesymbol], [sprintf], and perhaps others use this syntax. The single ? notation seems to be supported by at least these, if you want to call that specific: Qt, PerlDBI, Perl's DBD::Pg, RubyDBI, PHP PDO, Java JDBC, MySQL, Oracle. I think it is quite important to reuse existing syntax rather than introducing new syntax. Minimal syntax is really one of Pd's biggest strengths. Since these lines would be pure SQL, I think it would be appropriate to use a common SQL syntax. I just had a thought, SQL injection relies on being able to send semi- colons in text fields. You can't transmit a semicolon in a message in Pd, and if you don't provide a means to explicitly send a semi- colon to the query (e.g. [addsemi( to the hot inlet), then no one will ever be able to send a semi-colon to [sqlite]/[psql]. Pd would always interpret the semi-colon before the object received it on its cold inlet. AFAIK, that eliminates basically all of the really bad SQL injection attacks. .hc $ alone can be used in pd as long as it is not followed by a digit, but I wouldn't encourage that, if it's not used in a [expr] way, because the use of '$' alone would prevent you from later supporting an [expr] syntax in a way compatible with yourself. Using $f1 or $s1 in [expr] style, or perhaps $e1 to mean any atom (e stands for element), would be useful, though less required than the placeholder feature itself. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list http://at.or.at/hans/ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
On Mon, 10 Dec 2007 22:41:32 +0100 Yvan Vander Sanden [EMAIL PROTECTED] wrote: And of coruse we must not forget he came from sirius to explain us all that :-) No way? A or B? I can't stand those wankers from Sirius B with their our star's brighter than yours crap. Or was he a scientologist, where do they come from again? ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: [psql] object hand-holding
On Dec 10, 2007, at 3:57 PM, Mike McGonagle wrote: On 12/10/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: (What is the hold inlet, by the way?) It's a hot inlet that has been misspelled... It would be really nice to be able to have inlets for the sql placeholders, but I couldn't think of a clean way to do it. We could try the dynamic allocation like you say here, I don't know if I have a specific objection to it, but it could get weird. Since the SQL inlet has to be cold to support the comma hack, then these dynamic inlets shouldn't be hot since they are the right of a cold inlet. But that's not a big deal. And if you want placeholders to have inlets, then we are back to putting the SQL into the object creation arguments, like: [sqlite insert into table (id, name) values (:id, :name)] While I don't think it is a bad idea, it does restrict a particular instance of a database object to only a single type of message, and it would have to be done at creation time of the object. Should we allow both methods of entering SQL? One done at creation time, the other one done on the fly? Also, I don't know if any objects do this kind of dynamic inlet creation after the object itself has been instantiated. It might not even be possible. I figure that you can easily make a subpatch or abstraction around the SQL message generation, then manage the inlets there. Perhaps not ideal, but it's not difficult to do and follows existing practice. I would think that an object having the ability to change its inlets on the fly would NOT be possible, as the inlets may change so much, as to lose a connection when it is recreated. OR, could we possibly do something like this [sqlite :id(f) :name(s)] Which would create an instance with 4 inlets, the first 'hot' inlet would accept all the control messages, the next (x number) would represent the bound inlets for the placeholders, and the last would be the inlet for the incoming SQL statement. Would it be an error if the incoming SQL statement didn't have the same placeholders defined in it? Or should it be allowed to operate as any other? This kind of thing could be done in a separate query object, like what's included in the sqlwrappers, and [sqlite]/[psql] would still represent the database itself. Having the objects structured this way means that Matju could write his [expr] SQL query too, and they would work with the different SQL database objects (sqlite, psql, mysql). As for the SQL binding, I was thinking it would happen inside of the object, binding the placeholder names to the selectors. As long as there wasn't any new input on the SQL inlet, then the SQL statement wouldn't need to be recompiled. My thought too... Another question I just thought of it how to handle returning multiple results from s single query. If it followed the [textfile] style, then you would have to bang to get each individual result, then keep banging until you get a bang on the status/second outlet, meaning the query was done. I think this could work. This is already what I have been doing. Basically, as we are working now, the SQL would get input on the right inlet, then if any binding were needed, that would be done, and when the next bang occurs, the query is submitted, and the first result set is returned. Any subsequent bang would return the next result set. And when the result sets have been exhausted, it would send a bang out the status outlet to indicate the sets are done. Cool, that sounds like a good idea. I probably got it from you. :) Maybe you are already doing this, but a query could also send a message out of the status outlet to say how many results were found (i.e. [results 5(). This number could be routed to trigger an [until] or other such behaviors. (using the completion bang to stop [until] probably makes more sense though). .hc Mike .hc -- -- There is no way to peace, peace is the way. - A.J. Muste -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
Siriusly though... I seem to recall Newton was something of an occultist. Einstein and many other scientists share beliefs in supernatural entities. Does that really effect the value of their work? By all accounts Stockhausen was an arrogant man, which perhaps explains his clumbsy explanations due to unwillingness to research and study others. But, whatever you think of the man and his ravings, the work stands on its merits because it confirms hypotheses and has predictive utility. That makes it science. Probably more so than Art imho. What kinda makes him great, but also a bit sad, is what he achieved was in isolation, like many who fall into the cracks between the pillars of established thought. andy On Mon, 10 Dec 2007 22:41:32 +0100 Yvan Vander Sanden [EMAIL PROTECTED] wrote: Andy Farnell wrote: Of course he will always be remembered as an avant garde composer, but much of Stockhausens greatness is missed by artists who saw him as a pseudo-scientist and scientists who dismissed him as an artist. He was both at different times. A lack of rigor and precise voclabulary hides his contribution to psychoacoustics, he basically provided experimental support to Gabors theories, yet he is not mentioned once in critcal textbooks like McAdams and Bigand. And of coruse we must not forget he came from sirius to explain us all that :-) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] RIP Stockhausen
He'll be missed, but the music will live on: http://flickr.com/photos/cypod/2094889566/ On Dec 11, 2007 5:15 AM, Andy Farnell [EMAIL PROTECTED] wrote: Siriusly though... I seem to recall Newton was something of an occultist. Einstein and many other scientists share beliefs in supernatural entities. Does that really effect the value of their work? By all accounts Stockhausen was an arrogant man, which perhaps explains his clumbsy explanations due to unwillingness to research and study others. But, whatever you think of the man and his ravings, the work stands on its merits because it confirms hypotheses and has predictive utility. That makes it science. Probably more so than Art imho. What kinda makes him great, but also a bit sad, is what he achieved was in isolation, like many who fall into the cracks between the pillars of established thought. andy On Mon, 10 Dec 2007 22:41:32 +0100 Yvan Vander Sanden [EMAIL PROTECTED] wrote: Andy Farnell wrote: Of course he will always be remembered as an avant garde composer, but much of Stockhausens greatness is missed by artists who saw him as a pseudo-scientist and scientists who dismissed him as an artist. He was both at different times. A lack of rigor and precise voclabulary hides his contribution to psychoacoustics, he basically provided experimental support to Gabors theories, yet he is not mentioned once in critcal textbooks like McAdams and Bigand. And of coruse we must not forget he came from sirius to explain us all that :-) ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Use the source ___ 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] Fwd: [psql] object hand-holding
On 12/10/07, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: Cool, that sounds like a good idea. I probably got it from you. :) Maybe you are already doing this, but a query could also send a message out of the status outlet to say how many results were found (i.e. [results 5(). This number could be routed to trigger an [until] or other such behaviors. (using the completion bang to stop [until] probably makes more sense though). I could be wrong on other databases, but sqlite doesn't return the count of the number of result sets found. And as far as using an [until] object, you could still hook up the bang sent out the status outlet to the until so that it would shut it down when needed. Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbolatom: why does it not allow to type spaces?
On Dec 10, 2007, at 6:48 PM, Roman Haefeli wrote: On Mon, 2007-12-10 at 16:34 -0500, Mathieu Bouchard wrote: On Mon, 10 Dec 2007, Roman Haefeli wrote: (or am i overseeing something?). It would only break externals that rely on lack of spaces in any way, and only if supposing that you weren't already using some other way of producing the spaces. about spaces, those that break are: [netsend], [print], [textfile], ... anything using atom_string(). ah, yes i am overseeing. thank you for mentioning them. to be added: labels in iemguis, when saved. but these are things that already would break now and it is possible to create symbols containing spaces in pd, it's just not as easy as just using a symbolbox. fact is, that people do it anyway, so why trying to prevent them? i didn't know that [print] would be affected. in what way is it affected? at least visually it doesn't seem to be. i encounter that ' ' is treated in a non-comprehensibly special way, since other characters such as ';' or ',' are escaped by symbolatom (or by pd, i don't know) and can be used, atltough they have a meaning in pd as well (like 'space' has). wouldn't it be more consistent, if ' ', ',' and ';' would be treated the same way? A simple fix for allowing spaces is making the label be based on a list rather than a symbol. This is what I am doing tkwidgets. But for the iemguis, I'm not sure it would work since it might break backwards compatibility. .hc roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism.- retired U.S. Army general, William Odom ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [psql] object hand-holding
What we really need is regression testing, I think that would make it easier to convince Miller to accept patches, and would be a great tool for finding bugs. Matju started that project, any word on that Matju? I'd love to see that in action. :D .hc On Dec 10, 2007, at 5:33 PM, Martin Peach wrote: It probably would end up in vanilla if there was a demand for it, although Miller doesn't seem to like the idea, needs more convincing ;) Martin Mike McGonagle wrote: To: Martin Peach [EMAIL PROTECTED] CC: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 14:17:20 -0600 Is this something that is part of PD Vanilla? I would like to be able to have this external running there. Thanks, Mike On 12/10/07, Martin Peach [EMAIL PROTECTED] wrote: If you have applied the add string support patch you can use the blob atom, which is essentially a pointer to, and the length of, a binary string. The string can be anything at all. Martin Mike McGonagle wrote: To: pd-list@iem.at Subject: Re: [PD] [psql] object hand-holding Date: Mon, 10 Dec 2007 13:29:16 -0600 On a different note, has anyone given any thought to handling Blobs? I know that in SQLite, they store the data as binary strings, but I am not quite certain how the external would handle the actual data going into and coming out of it. Mike ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Peace may sound simpleone beautiful word but it requires everything we have, every quality, every strength, every dream, every high ideal. Yehudi Menuhin (19161999), musician ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] re . xml-rpc client
Hallo! Thanks I looked at that but it wasn't clear to me how I could connect to an external server such as http://xmlrpc-c.sourceforge.net/api.sample.php with this. Do I need to run a python script along with the patch? Is there a help file some where? Well, there is an help pach: look in /externals/iem/iemxmlrpc (I think not a help patch, but an example patch). And you should be able to use that with any other language than python ... LG Georg Thanks Georg . I saw this patch but it doesn't really have any explanation associated with it that I can see. Also one would have to run another script in Python or something to make the xml-rpc calls if I understand it correctly. Is that correct? I was wondering if there was an external with the xml-rpc library included to avoid having to use anything along with PD. In the ideal case one would use only PD as the client and be able to contact a remote xml-rpc server directly. I guess this isn't currently available or perhaps I just don't understand iemxmlrpc? Thanks, Jim ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Moveable Type - powered by Pd
As a follow up, I just read a nice little comment toward the end of this blog post by David Byrne: http://journal.davidbyrne.com/2007/12/12062007-embedd.html Congrats! ~Kyle On Dec 5, 2007 11:18 PM, Hans-Christoph Steiner [EMAIL PROTECTED] wrote: It is running PDa 0.4 for sound and custom python to control the text: http://gige.xdv.org/pda/ it uses these boards: http://www.embeddedarm.com/epc/ts7250-spec-h.html It uses this distro of linux: http://www.embeddedarm.com/linux/main.htm We are currently writing a paper about it for a conference, which we hope will be published. It will cover the whole thing in more technical detail. .hc On Dec 5, 2007, at 9:59 PM, palmieri, ricardo wrote: hi hans. this screens is a comercial product, or a special project? do u have more info about it? ah is alex posada in the earstudio moveable type album? hasta. palmieri 2007/12/5, Hans-Christoph Steiner [EMAIL PROTECTED]: In case anyone is interested, there is now a newspaper article with a video about this piece: http://www.nytimes.com/2007/10/25/arts/design/25vide.html .hc On Nov 16, 2007, at 4:24 PM, Hans-Christoph Steiner wrote: If any of you happens to be in New York City, drop by the lobby of the new New York Times building. It's open to the public, and there is a great installation there. The sound is all powered by Pd and the text handling and sequencing was done with Python. http://earstudio.com/projects/moveable_type.html Moveable Type Mark Hansen and Ben Rubin (in progress, to be completed in fall, 2007) Moveable Type, by New York artist Ben Rubin and U.C.L.A. associate professor Mark Hansen, is an artwork commissioned for the ground- floor lobby of The New York Times Building in New York City. When complete, it will be a dynamic portrait of The Times. Statistical methods and natural-language processing algorithms will be used to parse the daily output of the paper (news, features, editorials) and the archives, as well as the activity of visitors to NYTimes.com (browsing, searching, commenting). The resulting refracted view of The Times will be displayed on 560 vacuum- fluorescent display screens installed in the lobby. I'll post more on this when I get it, like video would be nice... .hc -- -- ¡El pueblo unido jamás será vencido! - --- 'You people have such restrictive dress for women,' she said, hobbling away in three inch heels and panty hose to finish out another pink-collar temp pool day. - Hijab Scene #2, by Mohja Kahf ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- ricardo palmieri # 1185833173 [palm.estudiolivre.org] [skype:palmieriricardo] [jabber: [EMAIL PROTECTED] [msn: [EMAIL PROTECTED] [linux user # 392484] Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- - - - -- http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] re . xml-rpc client
Hallo! Thanks Georg . I saw this patch but it doesn't really have any explanation associated with it that I can see. Also one would have to run another script in Python or something to make the xml-rpc calls if I understand it correctly. No, this is just an example in python... Is that correct? I was wondering if there was an external with the xml-rpc library included to avoid having to use anything along with PD. In the ideal case one would use only PD as the client and be able to contact a remote xml-rpc server directly. Yes, I think thats the idea - however, you have to replace the calls from the python example with the equivalent calls from your desired language - I'm sorry, I only used it in python so far, so I can't give an example ... So maybe the best is to simply try to reprogram this python example in your language (if you have problems just post them) - then this could be also added as an example ... LG Georg ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
