Hi kids,
I finally finished a more or less stable and official release of the 'hidin' object for Pd on Windows. It allows to read in data from HID USB devices like gamepads and joysticks on Windows (and only Windows). Does not work with mice and keyboards due to some access restrictions on Windows. I just tested it with my gamepad and it seems to work. Hope it works with other devices too... if not: install Linux!
Get it here: http://www.akustische-kunst.org/puredata/hidin1.0test1.zip
best, Olaf (who wasn't there)
a certain Olaf Matthes olaf.matthes@gmx.de wrote: install Linux!
;-)
--------___________________________
hear me here: http://www.mprims.tk
Hey, this is good actually. I am knee deep in writing a cross-platform
HID I/O object and I am working now MacOS X with GNU/Linux to follow.
But I looked at DirectX and it looked ugly, so I decided not to mess
with it.
Its going to be structured very similarly to my [linuxevent] object, with the addition of taking input from the inlet in order to control haptic feedback, LEDs, etc. I chose to use the Linux scheme of representing events (time, type, code, and value) because its the cleanest after looking at libSDL, DirectX, Darwin HID Manager, USB HID, and Linux input event. The USB HID style stuff (i.e. DirectX and HID Manager) just seems needlessly complicated. Also the Linux input event headers are all GNU GPL, so I can easily include them, unlike DirectX or HID Manager.
Also, I just tested [hidin] with my Logitech Wingman Force 3D. I used
the PureData-0.37-2003.10.19.exe from puredata.org on WinXP. I got
input from the joystick, but it was strange. This may be because its a
force feedback joystick and I didn't install a specific driver for it.
Here's what was happening: all three axes had this format of data:
center
|- left end | right end -| 64..................127 0 0 0 0 0 0 0 0 0 0 0 0
So 127 was the center, in one direction, it went down to 64, everything the other direction was zero.
.hc
On Oct 14, 2004, at 6:54 PM, Olaf Matthes wrote:
Hi kids,
I finally finished a more or less stable and official release of the 'hidin' object for Pd on Windows. It allows to read in data from HID USB devices like gamepads and joysticks on Windows (and only Windows). Does not work with mice and keyboards due to some access restrictions on Windows. I just tested it with my gamepad and it seems to work. Hope it works with other devices too... if not: install Linux!
Get it here: http://www.akustische-kunst.org/puredata/hidin1.0test1.zip
best, Olaf (who wasn't there)
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
http://at.or.at/hans/
Is this possible with pd?
On Oct 15, 2004, at 3:49 PM, siggmuss wrote:
Is this possible with pd?
Anyone what know the latency of a PCI-Express CPU->GPU->CPU transaction is? I know that it's highly unlikely to do with reasonable block sizes over AGP because the read is so damn slow. Offline rendering would be a no-brainer for things like huge convolutions, FFT and FIR operations, but what about real-time low latency situations?
cgc
is there any way of wrapping a lot of geos in gem? i want to iterate complex structures made with a lot of geos and i was wondering if there is an elegant way to do this instead of using lots of "repeat" objects. It would be nice to have just one "repeat" object per structure. Any hint?
siggmus
smells very much like 'the wheel of reincarnation'. http://catb.org/~esr/jargon/html/W/wheel-of-reincarnation.html
but definitely cool though. it should be possible in pd through pf soon (maybe in a year ;) but cards are not really optimized to read back from graphics memory i think.
On Fri, Oct 15, 2004 at 01:49:38PM -0700, siggmuss wrote:
Is this possible with pd?
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
smells very much like 'the wheel of reincarnation'. http://catb.org/~esr/jargon/html/W/wheel-of-reincarnation.html but definitely cool though. it should be possible in pd through pf soon (maybe in a year ;) but cards are not really optimized to read back from graphics memory i think.
Is this possible with pd? http://www.bionicfx.com/
-Realtime seems to be a problem, because things have to be translated from video into audio and back and forth:
- Individual audio samples are isolated from the audio stream
- Samples are transformed into video data elements and structures
- Appropriate pixel shader application loaded on the GPU
- Secondary audio samples are converted to video textures and loaded on
video card 5. AVEX data sent to the GPU for processing 6. Iterative processes perform functions and read and write results to textures 7. Final output of shaded pixels sent to off-screen video buffers 8. Video data is retrieved and decoded into audio
AvS
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
` |Schreck Ensemble . . . . . . . . . . . . . . . . . . . . +
` |# -laboratory for live electro-acoustic music- # |
| http://www.schreck.nl/ |
| http://www.xs4all.nl/~schreck/ |
` *===========================================================++
` |Compositions http://www.xs4all.nl/~schreck/html/compo.html |
` |Samples http://www.xs4all.nl/~schreck/html/samp.html |
` |Patches http://www.xs4all.nl/~schreck/html/pat.html |
` |Videos http://www.xs4all.nl/~schreck/html/video.html |
` |Scores http://www.xs4all.nl/~schreck/html/scores.html |
*===========================================================++
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .....................................................................
-
Arie van Schutterhoef -
chris clepper -
Hans-Christoph Steiner -
mik -
Olaf Matthes -
siggmuss -
Tom Schouten