Hi,
It's me again with my portaudio problems. I've tried building Csound5 both 
with portaudio 19 and with v18.1, and the errors are exactly the same in both 
cases, so I guess the problem is not portaudio, but something else. Anyone 
knows what it can be?

gcc -DCSOUND_WITH_API -g -O2 -mthreads -DHAVE_IO_H -DHAVE_FCNTL_H -
DHAVE_UNISTD_          H -DHAVE_MALLOC_H -DHAVE_SYS_TIME_H -DHAVE_STRING_H -
DHAVE_STRINGS_H -DHAVE_DIRE          NT_H -DHAVE_ITOA -g -O2 -Wall -D_WIN32 -
DWIN32 -DHAVE_STRING_H -DPIPES -DOS_IS_W          IN32 -DRTAUDIO -DBETA -
IC:\mingw\include -IC:\tools\libsndfile-1.0.10pre4\src -I          C:\Python233
\include -IC:\msys\1.0\include -IC:\tools\portaudio\pa_common -IC:\t          
ools\boost_1_31_0 -I. -IH -ISDIF -I\usr\local\include -I\usr\include -c -o 
InOut          \rtpa.o InOut\rtpa.c
In file included from H/cs.h:34,
                 from InOut/rtpa.c:9:
H/csoundCore.h:770:1: warning: "__cdecl" redefined
InOut/rtpa.c:1:1: warning: this is the location of the previous definition
InOut/rtpa.c: In function `recopen_':
InOut/rtpa.c:59: storage size of `paStreamParameters_' isn't known
InOut/rtpa.c:80: warning: passing arg 5 of `Pa_OpenStream' makes pointer from 
in          teger without a cast
InOut/rtpa.c:80: too few arguments to function `Pa_OpenStream'
InOut/rtpa.c:59: warning: unused variable `paStreamParameters_'
InOut/rtpa.c: In function `listPortAudioDevices':
InOut/rtpa.c:90: `PaDeviceIndex' undeclared (first use in this function)
InOut/rtpa.c:90: (Each undeclared identifier is reported only once
InOut/rtpa.c:90: for each function it appears in.)
InOut/rtpa.c:90: parse error before "deviceIndex"
InOut/rtpa.c:94: `deviceCount' undeclared (first use in this function)
InOut/rtpa.c:94: warning: implicit declaration of function `Pa_GetDeviceCount'
InOut/rtpa.c:96: `deviceIndex' undeclared (first use in this function)
InOut/rtpa.c:97: warning: assignment discards qualifiers from pointer target 
typ          e
InOut/rtpa.c:105: structure has no member named `defaultSampleRate'
InOut/rtpa.c: In function `playopen_':
InOut/rtpa.c:113: storage size of `paStreamParameters_' isn't known
InOut/rtpa.c:145: warning: passing arg 5 of `Pa_OpenStream' makes pointer from 
i          nteger without a cast
InOut/rtpa.c:145: too few arguments to function `Pa_OpenStream'
InOut/rtpa.c:113: warning: unused variable `paStreamParameters_'
InOut/rtpa.c: In function `rtrecord_':
InOut/rtpa.c:170: warning: implicit declaration of function `Pa_ReadStream'
InOut/rtpa.c: In function `rtplay_':
InOut/rtpa.c:198: warning: implicit declaration of function `Pa_WriteStream'
scons: building terminated because of errors.
scons: *** [InOut\rtpa.o] Error 1

Thanks,
Andres

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...
> 

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...

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


> It never occurred to me the automation bus would be anything other than
global.
> It is created by Csound itself, and ~used~ by instruemnts and hosts. zak
is global.
>
> Having multiple instances of Csound in a process is one thing, having them
talk
> to each other is quite another!  I can recall that trick ever having been
> discussed  before! Inter-instance comms really would need to be mediated
by a
> host (ports, busses, etc). It sounds at least as scary as plugin opcodes
talking
> to each other behind the scenes.
>
> Richard Dobson
>
>
>
> Matt J. Ingalls wrote:
>
> >>this brings up another point, that the bus system needs to be global or
> >>there should be a way to specify global channels for hosts that are
using
> >
> >
> > correction: there should AT LEAST be away to specify global channels,
> > and now that i think about it, there definitely needs to be local
channels
> > as well, because of:
> >
> >
> >>multiple csound processes and/or multiple csound processes communicating
> >>with eachother.
> >
> >
> >
> >
>
>