Aah, ok - I'm on the dev list now. Here is the email that I sent directly to guenter before:

My external can scan for given input devices in linux and spit out the device file descriptor (i.e. /dev/input/event5) so that a particular device can be automatically connected to a patch when it's plugged in, or when the patch is started - rather than having to hard-code the descriptor - so it allows for a kind of "plug-and-play" for input devices. I've been using it with hans-christoph's linuxjoystick in order to avoid hard-coding the file descriptor, meaning that patch can always start up and be "live" regardless of what order devices were plugged in, etc.

thanks, -David

Mathieu Bouchard wrote:

On Fri, 28 Apr 2006 geiger@xdv.org wrote:

...

Quoting David Merrill dmerrill@media.mit.edu:

...

hello Guenter - Can I be given developer permissions for the pure-data CVS? I have a new external that I'd like to share with the rest of the community. thanks!

I am forwarding your request to the pd developers list, as this is the place where we normaly discuss additions. Maybe you can also explain what your external does, in order to not duplicat functionality.

Also, being subscribed to pd-dev@iem.at is a very good idea.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

Sure, I don't mind introducing myself -I wouldn't want there to be a double-standard..

Hi everyone, I'm David Merrill. My computer-music-related interests revolve around the design and construction of new musical instruments, and more broadly, human-computer interaction. I've been working with pd since about 2001, when I was a masters student in computer science at Stanford doing coursework at CCRMA, the university's computer-music center. Since then, I have built a number of projects using pd, including:

- a signal external in C that allows parameterized 'morphing' between a sine wave and a square wave, allowing for nice "rounded corners" square waves anywhere in-between.

- a digital, computer-vision-based, rotating-platter "music box" inspired midi instrument. http://web.media.mit.edu/~dmerrill/cool.html

- a singing-on-pitch training program that used Miller's [fiddle~] object to track vocal singing pitch and a haptic backpack to deliver vibrotactile feedback to help a singer correct in realtime. http://web.media.mit.edu/~dmerrill/tactile_performance.html

- an "attentional mixer" that ramps volume levels of different audio streams up and down based on the user's facial orientation towards various physical objects (.MOV video) http://web.media.mit.edu/~dmerrill/images/AM_web_512kbsec.mov

- an "adaptive music controller" - a musical instrument that learns to map a person's custom gestures and continuous manipulations to triggered sounds and continuous effect parameters http://web.media.mit.edu/~dmerrill/adaptive_controller.html

- a joystick-based voice sampler/triggerer/looper/shifter/scrubber sound play application.

..and I'm sure there are more small, one-off projects that I am forgetting (like my 7:30AM low-passed white noise program that hacked quickly and turned up LOUD to muffle the jackhammer that had unkindly started up outside my window in Boston). I am a competent C and Tcl/Tk programmer, though most of my time in PD is spent at the patch-creation level (fortunately).

My current pd-related project is to build a 'road-hardened', 'gig-ready' pd-based portable audio-processing system that is extremely robust and 'plug-and-play' in the sense that you can plug in a controller and it begins to work immediately. http://web.media.mit.edu/~dmerrill/audiopint.html

Anyway, the reason I wanted to be a developer on the CVS is that I have built an external that can scan for input devices in linux and output the file descriptor (i.e. /dev/input/event5), so that the device(s) can be dynamically loaded and their location doesn't have to be hard-coded into the patch. The hardware scan can happen as the result of a [bang], or can be triggered when new hardware (i.e. a USB joystick, for example) is plugged into the system. I imagine that this external will be useful to people (a) as-is, for making their patches more robust against accidental un-plugging/re-plugging or the order in which devices are plugged in, and (b) as an example of how to use the linux hardware abstraction layer (hal) and dbus to scanning for devices more generally, that can be modified and used in many contexts.

well, that's my story - did I pass the test? ;) best regards, -David Merrill

David Plans Casal wrote:

On 29 Apr 2006, at 02:41, carmen wrote:

...

...

someuser@media.mit.edu wrote:

...

I am forwarding your request to the pd developers list, as this is the place where we normaly discuss additions. Maybe you can also explain what your external does, in order to not duplicat functionality.

usually the new developers are asked to offer 'a bit about themself' and/or 'what they're doing with pd'. is this request waived for .edu addresses? perhaps only certain .edu addresses?

IMO, this isn't just a 'validation' process, but a way to get to know incoming developers and their interests, reduce possible duplication of efforts, etc., so it's a good idea, and we shouldn't wave it for education institutions necessarily...

d

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev