Pd-list December 2007

pd-list@lists.iem.at

129 participants
239 discussions

Re: [PD] [psql] object hand-holding
by Hans-Christoph Steiner 12 Dec '07

12 Dec '07

On Dec 11, 2007, at 3:45 PM, Hans-Christoph Steiner wrote: > > On Dec 11, 2007, at 8:29 AM, Frank Barknecht wrote: > >> Hallo, >> Jamie Bullock hat gesagt: // Jamie Bullock wrote: >> >>> Actually, please don't be quiet! When this was discussed some >>> time ago, >>> you mentioned Python as a solution, and my feeling was that if I >>> write a >>> piece and it uses some database connectivity, I don't really want to >>> have to distribute a Python runtime, relevant Python SQL module, >>> [py] >>> and all the respective dependencies with it. I just (at most) >>> want to >>> include an external, and the databse library it uses. If I write a >>> piece, I can't reasonably expect a performer to resolve all of this >>> themselves - it needs to "just work". I also want to minimise as >>> much as >>> possible the number of discrete components in the system that could >>> possibly go wrong. >> >> That's quite sensible. As soon as a DB interface is involved, one >> already has entered dependency hell, so minimizig further >> dependencies >> may be a valid goal. However a dependency on flext is just a >> dependency at compile time, so it's not really an additional >> dependency at runtime. A dependency on Python is kind of a dependency >> at runtime, as you need a possibly large Python installation. A >> dependency on Lua is also a runtime dependency, however as Lua is >> small, including it with the binaries will make the runtime >> dependency >> not matter. >> >> An immediate advantage of both Python and Lua is, that once the >> system >> is set up (easy with Lua, a bit tricky with pyext), the actual object >> code is just a textfile with a script. Especially as so far it's not >> even clear, how the SQL class in Pd should behave, this would allow >> rapid turnaround cycles in development. (For example I posted a >> working SQL object in Lua some weeks ago, and in Pyext some months >> ago, that took me about 20 minutes to write, including help-patch. In >> the case of Lua, I had never written SQL code in that language >> before. >> I wasn't so fast because I would be a genius programmer, but because >> the language is easier and no compilation is involved.) >> >> For a general purpose DB interface I would generally still prefer >> Python because threading is possible, but if ease of installation >> is a >> higher goal, Lua IMO even beats C-externals. > > Things are easy to compile only if your machine is setup for > compiling. Pd patches and binaries shipped as part of Pd are by > far the easiest to use. Getting distribution working in a non- > trivial task, so unless lua and/or python are built as part of Pd- > extended, I would not consider it easy. > > Other than that, Python, PHP, Perl, Lua, etc all have native > interfaces to databases (some likely written in C), I think Pd > should also have a native interface for databases. Pd is written > in C, we have working C code, Pd externals written in C have a > proven track record of ease of use, so it makes sense to write this > interface in C as well. I just wanted to add, I am not anti-python or lua or whatever. It's just a practical matter. Pd is written in C, therefore it's going to be much easier to manage Pd code written in C. C is a pain, that's true, but that's what we got. Perhaps someone could write another pd in Lua! :D .hc > > That said, I think we have a solid interface sketched out, I think > it's time to write some code and try it out. I've started porting > the mysql external from Max to Pd. Let me know if you guys want > specific help with psql and sqlite. Ultimately, I think these all > should be part of a 'sql' library, and then we can also add the > query building objects too. > > .hc > > > ---------------------------------------------------------------------- > ------ > > 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 > > > ------------------------------------------------------------------------ ---- "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

1 0

hardcore nerd question
by Andy Farnell 12 Dec '07

12 Dec '07

In a sci-fi story I once read, an inventor creates a device that can listen into the past by recovering long passed conversations from the thermal heat in a building. The author has totally slipped my mind. Does anyone remember this story and who wrote it? Cheers, Andy -- Use the source

5 9

RIP Stockhausen
by Chris McCormick 11 Dec '07

11 Dec '07

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=1&ref=…> Best, Chris. ------------------- http://mccormick.cx

8 10

re . xml-rpc client
by jim ruxton 11 Dec '07

11 Dec '07

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

2 3

Re: [PD] VOSIM with a tiny bug
by robbert van hulzen 11 Dec '07

11 Dec '07

³An artist is never ahead of his time but most people are far behind theirs.² Edgard Varèse .andre wrote: > is this just me, or why are Andys emails always in the future ?

1 0

Re: [PD] [PD-dev] Error when crosscompiling pdlua
by Patrice Colet 11 Dec '07

11 Dec '07

Martin Peach a Ã©crit : > Frank Barknecht wrote: >> Hallo, >> Martin Peach hat gesagt: // Martin Peach wrote: >> >> >>> With dlls you have to export symbols using a def file or /export: statement >>> on the command line (or __declspec(dllexport) in the code with MSVC). On >>> linux all symbols in a shared library are visible by default, it's about >>> the structure of a windows dll versus that of a unix shared library, not >>> gcc. >>> >> So unless pd.dll is built with sys_loader exposed, I won't be able to >> build a loader-external, right? If so, then I'll let the >> MS-Windows-people take over building pdlua. >> >> > Usually on Windows you link against pd.lib, not pd.dll, so it ought to > work. You will need to include the header file containing sys_loader > (except I can't find sys_loader anywhere in the pd source). > > Martin by the way, what is sys_loader() or what it is supposed to be? !There is no such thing like this in pd source, maybe it is "sys_loaded()" in s_loader.c?

2 1

phasor time scaling
by Jamie Bullock 11 Dec '07

11 Dec '07

Hi, Has anyone implemented 'phasor time scaling' as an abstraction (or external)? I know it is relatively easy scale a phasor where the frequency of the scaled phasor is an integer multiple of the master phasor: [phasor~] | [*~ 2] | [wrap~] ...but what about non-integer multiples, and fractional scaling? Jamie -- www.postlude.co.uk

5 11

Re: [PD] array indirection
by Chuckk Hubbard 11 Dec '07

11 Dec '07

On Dec 9, 2007 10:50 PM, Phil Stone <pkstone(a)ucdavis.edu> 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 <pkstone(a)ucdavis.edu> 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(a)iem.at mailing list > >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list > >> > >> > > > > > > > > > > -- http://www.badmuthahubbard.com

3 4

Re: [PD] [psql] object hand-holding (fwd)
by Mathieu Bouchard 11 Dec '07

11 Dec '07

---------- Forwarded message ---------- Date: Sun, 9 Dec 2007 20:23:16 -0500 (EST) From: Mathieu Bouchard <matju(a)artengine.ca> To: Mike McGonagle <mjmogo(a)gmail.com> Subject: Re: [PD] [psql] object hand-holding On Sun, 9 Dec 2007, Mike McGonagle wrote: > On 12/7/07, Mathieu Bouchard <matju(a)artengine.ca> 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. > 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

2 2

Moveable Type - powered by Pd
by Hans-Christoph Steiner 11 Dec '07

11 Dec '07

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!

3 4

← Newer
1
...
13
14
15
16
17
18
19
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list December 2007