Re: [PD] flashing a bng without making it send?

2008-03-19 Thread matteo sisti sette
 flashing the background color might be what you need.

Oh yeah, great!

I needed a little bit of KISS-thinking :)

 Then you can use a
 different color when you flash it from outside.

I don't even need that.

So I could just implement my [control_bang] abstraction like this:

[r $1]
|
[pd generate_a_pair_of_color_messages]
|
[s $1-if-receive]

assuming that my [bng]s send directly to the target name and receive
from name-if-receive


-- 
Matteo Sisti Sette
[EMAIL PROTECTED]
http://www.matteosistisette.com

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


Re: [PD] 'apple' lib for controlling hardware and getting sensor data

2008-03-19 Thread Jack
Good, very interesting !
++

Jack


Le 17 mars 08 à 21:58, Hans-Christoph Steiner a écrit :


 Hey,

 I just finished of a quick library of functions for controlling some
 of the hardware features on Apple computers when running under Mac OS
 X.  So far, I have been able to control the screen brightness;
 control the keyboard backlight brightness and fade time; get data
 from the sudden motion sensor or built-in accelerometer; and get
 data from the built-in light sensors.

 It's included in the nightly builds as the 'apple' library, check
 5.reference - apple in the Help Browser for help patches.

 Also, this should be pretty easy to do for other computers.  For
 example, the Thinkpad features are pretty well documented under
 Windows and GNU/Linux:

 http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
 http://www-128.ibm.com/developerworks/linux/library/l-knockage.html
 http://www.almaden.ibm.com/cs/people/marksmith/sdl.html
 http://www.gnome.org/~fherrera/gtollina.c

 Or for Apple hardware, there is pbbuttonsd:
 http://pbbuttons.berlios.de/

 .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-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Alternate Controllers

2008-03-19 Thread Hans-Christoph Steiner

On Mar 18, 2008, at 8:56 PM, Charles Henry wrote:

 On Tue, Mar 18, 2008 at 7:34 PM, Derek Holzer [EMAIL PROTECTED] wrote:
 What's interesting is that the HID protocol is orders of magnitude
 faster than using USB-serial to access an Arduino. We figured that  
 out
 last week preparing for the gamepad hacking workshop at Pickled Feet
 here in Berlin.

 This is something I've been wondering about... where does that latency
 come from on the usb to serial on the arduino.  I am using debian
 Linux with 2.6.17 kernal on a computer that accesses the arduino
 through /dev/ttyUSB0

 The arduino is doing serial communication with a couple of IC's.  Even
 with 24 bits of information sent to an IC using 3-wire interface, the
 process only takes about a millisecond.  The computer interfaces with
 /dev/ttyUSB0 and sends a command, then waits for information to
 return.

 I poll the device with select().  The round trip time is around 15-16
 ms.  Only 2-3 ms are actually accounted for in the communication
 routines, so where does the other 12 ms come from?

 (Actually, I have thought about different methods, such as triggering
 an interrupt from the actual serial port via another pin on the
 arduino, to indicate that data has been sent.  Would it help?)

 I think that the linux kernel doesn't check the file very frequently,
 which gives me this kind of latency, but I don't really know.  I
 wonder, how is the HID interface different?  It gets registered as a
 character device, also, right?
 Any tricks?  fundamental concepts I'm missing?

USB-serial drivers are usually optimized for maximum thruput rather  
than low latency and jitter.  Basically, they were designed to hook  
up modems and the like.  USB HID was designed around low latency and  
jitter.  Most USB HID devices deliver data every 10ms with decently  
low jitter.

The best I've been able to get with Arduino/Firmata is 20ms.  The  
FTDI driver/chip on has a huge and crappy buffer, so lowering the  
poll time would actually make it slower with massive jitter.  With  
the Arduino, you can tie a pin of the Atmel to the FTDI USB chip then  
you can flip that pin to force the FTDI to send it's data  
(circumventing the buffer).  Then you can get reliable 10ms latency,  
perhaps lower.  Check the arduino forums for docs on that.

.hc




 Chuck

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



 


Using ReBirth is like trying to play an 808 with a long stick.- 
David Zicarelli



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


Re: [PD] Alternate Controllers

2008-03-19 Thread Hans-Christoph Steiner


Any luck getting the Guitar Heroes controller working with [hid]?

.hc

On Mar 18, 2008, at 8:02 PM, James Rojsirivat wrote:

Since I was working on the Guitar Heroes controller and [hid], I  
tried plugging in my old Microsoft Sidewinder controller. It read  
perfectly. This is OS X. So with that controller you get 8 trigger  
buttons, 1 select buttons, and d-pad with variable values. Perfect  
simple way as something to trigger events.


James

***
astroboy2520
Visit my blogs: http://triphop-universe.blogspot.com
http://videokilledtheradiostar.vox.com
Myspace: http://www.myspace.com/astroboy2520
Skype: astroboy2520
MSN: astroboy2520[at]sbcglobal.net



- Original Message 
From: Daniel Wilcox [EMAIL PROTECTED]
To: pd-list@iem.at
Sent: Tuesday, March 18, 2008 3:17:26 PM
Subject: [PD] Alternate Controllers

Try hacking some gamepads ... its cheap and easy.  Try [hid].

My project, robotcowboy, makes use of hacked gamepads and a custom  
joy - OSC daemon in Linux.  I'm getting ready

to release it soon, so if you use Linux you could try that.

For instance, I cut a gamepad up and wrapped it around my old  
trumpet.  pic1, pic2, a short pd session with it


There's lots of cool stuff you can for cheap.  Also, old console  
gamepads (psx, ps2, gamecube) are readily available and all you  
need is a usb converter.  I've found aftermarket playstation  
controllers the perfect hackables.


--
Dan Wilcox
danomatika
www.robotcowboy.com


-Inline Attachment Follows-

___
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






 



'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


Re: [PD] [PD-dev] adding pdpedia links to all help patches

2008-03-19 Thread Hans-Christoph Steiner

Sounds like a good idea, and a nice comprimise, definitely give it a  
shot.

.hc

On Mar 19, 2008, at 4:11 AM, Luke Iannini (pd) wrote:

 Hi,
 Maybe an idea would be a help-menu entry that says go to this patch's
 page in the Pdpedia, that detects the frontmost window's patch name
 (this must be possible, since [getpatchname] does it from within Pd).
 It could filter out the -help.pd part, and then it would work for
 object helpfiles as well as just open abstractions (and would make it
 easy to add Pdpedia text to an object, since visiting a nonexistent
 page in Pdpedia gives you the opportunity to edit it).

 I wouldn't mind trying to do this.

 Cheers
 Luke

 On Tue, Mar 18, 2008 at 5:33 PM, marius schebella
 [EMAIL PROTECTED] wrote:
 I really think this should be done by hand, and every pdpedia page  
 has
  to be fixed together with the help patch (right now all the
  texts/comments of a help patch were just dumped into the pdpedia  
 pages).
  then you can give the patches a good layout/design. and there  
 must be
  relevant additional information on the pdpedia pages for it to make
  sense to link to the pdpedia pages. pdpedia is not well mentained  
 right
  now...
  I would like to see link in pd-vanilla. but don't know if that  
 counts,
  because I also would like to see a lot of other objects in pd- 
 vanilla...
  marius.





  Hans-Christoph Steiner wrote:
 Hey,

 I want to add links to all of the help patches in SVN to their
 respective pdpedia pages.  Ideally, I could check these into  
 trunk so
 that they would become a permanent addition.  The problem is that  
 the
 link object is not included in pd-vanilla ([pddp/pddplink]).

 Who does not want this checked into trunk?

 .hc

  
 
 

  kill your television



 ___
 PD-dev mailing list
 [EMAIL PROTECTED]
 http://lists.puredata.info/listinfo/pd-dev



  ___
  PD-dev mailing list
  [EMAIL PROTECTED]
  http://lists.puredata.info/listinfo/pd-dev




 


If you are not part of the solution, you are part of the problem.



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


[PD] envelope vadsr2

2008-03-19 Thread Enrique Erne

hi all

i have a little envelope to share. it should be click-free when it gets 
re-triggered before the envelope finished. maybe this has already been done?


when it gets triggered it measures the actual value with snapshot~ and 
starts from the current value. this way it does not automatically begin 
with 0.


comments welcome.

cheers eni
#N canvas 346 22 766 505 10;
#X obj 216 455 switch~;
#X obj 27 13 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1 1
;
#X obj 27 211 metro 1451.25;
#X floatatom 281 190 5 0 0 0 attack - -;
#X floatatom 331 220 5 0 0 0 decay - -;
#X floatatom 381 250 5 0 0 0 sustain - -;
#X floatatom 431 280 5 0 0 0 release - -;
#X obj 93 455 tabwrite~ vadsr;
#N canvas 0 22 450 300 (subpatch) 0;
#X array vadsr 11000 float 0;
#X coords 0 1 10999 0 500 100 1;
#X restore 176 25 graph;
#X obj 265 436 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 1
1;
#X obj 393 164 loadbang;
#X msg 431 249 261;
#X floatatom 511 346 5 0 0 0 - - -;
#X msg 511 316 set 11025;
#X msg 511 376 \; vadsr resize \$1;
#X obj 123 375 pack 51 87 31 261;
#X obj 123 345 f 51;
#X obj 102 179 * 64;
#X obj 102 149 / 44.1;
#X msg 102 119 1000;
#X floatatom 110 244 5 0 0 0 - - -;
#X msg 281 159 31;
#X obj 77 264 del 80;
#X msg 331 187 35;
#X msg 381 219 65;
#X obj 123 425 vadsr2 3 4 90 16;
#X text 47 12 a) start triggering;
#X text 71 101 blockligned;
#X text 425 193 b) play with the adsr parameter;
#X text 462 410 c) adjust tablesize to adsr duration for better visualization
;
#X text 267 454 optional switch to save cpu;
#X text 90 280 retriggering is clickfree;
#X text 130 402 attack(ms) decay(ms) sustain(%) release(ms);
#X connect 1 0 2 0;
#X connect 2 0 7 0;
#X connect 2 0 16 0;
#X connect 2 0 22 0;
#X connect 3 0 16 1;
#X connect 4 0 15 1;
#X connect 5 0 15 2;
#X connect 6 0 15 3;
#X connect 10 0 21 0;
#X connect 10 0 23 0;
#X connect 10 0 24 0;
#X connect 10 0 11 0;
#X connect 10 0 13 0;
#X connect 10 0 19 0;
#X connect 11 0 6 0;
#X connect 12 0 14 0;
#X connect 13 0 12 0;
#X connect 15 0 25 0;
#X connect 16 0 15 0;
#X connect 17 0 2 1;
#X connect 18 0 17 0;
#X connect 19 0 18 0;
#X connect 20 0 22 1;
#X connect 21 0 3 0;
#X connect 23 0 4 0;
#X connect 24 0 5 0;
#X connect 25 0 7 0;
#X connect 25 1 0 0;
#X connect 25 1 9 0;
#N canvas 18 22 535 739 10;
#X obj 147 545 vline~;
#X obj 29 485 vline~;
#X obj 147 575 dbtorms~;
#X obj 29 515 dbtorms~;
#X obj 13 575 -~;
#X obj 13 545 sig~ 1;
#X obj 152 232 rmstodb;
#X obj 86 172 max 0.1;
#X obj 333 186 max 0.1;
#X obj 145 279 t b f;
#X obj 29 22 inlet;
#X obj 84 697 outlet~;
#X obj 375 622 outlet;
#X obj 375 562 f 1;
#X obj 415 562 f 0;
#X obj 415 532 del 500;
#X msg 415 502 stop;
#X obj 376 472 t b b b;
#X text 39 379 attack decay sustain hold release;
#X obj 29 405 t a a b;
#X obj 152 202 * 0.01;
#X obj 152 172 clip 0 100;
#X obj 464 443 t b f;
#X obj 454 472 + 16;
#X obj 125 309 + 4;
#X obj 29 112 unpack f f f f;
#X obj 29 202 t a a;
#X text 79 22 attack(ms) decay(ms) sustain(%) release(ms);
#X obj 29 355 pack f f f f f;
#X obj 49 82 list append \$1 \$2 \$3 \$4;
#X obj 49 52 loadbang;
#X obj 375 592 change 0;
#X obj 29 172 max 0;
#X msg 29 455 60 \$1 0 \, 100 0 \$1;
#X obj 147 485 t a b;
#X msg 147 515 0 \, 100 0 \$1 \, \$3 \$2 \$1 \, 0 \$5 \$4;
#X obj 214 613 snapshot~;
#X obj 214 673 -;
#X obj 214 703 rmstodb;
#X msg 214 643 1 \$1;
#X msg 397 22 version 2.0.0;
#X connect 0 0 2 0;
#X connect 1 0 3 0;
#X connect 2 0 11 0;
#X connect 2 0 36 0;
#X connect 3 0 4 1;
#X connect 4 0 11 0;
#X connect 4 0 36 0;
#X connect 5 0 4 0;
#X connect 6 0 28 2;
#X connect 7 0 9 0;
#X connect 7 0 28 1;
#X connect 8 0 22 0;
#X connect 8 0 28 4;
#X connect 9 0 24 0;
#X connect 9 1 24 1;
#X connect 10 0 25 0;
#X connect 13 0 31 0;
#X connect 14 0 31 0;
#X connect 15 0 14 0;
#X connect 16 0 15 0;
#X connect 17 0 15 0;
#X connect 17 1 13 0;
#X connect 17 2 16 0;
#X connect 19 0 33 0;
#X connect 19 1 34 0;
#X connect 19 2 17 0;
#X connect 20 0 6 0;
#X connect 21 0 20 0;
#X connect 22 0 23 0;
#X connect 22 1 23 1;
#X connect 23 0 15 1;
#X connect 24 0 23 0;
#X connect 24 0 28 3;
#X connect 25 0 32 0;
#X connect 25 1 7 0;
#X connect 25 2 21 0;
#X connect 25 3 8 0;
#X connect 26 0 28 0;
#X connect 26 1 24 0;
#X connect 28 0 19 0;
#X connect 29 0 25 0;
#X connect 30 0 29 0;
#X connect 31 0 12 0;
#X connect 32 0 26 0;
#X connect 33 0 1 0;
#X connect 34 0 35 0;
#X connect 34 1 36 0;
#X connect 35 0 0 0;
#X connect 36 0 39 0;
#X connect 37 0 38 0;
#X connect 38 0 1 0;
#X connect 39 0 37 0;
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] [OT] hdsp pcmcia and macbook pro

2008-03-19 Thread marius schebella
hey,
I think the combination macbook pro, hdsp multiface and not willing to
spend money for the hdspe express card (EUR 330+) is rare. but I just
got a duel-systems express card 2 pcmcia adapter (100$), and everything 
seems to work. there is still a bug with os x though, you have to 
restart when you pull off the adaper and want to reconnect. duel systems 
promises to fix this, but who knows when.
marius.


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


Re: [PD] help with widgets

2008-03-19 Thread Patrice Colet
  Hi, when we save a change with in the abstraction containing the 
widget, dollarsign inside de widget object is replaced by the value 
given to the abstraction, the only way I've found to correct this is 
using a text editor or a command line editor and replace the given 
dollarsign during saving by the original name that would be: \$0 or \$1, 
or \$n, backslash is quite important in here.


robcanning a écrit :
 hello,
 
 i have just started using toxy widgets and need one basic bit of help:
 
 i create a widget:
 widget popup menuename$1
 
 when this is created it is created with the abstractions $1argument i.e. 
 the widget is now called menuename123 instead of menuename$1
 
 i want to create an abstraction with a variable widget name
 how can i send a message to change the name of the widget?
 
 thanks
 
 rob c
 
 ___
 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


[PD] [PD-announce] Fw: SIMULTAN04 Festival - Screening - Call for entry

2008-03-19 Thread Levente Kozma | simultan

---
SIMULTAN04 Festival - Screening - Call for entry | www.simultan.org 
---
SIMULTAN04 - Video and Media Arts Festival will take place in Timisoara, Romania
between May 22nd -24th 2008.

Under the theme Temporary Tactics, Simultan04 explores a conflict situation, 
a difficult cohabitation between the independent audio-visual works and the 
cultural, 
social and political context in which they are born.
Temporary Tactics wishes to highlight time and space connected speculative 
situations, 
the practice of acting and reacting, of making and creating, 
in the moment and in response to the stimulus of one's immediate environment.
---
SIMULTAN04 is open for submissions of innovative works which that make use of 
technology 
in a creative, ingenious way or are based on a peculiar, unusual story.
The video section is open to all video artists and not only, who can apply with 
narratives, 
experimental videos, animations, vj-ing movies and motion graphics.

Those interested may apply with a maximum number of 2 video works, 
each having a duration that must not exceed 3 minutes.

Terms and conditions, technical details, application form here:
http://www.simultan.org/en/2008/callforentry.htm

The deadline for the submission of works and applications is April 10th, 2008 
(postmark)

After the event, a DVD/catalogue will be published, each of the admitted 
participants 
will receive a DVD/catalogue by the end of 2008.

no application fee required!

For additional information please contact: Levente Kozma
email: simultan[at]simultan.org, tel: +40-740.300.806

for more details please visit www.simultan.org 

---
a video review of SIMULTAN03 
www.youtube.com/simultanfestival  
www.myspace.com/simultanfestival 
---
[ please distribute to interested people | apologies for any duplicates ]___
PD-announce mailing list
[EMAIL PROTECTED]
http://lists.puredata.info/listinfo/pd-announce
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] More about PD state-saving

2008-03-19 Thread Phil Stone
Hi Luke, Frank, and list.

Luke Iannini (pd) wrote:

 Basically the original presentation of RRADical is organized so that
 Polaroid can be used to copy/paste or save/load settings  from one
 instance of a module to another.  So it is like a big Moog Modular,
 where the settings of one 901 oscillator can be copied to a second 901
 oscillator, or a 911 envelope to second 911 envelope.  And then, to
 save the whole rack of modules at once, you use [careGUI].

 What I describe is a bit different; what I wanted was more like
 combining 3 oscillators and a filter to get a Minimoog, and then using
 Polaroid to copy the settings of all 4 modules to a second Minimoog,
 or using [careGUI] to save both of them at once.
   

 I haven't gotten to thinking about Memento's preset system yet (I tend
 to just use preset 0 and the filesystem).

That is a clever way to get around the problem (of accessing individual 
presets), but it's a bit of a shame when you consider that the 
underlying storage, [pool], is very well-designed to handle arbitrary 
hierarchies, yet you have to use the filesystem (with its inherent 
disadvantages...e.g. glitching during disk access) with a shallow 
[pool] to achieve the desired functionality.

With the current Memento setup, one can have an arbitrary number of 
Minimoog presets, and switching them is as easy as sending a new 
substate message via OSC (and it all happens without any filesystem 
access).  What one *can't* do is individually *access* those presets 
(e.g., to save them individually, or to cut/copy/paste them), because 
Memento's hierarchy is not organized that way.

There's nothing magical about substate in rradical/memento -- it's 
just mapped to a relative directory change message for [pool].  What 
if the current hierarchy were inverted, so that what is now called 
substate became superstate (corresponding to a preset, in a 
modular-synth vocabulary), with [originator]-spawned parameter groupings 
(the current system's directory roots) underneath?

Illustrating this desired [pool] directory structure with your Minimoog 
analogy:

Preset 1-- this is the superstate
VCO -- this is the [originator]-delineated module
   freq. 2000   --  these are key/value pairs (parameters)
   wave saw
   (etc.)
VCF -- another [originator]-delineated module
   cutoff 5000
   q 0.05
   (etc.)
ETC.-- (other modules)

Preset 2-- superstate 2
VCO -- [originator]-delineated module
   freq. 2000   -- key/value pairs (parameters)
   wave saw
   (etc.)
VCF -- another [originator]-delineated module
   cutoff 2000
   q 0.10
   (etc.)
ETC.


Going one step further, why not an ultimate flexibility for the upper 
hierarchy?  Right now, the [originator] in each logical module functions 
as the main architectural building block of Memento, and sits 
accordingly at the top of the hierarchy.  What if a (superstate) 
hierarchy list were passed as an argument to [originator], which tells 
it where to store its underlying data in [pool]?


Imagine this hierarchy (perhaps a bit fanciful, but not inconceivable):

2008
   July
   Carnegie_Hall
   Minimoog
  Preset_12
 Module (here lies the current top of the Memento 
hiearchy, created by [originator])
key-value pairs


If [originator] could accept as an input the list {2008, July, 
Carnegie_Hall, Minimoog, Preset_12} -- it could store its data at that 
level of a [pool] hierarchy.  It would then be possible to save/restore, 
cut/copy/paste the tree below *any* node on the hierarchy, and it would 
be organized in a way that makes more sense.


Of course, it's easy to theorize about this; perhaps not so easy to 
implement!  Thoughts?


Phil Stone
www.pkstonemusic.com
 
   

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