Plasma Studii
Since the beginning
Works in New York United States of America

PORTFOLIO (8)
BIO
judsoN = computer artist for shows internationally on stages, galleries and the web, and the Artistic Director of Plasma Studii, a non-profit arts organization in New York. His goal is to use technology as a tool to fuse arbitrary distinctions in art, such as dance and sculpture, color and sound frequencies, stages and web sites. His live interactive pieces appear in such venues as plays in circus tents across Europe, installations for places like the Arts Council of Mildura, Australia, on web sites at ISCAM (in Istanbul) and cTheory for Cornell University (twice). His artwork published in books (US, Europe, South America) and on CD-Roms worldwide. Studied choreography under Doug Elkins, music composition with a student of Stockhausen.
Discussions (278) Opportunities (1) Events (3) Jobs (0)
DISCUSSION

Re: Re: Re: Re: AJAX for artists


just so everybody's clear on it, on the same page, XML is not really a technology as much as a convention. this may be stuff you (the reader) realize, but seems not all do.

adding the />s won't make any difference to the HTML readers, so XML absolutely, literally is HTML, but with a few extra symbols thrown in where it won't bother a web page. it is all entirely adding conventions, nothing mechanical/practical (as in "practice" not utility). but RSS readers look for standardized HTML. it's a tedious sollution, not an "elegant" one and also a "systemization" of something that previously existed. but that applies to most everything in consumer computer technology in the last 7 years. even most of the stuff you see from WIRED, MIT or NASA.

Converting text to ASCII numbers was a development. sending info over the web in redundant "packets" for verifying the re-assembly of them was a development. adding time-based compression, as opposed to only pixel-location-based was a development. but those happened years ago.

RSS isn't actually any profound improvement over bookmarks. whether you look at it mathematically or neurologically, a person reads headlines whenever they direct their focus and auto-downloading makes no ultimate difference. (just as the usefulness of express stops in the NY subway depends entirely on the number of cars running. Usually, you wait longer for the 2,3 than yoyu save by skipping stops.) or a blog is actually not much different, only far more complicated to use, a less clear layout for readers, than an old fashioned bulletin board.

writing them from scratch is pretty easy and there's no point in using pre-fab blogware. it force fits your organization to what they think the average person needs. creativity isn't impossible, but blogs discourage it by making it a multi-step process where it was effortless, required no conscious thought. dreamweaver does that plus auto-generates convoluted ways to script because it has a lot less logic built in than we humans do.

learning code shouldn't be a dauting task at all, it is like everyone being expected to be comfortable making change in their country's currency (the US is pretty easy but the UK is tough) or using a phone. much more complicated. try explaining it to a kid for the first time. we gradually over years, figure it out, then forget we didn't know.

most often, developers use XML to act like a simplified database. but a simple text file would serve the same purpose. a hard return instead of "<category>...</category>". unless your dealing with a huge inventory or 1000 name mailing list, the whole word "database" really only serves as fashion.

the biggest difference is Flash. but the whole "parent, sibling" thing of XML is pointless if you use any (far simpler) tool. There are a ton of things that will read the text from a URL. Flash's XML reader is handy because it is really such a moron. it doesn't have any idea what that text is. what is XML. so you can actually read or write anything, and it'll think this must be one big long attribute. just write the text to whatever.xml

Dirk Vekemans wrote:

> Afaik the AJAX thing is only new in the sense that it's a
> systematisation of
> existing javascript techniques to further the rendering of xml in an
> appropiate client-side way. It offers an interesting alternative for
> doing
> more with your server resources on the client side and as you've shown
> with
> your excellent example code you don't need to go deep into server-side
> programming to accomplish a lot with it.That's excellent for artists
> to get
> what they want without too much fuzz.
> Professionally, i've been hesitant to jump the Ajax wagon because i'm
> in
> the habit of turning to Flash for any client-side processing, and
> Flash
> ofcourse in that context is just prepackaged javascript with the
> advantage
> that there's a large userbase developing all kinds of classes to
> handle your
> xml stuff. A major disadvantage with Flash is the slowness of parcing
> xml,
> it's a real bottleneck, although it has improved somewhat in the
> recent
> versions of the player, i gather. That's why i prefer to roll out the
> data
> for Flash from the server with java binding classes, that really makes
> for a
> speedy combination and you can rebalance the processing load
> (server-client)anytime you run into trouble. There's lot's of
> examples of
> this Flash/xml/java model in my Cathedral, the monAd blog system is
> built on
> it (http://www.vilt.net/nkdee/monads/) and there's the rather noisy
> experiment at http://www.vilt.net/nkdee/kids.jsp (unfinished like
> nearly
> everything) that has a basic idea similar to Myron's Animal Locomotion
> (wow
> Myron, some serious work you got there! Too bad the stats app is for
> Linux
> servers only, i'm commercially hooked to a windoze host).
>
> Ofcourse my own prefs are very relative in value (i actually enjoy its
> complexity, there's a sense of delicacy to it), you can't do much this
> way
> if you don't use some tools like Altova's xmlSpy suite to generate the
> Java
> code for you, you 've got the trouble with Macromedia changing players
> every
> year, so there's a lot of mess you need to be aware of, and AJAX sure
> is a
> much cleaner, straightforward approach in this.
>
> I can't see why an AJAX solution could avoid overloading the client at
> some
> point, though. You won't notice anything going wrong developing
> easily, but
> as your app scales up you'll reach the limit there soon enough. The
> whole
> thing is about balancing the workload, always has been, always will.
> So
> sure, AJAX 's a good thing as long as you don't expect it to solve all
> of
> your problems...
>
> greetz,
> dv
>
> Dirk Vekemans, poet - freelance webprogrammer,
> Central Authoring Process of the
> Neue Kathedrale des erotischen Elends
> http://www.vilt.net/nkdee
>
> dv@vilt.net
>
> http://www.vilt.net
> http://www.viltdigitalvision.com
>
>
>
> > -----Oorspronkelijk bericht-----
> > Van: owner-list@rhizome.org [mailto:owner-list@rhizome.org]
> > Namens Eric Dymond
> > Verzonden: zondag 5 februari 2006 6:07
> > Aan: list@rhizome.org
> > Onderwerp: RHIZOME_RAW: Re: Re: AJAX for artists
> >
> > Myron Turner wrote:
> >
> > > I was very interested in these posts concerning Ajax, which
> > I hadn't
> > > heard of before, although I was aware of the possible
> > interactive use
> > > of XML, i.e. read about it but never tried it out. But you
> > sparked my
> > > interest and I found useful links at
> > >
> > > http://en.wikipedia.org/wiki/AJAX
> > >
> > > While Ajax refers to a particular technology, ie. Javascript in
> > > combination with XML and behind the scenes server access
> > that can be
> > > parsed using the DOM, the purpose of Ajax, as I understand it, is
> > > independent of any particular technology.
> > >
> > > "The intent is to shift a great deal of interaction to the Web
> > > surfer's computer, exchanging data with the server behind
> > the scenes,
> > > so that the entire Web page does not have to be reloaded
> > each time the
> > > user makes a change. This is meant to increase the Web page's
> > > interactivity, speed, and usability." -- from wikipedia
> > >
> > > This is a practice which I've been interested in for some
> > time, most
> > > recently in Bstat Zero at http://www.bstatzero.org/bstat,
> > where using
> > > php and perl and both hidden and visible frames, I create a user
> > > interface that remains constant, while a great deal of data
> > is loaded
> > > into the hidden frames and accessed by the user interface.
> > >
> > > There are basically two kinds of hidden data--javscript and
> > html, each
> > > of which is accessed on an as needed basis. When a major
> > new access
> > > is made from the visible screen this hidden data changes. But
> > > otherwise, it reamins behind when the visible screen
> > updates data from
> > > the server.
> > >
> > > The aim was to give the user some feeling that this is a like a
> > > desktop application, and depending on how fast your
> > connection is and
> > > how great a load of data has to be fetched from the server,
> > it often
> > > has the feel of a desktop app.
> > >
> > > A big difference between Ajax and what I've been doing is that
> Ajax
> > > may put a bigger demand on the borwser. The data I load into the
> > > hidden frames is already pre-cooked, but with Ajax I assume
> > you have
> > > to parse the input stream. I found that I had to make changes to
> > > bstat when I put too much of a demand on the browser--even with a
> > > fairly powerful machine. So, that is a consideration.
> > There are some important considerations when you decide to use Ajax.
> > The most important is latency.
> > I have found that the javascript calls reduce the round trip
> > for the client.
> > The reason being that the entire web page doesn't have to
> > rebuild state, just the javascript callback. Only the
> > javascript layer makes the query, the page remains in state.
> > From a design view, this offers a very different design model.
> > Current design models require the server to re-emit the page
> > in it's entirety. The javascript callback keeps the page in
> > state, no flicker or refresh issues.
> > Since the model is so new, it will evolve. Current clients
> > require little memory usage on the browser.
> > I think the AJAX model is a big improvement on the current
> > client/server model.
> > Current browsers use very little memory and computation.
> > I can't see complex AJAX apps causing a memory issue on the
> > browser side.
> >
> > Time will tell, but all the major techs (java, ruby, python)
> > are moving quickly to this model for a good reason. It really
> > does open up possibilities that escaped us before.
> > Eric
> >
> >
> > >
> > >
> > >
> > > Myron Turner
> > > http://www.room535.org
> > > http://www.bstatzero.org
> > +
> > -> post: list@rhizome.org
> > -> questions: info@rhizome.org
> > -> subscribe/unsubscribe:
> > http://rhizome.org/preferences/subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in
> > the Membership Agreement available online at
> > http://rhizome.org/info/29.php
> >
>
>

DISCUSSION

Re: Re: Re: AJAX for artists


>You will need to add the xmlrpc classes to your classpath, but thats trivial.

hey eric,

probably, i'm just not getting this, but seems like the same result would be SO much easier with PHP? PHP is super clear, whereas Ajax just isn't at all. It's kinda the diff between intuitive and memorized. most folks don't even notice how much they memorize(as opposed to understand), but a lot seem like just arbitrary steps. sorta why reading/writing C is actually FAR more intuitively comprehensible (though compilers are usually convoluted) than anything in Flash.

the steps to write to a file (any file on the web, not just XML) in PHP are clear. seems it would be a lot more "available to artists"? is there some perk i'm missing here? Seems like bafflingly convoluted MS design?

<?

$FileOpen = fopen( "anything.txt", "w" ); // specify file to write to
if ( $FileOpen ) {
fwrite( $FileOpen, "write whatever you want, including HTML, XML or javascript code" );
}

?>

that's ALL the code it takes!

upload it to a server running php (and about all of em do) this shows up on the page (or it's included with osX, a download, etc). the code doesn't. if the page doesn't exist, it'll create it (though there's also a file_exists() function you can use if you don't want that to happen) the php could go absolutely anywhere on your HTML page. just name it x.php instead of x.html. it's designed with the coder in mind, not the code (which is why i say an MS thing, they seem to be incapable of thinking any way but from their own perspective)

reminds me of depreciating the <center> tag. what possible improvement could you make by replacing it?! if it's off by a pixel one in a thousand times, who cares?! (Web design just isn't print design and CSS and XHTML are just blatantly dumb code design) the tag is well worth it just because it works so clearly and without memorizing. Design utility extends to a lot more than just Italian coffee makers and German cars. Code is another appliance.

DISCUSSION

Re: Re: Re: Re: Re: Re: How to make a perfect Malevichpainting using only basic HTML code


>On Jan 27, 2006, at 4:29 AM, rob@robmyers.org wrote:

>>Quoting Eric Dymond <dymond@idirect.ca>:

>>I don't care about Malevich, I don't care about Rembrandt and Warhol.
>>They made artifacts like the dead sea scrolls. Interesting to targeted markets, but >>insignificant to the rest of humanity.

>Art's target market is humanity.

yeah, but so often, the ideal target is not the actual target.

malevich may have even told folks he liked humanity (many artists think they make art for humanity, but are just not admitting they're work is really mostly for themselves, they don't even consider many other humans' wants/needs.), but look at his product, it's not FOR everyone to appreciate. certainly doesn't include babies who haven't formed the ability to keep an object they see in their head in an abstract form. or even kids, because it just plain isn't fun. it doesn't include some starving person in some third world country that would be fed for a year with the money that's gone into it. and investments for no practical reason other than: because we can, and someone cares more about this bafflingly useless object than you. that's a little melodramatic, but "humanity" is a big word to use with "art".

some art may be for a larger chunk of humanity than others but lots (particularly this kind) is for the people who have an art background only, and rejects all others (from their perspective, pretty furiously).

>>What I am saying here is that here and now..., everything is good, in fact it's very good.

>Then so is the attitude of caring about Malevich.

both totally cool.

>>I should add that digital works will last forever, if properly nurtured. Like the old movies of the avant-garde re-issued on DVD, the current wealth of new media will be accumulated in databases, and will be available in 2600

>It is incredibly unlikely that systems in 2600 will still be able to run code
written for the 2600.

true, but his point remains. we don't generally own cylinder type record players in our home. but the music that was recorded that way, with a long extinct technology, is obviously still preserved/preservable. not every title gets the attention. but go into a big CD store (like tower in NY) and you'll find stuff from that era. then it's the Darwin gamble what survives. so much the current art that gets acknowledgment from the big institutions now is of little interest to humanity as a whole. we'll see.

actually, we won't. we'll be dead. so it's pretty unimportant to try to determine.

and therein is the crux of the biscuit. too easily in-discernible. but while art isn't necessarily FOR humanity, humanity does decide what will be preserved. the engineers who are budgeted to re-release those old records from the 20's needn't give a hoot about that era in music. somebody who works for the Smithsonian, may value preservation of history more than appreciation for any actual object. in fact, probably what will be saved, is the pieces that say "that is SO early 21st cent", not necessarily the most interesting in and of themselves.

>>( if humans are still around, and if they aren't .. who cares?).

>I do. I like humans.

but there's an awfully big likelihood they are screwing themselves over as a whole and a few with business priorities may ruin it for those with human priorities. like em or not, the ship is sinking fast. the best way to counter it, is not to ignore it or be convinced it won't happen, but assume it will and hopefully be wrong.

DISCUSSION

a lot more than 5 (was about malevich thing)


(tech folks: sometimes it works for me, sometimes not. this one just didn't post or bounce when i sent it? checked my "sent" copy and verified it came from the right e-address, to the list. go figure.)

well, ok, on a technical level, you are absolutely correct. probably you even mean computers creating graphics defaulting to drawing things like straight lines , flat colors, etc. but you bring up some really really important points. it's like curators asking for web art on video. it's not just these media have differences, but the similarities are so ridiculously and totally trivial to a computer (though not at all to that curator with an AV bias). focussing on the details of real paint is trivial to computer art. if the color(s) say "malevich", then that's really all they need to do. comparing them to some other media serves no useful purpose.

while on one hand, computer art and painting are independently methods of making. on the other, it isn't much of a leap of the imagination to understand the metaphor here. the entire notion of making a painting with a computer is too absurd to consider anyone means it literally. as much as the opposite would be silly. it only makes sense to assume the artist means it metaphorically. (my heart IS on fire). to read otherwise is (probably) to adhere to some bygone model.

which is all this seems to be saying. there are plenty of mondrian or pollock generators and some miss levels of what they were doing, while some go beyond. paintings miss levels too. an art student copying some masterpiece in a gallery (am sure we've all done) is hardly the ONLY way to make your "cover version". some art is pretty easily summed up (background=#000000). that doesn't cover every single aspect, but then nothing could. (it does say something that barnett missed in all his pomposity, that he took himself a little too seriously, spent way too much time breathing those fumes).

while tangibility is certainly cool, for me it's just that muscles and nerves are "listening" to their live environment. the mental process of registering color, or texture is not terribly different than registering motion or feeling off balance. all of these things are great resources for work, but no single one is required. at least not to anyone with a broader concept of environment or art, than simply AV. but tangibility doesn't equal art any more than smelliness. on the web, we get a tiny color palette (compared to a well-lit painting). hence, the color is an approximation, but not nearly as important as getting the idea across. in painting, there is no refresh rate. refresh rates are unimportant to painting. but neither colors no refresh rates are at all crucial, though both are welcome, for creating things.

there is no reason to limit "art" to focus on the visual, much less even sensory. interactivity is all about creating experience, not sensory info, the sensory is often an incidental by-product. one that many traditional art viewers/makers/curators commonly refuse to let go of. we CAN make sensory stuff, but we can also be flexible enough to look elsewhere.

Regina Celia Pinto wrote:

>
> ----- Original Message -----
> From: "Pall Thayer" <p_thay@alcor.concordia.ca>
> To: "listserv Rhizome" <list@rhizome.org>
> Sent: Wednesday, January 25, 2006 2:48 PM
> Subject: Re: RHIZOME_RAW: How to make a perfect Malevich painting
> using only
> basic HTML code
>
>
> >
> >> <!-- this is a Malevich painting, it seems strange but it is -->
> >> <!-- http://lunk.altervista.org/malevich --> ..."
> >
> > I disagree. It's a copy of a Malevich-ish idea. Not even a copy of
> a
> > Malevich painting. >
>
>
> Yes, you are completely right, we can't do perfect paintings with
> computers. (up to now, perhaps in the future?)
>
> When painting there is a tangible medium - paint, which makes a sloppy
> mess
> in cyan, yellow and magenta. In the case of computers, what we have is
> light
> and pixels, and red, green, blue, a clean art and.a certain limitation
> due
> to the software.
>
> What I think that is important is to explore in digital mediums all
> the
> possibilities of recognized Works of Art, it is a way of continue
> creating
> with that work. It means that the work continues alive. Exactely for
> this
> Creative Commons and Free Art are so important.
>
> Regina
>
>

DISCUSSION

RE: x 13 the random


i agree. but there seem to be 3 kinds of "random". we only have one
word.

random: as in some event that truly has no causality. it's actually
impossible to determine and may not even exist. even at a quantum
level. simply because we have no way of determining the outcome,
doesn't at all imply there's no causality. likewise, we often assume
causes. in standard billiard ball physics, we assume ball A hits ball
B and thus A causes ball B to move. that's an assumption though. it's
presumptuous for us even to determine any true randomness or causes
exist at all. (incidentally many use "arbitrary" to mean "random",
though it really means the opposite.)

pseudo-random: like from a rand() function. called "pseudo" because
actually they choose (usually based on the time of day or how cycle
count of your CPU) from a (fixed) list of jumbled numbers. the result
is technically pre-determined. just impossible for us to guess.

random: chaos. the stars may appear to be placed randomly. but of
course, they are not. a stranger's sneeze doesn't REALLY occur at a
random time, but it appears so to us. even brownian motion, the path
of electrons, etc. someone decided to call it random, but at most they
can only say "we are way too far from guessing now". humans can't
objectively know if they are ever correct in determining causality.
much less ruling out the infinite possibilities of all possible causes
of an event, merely because we think we can rule out a few.

but that still leads me to believe that, even if the word is rather
wishy-washy, there's a function to "randomness" (of whichever kind).
there is a use for not knowing a result, leaving it up to other forces.
especially, since those other forces will probably be determining it
any way. we are only humoring ourselves to think we decide any
outcomes at all.

i may think i choose to paint a brush stroke here. [sfx: thwip] but
there are very real neurological chains of events that determine my
choice. that are only afterwards called my preferences. there's no
point in arguing determinism vs. free will though, because we can't
possibly know free will objectively exists. and whether it does or
doesn't the end result is the same, i feel satisfied by my choice of
paint strokes or not. even if my satisfaction is also a result of
those chains.

but it's inspiration (at least to me) when i can say "this result is
not up to me, it's up to RANDOMNESS." maybe inspiration is a result of
stripping away the illusion of determinism. the responsibility of
guessing is relieved, which (for me) tends to spark new ideas.

On Jan 22, 2006, at 12:43 PM, Nad wrote:

> Eric Dymond wrote:
>
>> so in other words:
>> We can only exist in a closed universe.
>> Any amount of randomness will always create complex numbers.
>> Complexity abounds, randomness however always exists as an
>> immeasurable and non-quantifiable condition.
>>
>
> Frankly speaking, i haven't understood what you mean.
> are you referring to pseudo-random numbers?
>
> However I wanted to remark that we do not know what kind
> of universe we are living in.
> There is a video called "the shape of space", which
> i can recommend:
> http://www.geom.uiuc.edu/video/sos/about.html
> its about about some aspects of how one could possibly observe
> the shape of space.
>
> there is also to remark that we do not really understand
> quantum mechanics.
>
> nad
> +
> -> post: list@rhizome.org
> -> questions: info@rhizome.org
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php
>