Re: [PD] Gem compile error: filmAVIPLAY.cpp

2009-12-06 Thread IOhannes m zmoelnig
Peter Plessas wrote:
 Dear List,
 
 getting this trying to compile gem-0.92-1:
 
 
 make[1]: *** [filmAVIPLAY.o] Error 1

this is related to the avifile library, so it might help to know which
exact version of avifile-0.7 you are compiling/linking to.

what did configure say?

finally, your OS would be interesting as well.


gf,sdr
IOhannes

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem compile error: filmAVIPLAY.cpp

2009-12-06 Thread Peter Plessas
Thanks IOhannes,

IOhannes m zmoelnig wrote:
 Peter Plessas wrote:
 Dear List,

 getting this trying to compile gem-0.92-1:


 make[1]: *** [filmAVIPLAY.o] Error 1
 
 this is related to the avifile library, so it might help to know which
 exact version of avifile-0.7 you are compiling/linking to.
This is on Debian, libavifile-0.7-dev is of
Version: 1:0.7.48~20090503.ds-2

 what did configure say?
nothing special as far as i can tell:

...
checking for PKG_AVIFILE_CFLAGS... -I/usr/include/avifile-0.7
checking for PKG_AVIFILE_LIBS... -laviplay
...


Summary:
Result:
  Target : Gem.pd_linux
  Objects: Base Controls Geos Manips Nongeos Particles
Pixes openGL Vertex

Configuration:
  Compiler   : g++
  CXXFLAGS   : -g -O2 -fPIC -freg-struct-return -O3
-falign-loops=32 -falign-functions=32 -falign-jumps=32 -funroll-loops
-ffast-math -mmmx -msse2
 : -I/usr/include/lqt   -I/usr/include/lqt
-I/usr/include/avifile-0.7   -I/usr/include/FTGL -I/usr/include/freetype2
  INCLUDES   :  -I/usr/include/FTGL -I/usr/include/freetype2
  DEFINES:

  LIBS   : -ldv -lmpeg -lmpeg3 -lstdc++ -lGLU -lGL
-lXext -lXxf86vm -lXext -lX11 -ldl -lz -lm   -lpthread
 : -lftgl   -laviplay   -L/usr/lib -lquicktime
-lpthread -lm -lz -ldl -lquicktime -lpthread -lm -lz -ldl   -lMagick++
-lWand -lMagick
  LDFLAGS: -shared -Wl,--export-dynamic
 :

  Strip  : strip --strip-unneeded

  Install path   : /usr/local

 pure-data:
  version: 0.40
  extension  : pd_linux

 used optional libraries:

  font-rendering : FTGL

  image-support
use ImageMagick  : yes
use TIFF : no (forced)
use JPEG : no (forced)
  video-support
use mpeg : yes
use mpeg-3   : yes
use QuickTime: yes
use aviplay  : yes
use gmerlin  : no
  input-support
use v4l  : yes
use ieee1394 : yes


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Mathieu Bouchard

On Sun, 6 Dec 2009, Frank Barknecht wrote:

I was involved in early PDDP discussions (around 2005) as well, so PDDP 
isn't new to me. I dropped out of PDDP for various reasons after a 
while. Besides the endless discussion about template layout etc. another 
reason for my retreat was, that the help system started to require 
certain externals (pddp_link).


I was never really involved in PDDP discussions because it is definitely 
not right that documentation writers would have to mess endlessly with 
[cnv] sizes and pixel-precise positioning all of the time. Standards that 
require more work aren't as good as standards that require less work. 
Following the PDDP standard requires more work than the traditional way of 
making help files. Following the GFDP requires less work than the PDDP, 
but that's not all, it also requires less work than making help patches 
the traditional way! Especially for people who aren't quite happy with 
approximate layouts.


I can accept that, but obviously I had to stop contributing at that 
point. Some other early participants also dropped out, some for similar 
reasons IIRC.


How many of those PDDP contributors would have dropped out at the point 
that they would have had to use the template that they designed? Obviously 
it's fun getting together on the chatline and talk about each person's 
favourite colours and each person's favourite help-patch width, but living 
with the consequences of those decisions is something different. That's 
why in the end not much was done after the decisions were made. (If 
there's any hidden stash of PDDP docs that *do* follow the PDDP standard, 
I'd like to know.)



While I'm surely guilty of some anti-Pd-extended puritanism, my retreat from
PDDP didn't have anything to do with it. It has a different story.


Regardless of stated theoretical differences, there's not much that 
separates anti-extended, pro-portability-across-distribs, and pro-vanilla. 
Why would the distinction matter?


I believe, a general purpose help file template should not require 
objects not available in all major Pd distributions.


This is a contorted way to say that you only want vanilla.

In any case, GFDP uses a lot of abstractions, which use a lot of 
externals, and those externals are required for automatic-layout. (GFDP 
doesn't use [pddp-link] or any equivalent of it so far). If you 
acknowledged automatic-layout to be an essential feature, then you'd 
figure out a way to incorporate it that clashes as little as possible with 
your beliefs. Whereas if you start from your existing beliefs, then you 
don't even have to ask yourself whether automatic-layout is a good idea.


In October, I rewrote the GridFlow manual. That's 165 help files as of now 
(actually it should be about 200 help files to be complete). It was 
enjoyable. GFDP made it fun to write docs, and that's how I got myself to 
do it the best I could. I wouldn't have had the same level of fun have 
enjoyed it if I hadn't had the GFDP framework. If I had had to use the 
PDDP template (that is, reimplement it by hand in every !...@#$ help file) it 
would have taken forever, and I wouldn't have gone back nearly as often to 
add additional notes and rephrase what I had written, thinking «I will 
have to readjust the [cnv]s one more time if I change ANY text in here.»


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Hans-Christoph Steiner


On Dec 6, 2009, at 1:40 PM, Mathieu Bouchard wrote:


On Sun, 6 Dec 2009, Frank Barknecht wrote:

I was involved in early PDDP discussions (around 2005) as well, so  
PDDP isn't new to me. I dropped out of PDDP for various reasons  
after a while. Besides the endless discussion about template layout  
etc. another reason for my retreat was, that the help system  
started to require certain externals (pddp_link).


I was never really involved in PDDP discussions because it is  
definitely not right that documentation writers would have to mess  
endlessly with [cnv] sizes and pixel-precise positioning all of the  
time. Standards that require more work aren't as good as standards  
that require less work. Following the PDDP standard requires more  
work than the traditional way of making help files. Following the  
GFDP requires less work than the PDDP, but that's not all, it also  
requires less work than making help patches the traditional way!  
Especially for people who aren't quite happy with approximate layouts.


I think we had some useful discussions in PDDP, but not much work came  
out of it.  It got too bureaucratic.  I think the 'official' PDDP  
template is a place to start from.  I've used a simplified version for  
help patches in my 'apple' library, for example.


I think people should learn from PDDP, but not we just need more and  
better docs, so people should make them based on the knowledge from  
PDDP.  Then thru real world use, we can figure out what works best.


.hc




I can accept that, but obviously I had to stop contributing at that  
point. Some other early participants also dropped out, some for  
similar reasons IIRC.


How many of those PDDP contributors would have dropped out at the  
point that they would have had to use the template that they  
designed? Obviously it's fun getting together on the chatline and  
talk about each person's favourite colours and each person's  
favourite help-patch width, but living with the consequences of  
those decisions is something different. That's why in the end not  
much was done after the decisions were made. (If there's any hidden  
stash of PDDP docs that *do* follow the PDDP standard, I'd like to  
know.)


While I'm surely guilty of some anti-Pd-extended puritanism, my  
retreat from

PDDP didn't have anything to do with it. It has a different story.


Regardless of stated theoretical differences, there's not much that  
separates anti-extended, pro-portability-across-distribs, and pro- 
vanilla. Why would the distinction matter?


I believe, a general purpose help file template should not require  
objects not available in all major Pd distributions.


This is a contorted way to say that you only want vanilla.

In any case, GFDP uses a lot of abstractions, which use a lot of  
externals, and those externals are required for automatic-layout.  
(GFDP doesn't use [pddp-link] or any equivalent of it so far). If  
you acknowledged automatic-layout to be an essential feature, then  
you'd figure out a way to incorporate it that clashes as little as  
possible with your beliefs. Whereas if you start from your existing  
beliefs, then you don't even have to ask yourself whether automatic- 
layout is a good idea.


In October, I rewrote the GridFlow manual. That's 165 help files as  
of now (actually it should be about 200 help files to be complete).  
It was enjoyable. GFDP made it fun to write docs, and that's how I  
got myself to do it the best I could. I wouldn't have had the same  
level of fun have enjoyed it if I hadn't had the GFDP framework. If  
I had had to use the PDDP template (that is, reimplement it by  
hand in every !...@#$ help file) it would have taken forever, and I  
wouldn't have gone back nearly as often to add additional notes and  
rephrase what I had written, thinking «I will have to readjust the  
[cnv]s one more time if I change ANY text in here.»


_ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone:  
+1.514.383.3801___

Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list






Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.-William Carlos Williams




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Mathieu Bouchard

On Sun, 6 Dec 2009, Hans-Christoph Steiner wrote:

I think people should learn from PDDP, but not we just need more and 
better docs, so people should make them based on the knowledge from 
PDDP.  Then thru real world use, we can figure out what works best.


GFDP was born when trying to use a PDDP template. I tried real world use 
and I figured out what works best, and it made me make the GFDP template. 
I wouldn't mind calling my stuff PDDP 2.0 if that makes anyone understand 
what's going on with that.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Finding $0 and dealing with it in messages

2009-12-06 Thread Mathieu Bouchard

On Wed, 25 Nov 2009, Roman Haefeli wrote:


To me, it is not even clear, when data types are converted, in cases when
conversion happens at all. Does it happen at the 'inlet', or the 'outlet'?
at both?


It is always at the inlet. You will not figure this out by using [print] 
or [route], which are both designed to hide the inconsistency under the 
carpet. They both contain the combination of if-statements required to 
mask the problem. Basically each of those classes contains a replica of 
much of pd_defaultlist, only in a way that doesn't look like copy+paste.



[prepend] in Cyclone is different from [list prepend], and
that's by design, not a bug (as symbol-selector handling in [route] might be).

We don't know if it is a bug, but it doesn't seem logical in a common sense
of the word 'logical'.


«logical» thus means «something that follows from a set of rules (instead 
of just being a rule of its own)» instead of the other possible 
definitions of «something that follows the rules instead of not following 
them» and «something that was found using the rules instead of being found 
by other means»... (I didn't look at dictionary for this, I thought about 
what are the uses of the word that I do encounter in practice.)


But because the whole set of rules hasn't been defined or agreed upon, we 
don't know whether anything is logical or not, because logic always starts 
from a set of basic rules (which can't be deduced from any other rules... 
at least not literally).


Actually, we can know, as this is written in Pd's source code (and Dd's 
source code). It's just that the source has to be read... (well, if 
someone can find Martin Peach's internals doc, I can't find it atm, so I 
can't tell whether it documents this or not).


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Finding $0 and dealing with it in messages

2009-12-06 Thread Jonathan Wilkes


--- On Sun, 12/6/09, Frank Barknecht f...@footils.org wrote:

 From: Frank Barknecht f...@footils.org
 Subject: Re: [PD] Finding $0 and dealing with it in messages
 To: pd-list@iem.at
 Date: Sunday, December 6, 2009, 12:04 PM
 Hallo,
 Jonathan Wilkes hat gesagt: // Jonathan Wilkes wrote:
 
  --- On Sat, 12/5/09, Frank Barknecht f...@footils.org
 wrote:
   Hey, all I said is that *I* am not the right
 person to do
   that.
  
  If that's all you had said, I doubt anyone would have
 replied with 
  anything other than ok.
  
  And now I'm curious: why can't you create all the
 objects in that 
  patch?  If some of those objects don't create in
 pd-ext on win/macos/
  linux, at the very least the patch should be changed
 so that they are 
  removed (or replaced with ascii art).
  
  But if it's that you just prefer using pd-vanilla and
 don't want to 
  download/install pd-ext, why not just say that?
 
 Some history: 
 
 I was involved in early PDDP discussions (around 2005) as
 well, so PDDP isn't
 new to me. I dropped out of PDDP for various reasons after
 a while. Besides the
 endless discussion about template layout etc. another
 reason for my retreat
 was, that the help system started to require certain
 externals (pddp_link). I
 believe, a general purpose help file template should not
 require objects not
 available in all major Pd distributions. Help files should
 be accessible to
 everyone. I wasn't alone with this view, see:
 http://puredata.info/dev/pddp/2005-11-22-pddp_meeting.txt
 for example.  Some
 other PDDP contributors didn't have a problem with that. I
 can accept that, but
 obviously I had to stop contributing at that point. Some
 other early
 participants also dropped out, some for similar reasons
 IIRC.
 
 While I'm surely guilty of some anti-Pd-extended
 puritanism, my retreat from
 PDDP didn't have anything to do with it. It has a different
 story. 
 
 (I'm sorry for saying pd-extended docs in my previous
 mail, it should have
 been PDDP docs.)

Thanks, that clarifies some things.

So if [pddp_link] is removed, and external objects are given as comments 
in ascii art, would you have any other issues with pddp?  (I don't see 
template layout as a problem because I've been revising all the 
reference files to conform to one standard, and I can't imagine 
someone objecting to using them because they don't like the colors 
or whatever.  But the template looks pretty much like the one for 
[float] in pd-ext.)

[pddp-link] is currently used for pdpedia links, and links to 
tutorials and other pddp docs.  Currently [pddp-link] throws an ugly 
error msg in windows, although after you close the error message window 
the link works. I've been spot checking the links from help files to 
pdpedia, and of 200 help patches roughly 0% of the pdpedia links add 
anything to what's already in the help patch.  If I remove those links 
then it's just a matter of converting all the More info links to 
comments and voila, no more [pddp-link].

At some point, it would be nice to have either [pddp-link] in all 
distributions, or have the ability to links within pd comments 
(actually that would be much more useful in my opinion).

-Jonathan

 
 Ciao
 -- 
 Frank
 
 ___
 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] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Jonathan Wilkes


--- On Sun, 12/6/09, Mathieu Bouchard ma...@artengine.ca wrote:

 From: Mathieu Bouchard ma...@artengine.ca
 Subject: Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)
 To: Hans-Christoph Steiner h...@at.or.at
 Cc: pd-list@iem.at
 Date: Sunday, December 6, 2009, 8:08 PM
 On Sun, 6 Dec 2009, Hans-Christoph
 Steiner wrote:
 
  I think people should learn from PDDP, but not we just
 need more and better docs, so people should make them based
 on the knowledge from PDDP.  Then thru real world use,
 we can figure out what works best.
 
 GFDP was born when trying to use a PDDP template. I tried
 real world use and I figured out what works best, and it
 made me make the GFDP template. I wouldn't mind calling my
 stuff PDDP 2.0 if that makes anyone understand what's going
 on with that.

Could you post an example help patch?  I downloaded gridflow to check 
out how your help patches work but I'm on windows so I just get a bunch 
of broken objects.

-Jonathan


  

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] How to access audio files from disk randomly?

2009-12-06 Thread Roman Haefeli
Hi all

Yeah, it's never too late for basic questions. Basically i would like to
create file player patch, that let's you pick a soundfile (be it a wav)
of any number of channels and a bit depth currently supported by
[readsf~] and it should be able to play from any position between the
start and the end of the file. 

Usually i used a kludge by using [soundfiler] in order to get the number
of sample frames of the file and then i calculated the number of bytes
to be skipped in order to be able to let [readsf~] play the file from a
random position. However, this only works when the actual header size of
the file is constant (i.e. known and the same for every file; ok, when
the header sizes would be known, they wouldn't need to be the same for
all files, but you get the point) and when you know beforehand the bit
depth of the file(s), since [readsf~] reads it correctly, but doesn't
tell you about it.

Now, i would like to be able to play wav files correctly with arbitrary
(unkown) bit depths and arbitrary (unkown) number of channels. Also, i
am looking for a way to be able to load both, simple RIFF WAV and so
called 'Broadcast WAV' files (the ones with a 'bext' header signature). 

I also tried [wavinfo] from ext13. However, this seems to work only with
the former (simple) format, but not with broadcast wav-files. Funny
enough, [readsf~] seems to have everything needed built-in, since it
reads both formats correctly, it just does not expose those functions to
the pd patch (as this unfortunately is often the problem with many
object classes). 

Any idea or pointers to other externals welcome!

Roman



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] [sigmund~] and [fiddle~]

2009-12-06 Thread Jonathan Wilkes
Hello,
 Can [sigmund~] do everything [fiddle~] can do (or do it better)?

BTW: I'm finding that to use [sigmund~] with tables, the -t flag is 
unnecessary-- just remove it in the example in the subpatch and you 
get the same results.  Not sure if that's a bug or not, but it makes me 
wonder: what's the purpose of having the -t flag?

Thanks,
Jonathan


  

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Mathieu Bouchard

On Sun, 6 Dec 2009, Jonathan Wilkes wrote:

Could you post an example help patch?  I downloaded gridflow to check 
out how your help patches work but I'm on windows so I just get a bunch 
of broken objects.


Screenshots of all the helpfiles are available at http://gridflow.ca/help/ 
but this is 0.9.6 (and the new helpfiles are already a bit different). 
note that those shots are truncated when they are too long (higher than my 
screen). I didn't code an automated screenshot stitcher yet (and there's 
no way I'm gonna do this manually).


Some helpfiles that best illustrate GFDP (among those that fit in a 
screenshot):

  http://gridflow.ca/help/%23mouse-help.png
  http://gridflow.ca/help/%23labelling-help.png
  http://gridflow.ca/help/range-help.png
  http://gridflow.ca/help/receives-help.png

But really, to appreciate GFDP you have to know that every component is an 
abstraction instance (except comments), that there are invisible 
patchcords so that comments have owners, and then there is an automatic 
positioning system:


  http://gridflow.ca/gallery/doc_anim.mov

but this video doesn't demonstrate much of it. Here's a screenshot of 
range-help.pd when in edit mode:


  http://gridflow.ca/gallery/%23range-help-edit.png

patchcords that aren't used for sending messages are dashed and painted 
orange. The dashed boxes aren't usually there. They can be turned on by 
editing two abstractions (one for comments and one for non-comments). What 
you see in this screenshot is by editing only one abstraction; in the 
video, the other abstraction has been edited. Note that some buttons are 
visible only when in edit-mode. Note that moving a [doc_m] moves the 
attached comment around, but moving the comment around has no effect (or 
may reorder comments if there are several of them). Writing more text in a 
comment automatically moves all following [doc_m] downwards and so on 
including higher-level section headings ([doc_oo], [doc_o], etc)


There's more to it. I guess someone with a faster computer than mine could 
make a video of all the features.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)

2009-12-06 Thread Jonathan Wilkes


--- On Mon, 12/7/09, Mathieu Bouchard ma...@artengine.ca wrote:

 From: Mathieu Bouchard ma...@artengine.ca
 Subject: Re: [PD] PDDP (was: Finding $0 and dealing with it in messages)
 To: Jonathan Wilkes jancs...@yahoo.com
 Cc: Hans-Christoph Steiner h...@at.or.at, pd-list@iem.at
 Date: Monday, December 7, 2009, 2:37 AM
 On Sun, 6 Dec 2009, Jonathan Wilkes
 wrote:
 
  Could you post an example help patch?  I
 downloaded gridflow to check out how your help patches work
 but I'm on windows so I just get a bunch of broken objects.
 
 Screenshots of all the helpfiles are available at http://gridflow.ca/help/ 
 but this is 0.9.6 (and the new
 helpfiles are already a bit different). note that those
 shots are truncated when they are too long (higher than my
 screen). I didn't code an automated screenshot stitcher yet
 (and there's no way I'm gonna do this manually).
 
 Some helpfiles that best illustrate GFDP (among those that
 fit in a screenshot):
   http://gridflow.ca/help/%23mouse-help.png
   http://gridflow.ca/help/%23labelling-help.png
   http://gridflow.ca/help/range-help.png
   http://gridflow.ca/help/receives-help.png
 
 But really, to appreciate GFDP you have to know that every
 component is an abstraction instance (except comments), that
 there are invisible patchcords so that comments have owners,
 and then there is an automatic positioning system:
 
   http://gridflow.ca/gallery/doc_anim.mov
 
 but this video doesn't demonstrate much of it. Here's a
 screenshot of range-help.pd when in edit mode:
 
   http://gridflow.ca/gallery/%23range-help-edit.png
 
 patchcords that aren't used for sending messages are dashed
 and painted orange. The dashed boxes aren't usually there.
 They can be turned on by editing two abstractions (one for
 comments and one for non-comments). What you see in this
 screenshot is by editing only one abstraction; in the video,
 the other abstraction has been edited. Note that some
 buttons are visible only when in edit-mode. Note that moving
 a [doc_m] moves the attached comment around, but moving the
 comment around has no effect (or may reorder comments if
 there are several of them). Writing more text in a comment
 automatically moves all following [doc_m] downwards and so
 on including higher-level section headings ([doc_oo],
 [doc_o], etc)
 
 There's more to it. I guess someone with a faster computer
 than mine could make a video of all the features.

That's some cool stuff.  What are the externals that are being used (esp. 
to hide patch cords and move the abstractions into place?  Are the 
pngs/movs in dd or pd-ext?

-Jonathan


  

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] [PD-announce] NIME concert at Southpaw in Brooklyn, Tuesday, 12/15 8-11pm

2009-12-06 Thread Hans-Christoph Steiner

There will definitely be some Pd projects here:


NIME: New Interfaces for Musical Expression.
NIME: creating new performance tools for digital music.
http://itp.nyu.edu/nime/show/


In the eighth annual NIME concert, performers will play a series of  
newly designed electronic instruments that aim to keep the live in  
the live performance of digital music.


Electronic music is usually played with a keyboard and mouse. Laptop  
musicians often sit at a desk and give performances that are little  
more than watching someone make office gestures. The idea behind  
NIME is to go beyond the mouse and keyboard and beyond even piano  
keys and drum pads. It seeks to present performance systems that  
make the most out of the new opportunities for musical expression  
that digital technology offers.


This year's NIME concert will feature such innovations as a  
musically enhanced sewing machine, sonified floor tiles,  
performative knitting needles, turntablism for live  
instrumentalists, electronically controlled cartoon antics, novel  
realizations of the rock guitar, and a host of other exciting  
approaches to the creation of music.


NIME is an end-of-semester performance by 16 graduate student  
artists from the Interactive Telecommunications Program (ITP) at NYU.


Entry is $7 (Free for NYU ID holders)
Doors open at 7, Show starts at 8


NIME @ Southpaw

http://itp.nyu.edu/nime/show/
125 Fifth Avenue
Brooklyn, NY 11217


Tuesday, December 15, 2009
Performances 8PM-11PM
Doors open at 7PM


NIME at ITP
http://itp.nyu.edu/nime
Greg Shakar,
Hans-Christoph Steiner, +1-718-360-4872, ha...@nyu.edu

ITP
http://itp.nyu.edu
George Agudow +1-212-998-1891, george.agu...@nyu.edu

Southpaw
125 Fifth Avenue (at Sterling Pl)
Brooklyn, NY 11217
718.230.0236
http://www.spsounds.com




___
Pd-announce mailing list
pd-annou...@iem.at
http://lists.puredata.info/listinfo/pd-announce

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list