I have no desire to reinvent any wheeels (and inter-Csound comms was not my 
suggestion anyway); but I am interested to know what this particualar wheel can 
do, and whether the host app (e.g. Csound VST host driving csound thru the API) 
need to know about (or control? facilitate?) this relationship at all. Is there 
a convention for deciding what port numbers to use? Does the top-level user have 
any interest (in the legal sense) in this decision?  Who ensures that port 
numbers are unique?


Richard Dobson




Michael Gogins wrote:
> No difference except sockets are more generic. I was being a tad facetious.
> 
> My real take on this kind of thing is, don't reinvent the wheel. That's why
> I put a whole programming language with oodles of libraries (Python) into
> CsoundVST. Csound should focus on sound.
> 

No difference except sockets are more generic. I was being a tad facetious.

My real take on this kind of thing is, don't reinvent the wheel. That's why
I put a whole programming language with oodles of libraries (Python) into
CsoundVST. Csound should focus on sound.

----- Original Message ----- 
From: "Richard Dobson" 
To: "Csound Developers Discussion List" 
Sent: Thursday, May 06, 2004 8:35 PM
Subject: [CSOUND-DEV:4590] Re: Bus design


> Well, Ok, I guess! Presumably there would be no need to provide socket
support
> via the API, for example. It must surely depend on what people want to
transmit.
> Would socket opcodes work for synchronous krate/arate signals?
>
> What would make using sockets different from using OSC calls?
>
>
> Richard Dobson
>
> Michael Gogins wrote:
>
> > All we need for that is socket opcodes!
> >
> > This kind of facility already exists of course in CsoundVST since Python
has
> > everything from lowlevel sockets to content management systems...
> >
>
>
>