| I also think this is a fantastic idea.
Although in the original email it was mentioned to be implementing
these systems using OSC, I feel that it's important not to rule out the
possibility of using the newly added cstclsh interpreter for these
types of network collaboration.
The reason this is suggested is because of Victor's recent examples
using the [netsend] object in Pd to communicate with the TCL
interpreter.
Right here, you can already implement your chat idea (colored syntax,
buttons, etc) using TCP or UDP (I believe OSC only supports one of
these, at present) but you enjoy the flexibility of working with the
TCL / Wish libraries.
Even though alternate methods are suggested as far as implementing some
kind of chat or "shared cyberspace", it would still seem imperative to
be using OSC as control for the *musical* elements.
-David
On Nov 11, 2005, at 5:02 AM, Oeyvind Brandtsegg wrote:
> I like this idea, and I think it might open up new possibilities for
> collaboration.
> Great.
> Oeyvind
>
>> From: Steven Yi [stevenyi@gmail.com]
>> Sent: 2005-11-11 06:21:36 CET
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] API Testing Idea
>>
>> Hi All,
>>
>> I had sort of random idea just now for a collaborative music making
>> program that might be an interesting test of the API. The idea is
>> that:
>>
>> -a host program on one's computer could network with other hosts
>> -each user runs the host and has their own directory sandbox that
>> hold's a CSD and any relevant files
>> -you could connect to rooms of people to perform with, when you do,
>> everyone gets a copy of your sandbox directory, including csd and any
>> relevant files within it
>> -for every user in the sandbox, a Csound instance would be created in
>> the local host, each running all CSD's in the sandbox in realtime, the
>> host collecting the audio data and mixing together
>> -a performance interface would generate OSC data, sent to the host;
>> your own data would be routed to your instance of csound running on
>> your own CSD, and your performance data would also be broadcast to
>> other hosts and routed to their csound instance running your csd
>> -users could hot swap in new CSD's to be updated live (would require
>> stopping and restarting the specific CSound instance associated with
>> that user once that CSD is received)
>> -All CSD's in current room could be view by everyone else (useful for
>> learning new techniques from everyone)
>>
>> Usages:
>> -collaborative performance
>> -general collaborative music making
>> -Csound study sessions
>> -Remote Csound teaching
>>
>> For example, let's say for an online meeting group you could get
>> together and experiment with a synthesis technique, or perhaps work on
>> sample manipulation ideas. Maybe a room sandbox could be a part of it
>> too so that all users in the room could share samples. So maybe one
>> person says "Hey, I just got a great sound, check this out" and
>> everyone could hear it right then, as well as see the user's CSD.
>>
>> Just a random thought I guess (I like the idea of casual performance
>> of art music and general music making with friends). It's perhaps not
>> very efficient to have that many instances of Csound running if it's a
>> big online room, but since each instance is isolated from talking to
>> another instance, the instances could be pushed onto separate node
>> computers which would communicate to the local host and mix audio with
>> it too. I imagine would help stress csound's abilities a bit and
>> could expose some places where Csound might need work too.
>>
>> Doing network code is fairly easy with both Python and Java, and OSC
>> libraries exist for both of those platforms, so those might be good
>> candidates for trying something like this out.
>>
>> Any thoughts?
>> steven |