Pd-list June 2007

pd-list@lists.iem.at

146 participants
264 discussions

pdplugin on a browser
by Miguel Cardoso 01 Jun '07

01 Jun '07

Thanks IOhannes So has anyone developed pd-plugin? it seems it only works on windows.... is there anyone else who developed other versions available of such plugin ? :D On May 31, 2007, at 7:35 PM, zmoelnig(a)iem.at wrote: > Quoting Miguel Cardoso <mcardoso(a)soopa.org>: > > >> Hi Frank! >> >> >>> http://www.iua.upf.edu/~malonso/pdplugin/ >>> >>> >> >> I had seen that one before, but it doesn't seem to work... on windows >> it installs de plugin, but when I try the test examples they don't >> work. >> anyone on the pdlist has used them? >> is the plugin still being developed? >> From the info you sent me it seems that pdplugin is just a >> javascript plugin to connect to pd server, rather than having pd >> running on the client-side. >> >> > > no its not. > the "barcelona" plugin is basicaly stripped down pd compiled into a > plugin (so it is exactly what you asked for) > > there are 2 other approaches: > - controlling a pd server via a plugin (javascript, java,....) or > directly via xml-rpc; there are several sites out there that use this > (afaik gollum.artefacte has a pd/pdp/pidip streaming server; pd-radio > was of the second type) > - controlling a full-fledged local installation of pd via a plugin > (iem's iARS took that road) > > mfg.asdr > IOhannes > > > > >

2 3

Re: [PD] what distinguishes a numeric symbol as an argument?
by Matteo Sisti Sette 01 Jun '07

01 Jun '07

Thanks a lot Frank, now I see it all quite clearly. I always thought that the two following conjectures were true: conjecture 1 - any given message output by any PD object can always be reproduced by writing it down literally in a message box conjecture 2 - a PD message is simply a human-readable string that you can always "see" by for example [print]ing it, or prepending a "set" and viewing it in a message box, and two messages that "appear" identical are identical. Now I see both conjectures are wrong (kinda disappointed since I loved them) but once I assume that, and thank to your explanation, everything is clear and coherent. A desired message can always be generated using a makefilename or something, and the difference between different cases can be detected - though all this in a less immediate way than I thought. Now that I think about it, a proper escaping mechanism for writing literals and spelling messages could allow both conjectures to become true without touching the message mechanism: an escape character such as § or whatever may force a number to be interpreted as a numeric symbol (or numeric symbol-selector). For example: [§123( [list 1 3 §123 foo bar( [symbol §123( Also, the [print] object may print out numeric symbols with the escape character Also, when dynamically setting (or updating) the content of a message box, the escape character may show up. Wouldn't it be desirable? What would the drawbacks be? Thanks again m. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Dvd Verbatim 16x da 0, 32 - Masterizzatore Pioneer112d 29,90 - Cdr Memorex da 0, 16 - Stampa Foto a 0,06 con 25 foto gratis. Solo su atomicshop.it Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6576&d=31-5

4 3

what distinguishes a numeric symbol as an argument?
by Matteo Sisti Sette 01 Jun '07

01 Jun '07

Hi list I understand that [symbol 43( is not the same as [43( as it is interpreted as a symbol, not a float. So I can send the message [symbol 43( to a symbol atom, or to any object that works with symbols, and it will be handled just as if it was [symbol dog(, right? However, when this symbol is inserted as an argument into a message, or packed into a list, what is it that distinguishes it from the number 43?? Let's make a practical example. I want to dynamically set the label of a canvas so that it shows a number. Suppose the receive symbol of the canvas is mycanvas_receive. (1) The following doesn't work: [label 43( (*) | [s mycanvas_receive] (2) Nor does this: [43( (or replace this with a number box) | [label $1( (*) | [s mycanvas_receive] (3) Nor this: [symbol 43( | [label $1( (*) | [s mycanvas_receive] (4) While this DOES work [43( (or replace this with a number box) | [makesymbol %d] | [label $1( (*) | [s mycanvas_receive] However, I can't see any difference between the output of the message box (*) in (4) and in (1-3). If I connect that message box to a [print] in any of the four examples above, the output is always "label 43". It seems that the message that is generated in example 4 is intrinsically but invisibly different from the previous 3 examples. I may deduce that each argument of a message has an associated type that somewhat depends on its "history" and cannot always be "seen"... which I don't like but may be an explanation. However, this does not explain the following: * Isn't the output of [makefilename] in example (4) just the same as [symbol 43( of example 3?? Then why doesn't example 3 work as well??? Also, consider this: (5) [label 43( | [unpack s f] and this (6) [symbol 43( | [label $1( (**) | [unpack s f] In example (5), the second outlet of unpack outputs float 43, which is (somewhat) coherent with the fact that example (1) didn't succeed to set the canvas label However, in example (6) unpack gives the error "unpack: type mismatch"... so I guess that the "$1" (i.e. the "43") in (**) is seen as a symbol, not a float....... but then, again: why didn't example (3) set the canvas label??? Anybody can help me to understand the underlying logic? Oh shit!!!!!!! Now I see that the following: [symbol 43( | [print] just outputs "symbol " while [43( | [makesymbol %d] | [print] outputs "symbol 43" as expected.... isn't it weird?????? Well... again, if anyone can help me to undertsand this, I'll be grateful Thank you m. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vacanza in Grecia: 7 giorni con trattamento all inclusive in albergo 4 stelle a soli 479 Euro Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=31-5

3 3

Re: [PD] mMm
by Cypod 01 Jun '07

01 Jun '07

mMm looks really cool, I can't wait to try it thanks,

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list June 2007