Page 1 of 1

Puredata and internet interactive music

Posted: Thu Oct 26, 2006 5:06 pm
by knotkranky
Ok, maybe someone has posted this stuff already. I haven't seen anything here or can find anything with the search. But I am interested in realtime (or very close to) web music interaction. Online jamming if you will. Anybody experienced netpd or have programmed with Puredata? or with their chat.pd or creator.pd? I don't think I've heard Max or Bidule having the same net abilities. Would be cool to use this with live's generative side. Could this work with netpd's 4kb net buffer limit? I'm a newb with this stuff. Thanks.

http://createdigitalmusic.com/2006/10/2 ... in-a-cage/


what is netpd?

netpd is a project based on the software puredata. its intention is to create an environment for electronic musicians and give them the opportunity to jam with each other in realtime, connected over the internet or a LAN.

the idea of netpd

netpd does not provide any software which produces sound, but an environment to 'share' client created patches and broadcast control data. it is important to the idea of netpd not to prescribe a way how to make music. for this reason, the users of netpd are asked to build their own patches and to play them in netpd, which hopefully leads to a big variety of styles of creating music (or noise).

how does netpd work?

netpd has the structure of a client-server-system. on the client side, mainly two patches are important in order to use netpd:

chat.pd
this patch establishes the connection to the netpd-server (netpd.org:3025). all data from the the custom netpd-patches (instruments, synths...) are sent by chat.pd to the server. the server broadcasts all data received from every client to all connected clients. the way of one event (pd-message from a toggle, slider...) is shown here:
custom netpd-patch >> chat.pd >> netpd-server >> chat.pd >> custom netpd-patch
as the name says, chat.pd is also a very simple chat-client. this feature has been built-in, since it is not possible to make music without communication.

creator.pd
creator.pd is used to upload the custom netpd-patches to all other connected clients netpd/patches-directory. only if all clients have opened the same custom netpd-patches, all will hear the same sound. you can share patches with creator, but NOT audio files. this limitation means, that only generative music can be made with netpd, but not audio-sample based music. even if audio-data is saved within the patch in a table, it would not be possible to distribute this patch with creator.pd because of the limited buffer size (4kB) of [netclient] and [netserver].

in order to make it as easy as possible to create your own custom netpd-patches or to make an existing patch easily 'netpd-able', the netpd-package contains a few abstraction, which do the broadcasting part for different data-types (floats, symbols, lists, arrays). -> see the help-files

a short tutorial about how to create a custom netpd-patch is included.

more info about howto use netpd. http://www.netpd.org/Howto

other webresources

article about netpd:
http://www.neural.it/nnews/netpde.htm
http://www.neural.it/nnews/netpd.htm (italian version)

short introduction into netpd (french):
http://www.linuxmao.org/tikiwiki/tiki-i ... page=Netpd
article on createdigitalmusic.com: http://createdigitalmusic.com/2006/10/2 ... #more-1689

Posted: Thu Oct 26, 2006 10:09 pm
by nolus
I've been using PD for controller mapping jobs. But I'm a bit disapointed because it adds a lot of latency to midi messages. better for some tasks than others, I've yet to get into using it to generate audio. To be honest programing PD is a bit obtuse and can eat up all your time if your not careful. It takes a long time to master it properly (not that I have)

This project looks interesting though, I'll definitely check it out when I get the time. I've been made redundant at work so I'll have plenty of time on my hands in the new year.

I get the impression there are not that many PD users round here though, the occasional PD related posts tend to sink like a stone.

Posted: Thu Oct 26, 2006 10:35 pm
by leonard
never tried it, but supercollider would be awesome for this sort of thing. i've often toyed with thoughts of setting up a web interface which sends a html form to a java server/servlets, which could then communicate via tcp/udp to a waiting supercollider server, via the javaosc, or maybe straight through a java applet via swingosc, not sure, but entirely doable i'm sure. i'm far too dumba nd lazy to put any work into it myself of course, but someone should.

Posted: Thu Oct 26, 2006 10:51 pm
by Machinate
leonard wrote:never tried it, but supercollider would be awesome for this sort of thing. i've often toyed with thoughts of setting up a web interface which sends a html form to a java server/servlets, which could then communicate via tcp/udp to a waiting supercollider server, via the javaosc, or maybe straight through a java applet via swingosc, not sure, but entirely doable i'm sure. i'm far too dumba nd lazy to put any work into it myself of course, but someone should.
Plenty of people do that - with PD, with SC, with Max, etc. I saw a great jitter patch that downloaded random pictures from the internet and sequenced them ::)

Posted: Fri Oct 27, 2006 8:13 am
by knotkranky
Thanks fellas. I would like to experiment sending simple cc's to a friend with an identical session in live with minimal fuss. Not an over bloated program that I would have to wade through for a simple task. Though maybe that's what's required with the apps you've mentioned. What's the best thing to look at to start experimenting? How can I simply fire clips n scenes remotely over the net?

Posted: Fri Oct 27, 2006 12:37 pm
by leonard
not sure, with vst's/au's (your on window, right?) you'd needd sometihign that'll convert your midi messages to a tcp/udp info, then back again on the client. maybe the vvvv thing someone poested before that does it, not sure. i'm not feelin the thought process right now, probably wont soon...

(your best bet is of course to program something yourself, ..., ,)

:roll: :wink: :idea: :?: :arrow: :idea: :twisted: :P 8)

Posted: Fri Oct 27, 2006 1:21 pm
by nolus
it should be reasonably easy create a PD patch to send midi to another computer via tcp/ip if that's all you want to do. I'll have a go at it when I get home tonight.

Posted: Fri Oct 27, 2006 1:30 pm
by Nixon
Sounds promising! I just got introduced in pd and am spending some time macking patches to complement live. Is this is running please let me know!

cheers

Posted: Fri Oct 27, 2006 4:26 pm
by knotkranky
yeah, I'm gaining some interest in this. I'm not a code or it guy, though I've been doing some more complicated html than usual. No big deal. But i'm a musician at heart and I can only learn at I putts around with 101 experiments. Total newb here. I would be thrilled to pull off a simple remote message to live. I'm on OSX and so is my friend in another state. Midi message via udp, ok. I just want to be using the simplest apps. Pd does seem obtuse. But maybe via ip is a simpler way to go. A friendly interface would be nice. Would love to know what you guys are pulling off. Thanx fellas, Cheers.

Posted: Sun Oct 29, 2006 9:38 am
by nolus
OK I made these two little patches to demonstrate the principal.

Run the patch with the netsend on one machine and the patch with netreceive on the other

where it says "localhost" you can put the ip address of the remote computer, 3000 is the port number (as used in the PD help patch), I think you can use other port numbers but 3000 worked for me.

Click where it says connect to start the connection, click disconnect to end it.

if data is going through correctly then the two little indicators should flash.

This patch only sends controller data. I was trying to create a patch that would send different event types to different outputs but the netreceive object doesn't seem to work quite how it is described in the PD help so I need to rethink my idea.

I'll definitely work on this further but I'm rather busy at the moment so It might have to wait a while.

Image

Heres the code for netsender.pd

Code: Select all

#N canvas 80 321 454 304 12;
#X obj 195 214 netsend;
#X msg 5 120 connect localhost 3000;
#X msg 7 187 disconnect;
#X floatatom 195 252 0 0 0 0 - - -;
#X text 0 175;
#X msg 195 172 send \$1 \$2 \$3;
#X obj 195 120 pack 0 0 0;
#X obj 215 60 ctlin;
#X obj 192 63 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
#X connect 2 0 0 0;
#X connect 5 0 0 0;
#X connect 6 0 5 0;
#X connect 7 0 6 0;
#X connect 7 0 8 0;
#X connect 7 1 6 1;
#X connect 7 2 6 2;
and netreceiver.pd

Code: Select all

#N canvas 580 321 454 304 12;
#X obj 57 49 netreceive 3000;
#X obj 81 168 ctlout;
#X obj 57 113 unpack 0 0 0;
#X floatatom 172 87 0 0 0 0 - - -;
#X obj 57 171 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1
-1;
#X connect 0 0 2 0;
#X connect 0 1 3 0;
#X connect 2 0 1 0;
#X connect 2 0 4 0;
#X connect 2 1 1 1;
#X connect 2 2 1 2;

Posted: Sun Oct 29, 2006 10:42 am
by kronk
there's also currently a tutorial on this topic on cycling's website (with a max/msp/jitter focus obviously):

http://www.cycling74.com/story/2006/10/23/104657/91

maybe some of this stuff is also applicable to pd...

Posted: Sun Oct 29, 2006 12:11 pm
by Machinate
yeah, it's almost too friggin easy with maxhole, hehe. You just open the help file for mxj.maxhole on both machines, and then it works :)

Posted: Sun Oct 29, 2006 6:30 pm
by knotkranky
Appreciate it, thanks guys. Nolus, thanks for the pd steps and code, will do. kronk, Machinate, same for maxhole/jitter. I'm gonna throw a few things through the apps next weekend, just because I haven't before. But of course i'll be thinking about the musicality in short order. Simplicity aside and moving past ip to udp. Do the apps begin to show differences in closing the gap of responsiveness or is it purely connection services at that point. Meaning, is it possible to maintain a consistent delay time or is it swimming around too much? Is this the advantage with udp? I would imagine shifting bottlenecks are the rub and why sequencing images are more satisfying. Please pardon the newb, but having identical sessions and audio in live and simply firing clips over the net within single bar quantization time frame is enough within the shifting net delay times? So, 120 bpm being a 2 second window to fire a clip. Enough net error hedge space? Cheers

Posted: Mon Oct 30, 2006 7:43 am
by nolus
if you look at the help patches for netsend an netreceive. it shows you how to open a UDP connection, it's just an extra parameter.