Hallo! You could use Plone, which already has many communication-tools, and write an additional product in python for it ... (where you could in example use pd or anything else and stream with an icecast2 server ...) a little howto you can make something (Plone and communication with pd ...) is here: http://pdradio.iem.at/howto (of course not that advanced as you want it ... ;) LG Georg

Frank Barknecht escribe: I'd be very glad helping in such a project up to my knowledge! Cordially, Ismael -- mí, myself et moi http://lamediahostia.blogspot.com/ http://www.flickr.com/photos/ivalladt/

just out of interest, if you have 2 people on opposite sides of the globe both with broadband connections....how much latency are you looking at if you send (control) data by OSC ??? is internet-based jamming still science fiction?

I don't think the requirements are quite defined here yet, and I see the term 'latency' taking on dual meaning and creating some confusion. Firs of all, what are we talking about with collaboration? Real-Time prcessing/recording, or the assembly and editing of audio tracks in a shared environment? One of the biggest problems here is timing. When dealing with music, notes have values in relation to beats and time, ie 4 beats per measure, etc. In order for everything to be synchronized, everyone must first agree to the tempo (beats per minute). There are techniques to do this in a localized system, SMPTE, or MIDI Clock, are two examples. The challenge is to achieve this synchronization, in real time, and compensate for the distance latency. The other latency problem is with sound generation. We all know the challenges of getting things synchronized in our local machines, so this poses an even greater challenge by adding the time latency related physical distance. The vision I came up with for such a system is a combination of a file sharing (GNUTella, SAMBA, or NFS?) and clustering (Beowolf). Sharing the files and sharing in the processing will get everybody involved on the same page because time could be negotiated to the machine with the greatest time latency. I belive the pieces of the collaboration aspect exist; people smarter than me need to identify the pieces and assemble that puzzle. Because latency relates to both processing time and physical distance, I do not see how this could happen in real-time. Again, somebody smarter than me would have to solve this problem. --- Paul Winkler <pw_lists(a)slinkp.com> wrote: if __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On Sat, Mar 04, 2006 at 02:44:43AM +0900, hard off wrote: ninjam is an approach to transport audio... http://www.ninjam.com there is a jackified client here: http://galan.sf.net/ninjam-with-jack-0.02.tar.bz2 and some amd64 patches can be found here: http://www.cockos.com/forum/showthread.php?t=159 there is a jacked client here: i doubt, that its possible, to transport control data in realtime, so i think its ok to do it for audio with exactly one bar of latency. the one bar latency makes everything appear in time. while this is quite complicated for real instrument jamming (requires some skill from the player) in my opinion its perfect for editing sequencer loops in a colaboration. the transmitted audio data is ogg compressed, so every client needs to record his own audio to wav and everything would need to be merged again. (there is no software to do that yet...) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language