Further, anyone know how I can get a host or other process to receive
csounds redirected standard output in real time? I know this is possible,
because GVIM can do it. If I use a system call in Gvim to start Csound in
real time, gvim prints out the csound output line by line as it plays just
like normal. But when we try a pipe redirect it in BASH or from within
python it seems like:

- csound blocks until the pipe it's sending to is opened
- csound plays just fine, but no text appears in the receiving pipe
- when csound is done, all the text appears at once in the receiving pipe.

Any clue what I might be doing wrong? I'm hoping that by suppressing all
displays from csound, I can use printks to send messages back to another
app/host/process.

Alternatively, we could have a "write to pipe" opcode . . . ; )   ( In your
spare time between 2 and 3 in the morning! )

Thanks in advance.
Iain


----- Original Message -----
From: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Sunday, May 02, 2004 11:31 PM
Subject: [CSOUND-DEV:4543] Re: csound API question


>
> ftfind() returns a a pointer to a function [a FUNC struct] for a given
> table # - so it looks like you would be able to access the function data
> and read/write/mangle or whatever.
>
> this of course could be dangerous, but if the host app knew what it was
> doing it should be ok i think [as long as table lengths were not changed]
>
> ive been planning for a long time to get graphic editing of tables in
> MacCsound, and was just planning on continuously sending f statements,
> your idea would be smoother - then again if you are changing breakpoints
> for a gen5 or something, you would probably need to recalculate the
> entire function --  i do this in one of my demo csound~ patches, and it
> actually works in realtime fine -- obviously if you are oscillating that
> function to produce audio or something, you usually get a click, i cant
> think of an easy way to 'lowpass' this for all gen types to get rid of
> the clicks...
>
> =m
>
>
>
>
>
> On Sun, 2 May 2004, iain duncan wrote:
>
> > > but it should be no sweat to add a ftfind() to the API. [with future
> > > implementation of named function tables!!]
> >
> > The above would do what exactly? I'm thinking it would be cool if the
area
> > of memory that ftables live in could actually be shared with another app
so
> > that while csound is using the tables they could also be read and
updated
> > from a host app or second app. Would this be a pretty major hack of
csound?
> > I suppose another option would be to have the tables shadowed in the
other
> > app and have csound and the host both send score messages to each other
> > indicating what they were doing with the tables but that seems a bit
> > convoluted if not necessary.
> >
> > The idea being that a host sequencer could control/read the tables used
> > within csound for patch data, mixer routing, etc.
> >
> > Thanks for the response.
> > Iain
> >
> >
> > >
> > >
> > > BY THE WAY, looking at csound5 i notice the FUNC **flist is still not
in
> > > the ENVIRON globals -- dont you think it should!?!??
> > >
> > > [although at some point i could see some benefits to having real
global
> > > functions, etc that multiple csound processes can share]
> > >
> > > -m
> > >
> > >
> > > On Sun, 2 May 2004, iain duncan wrote:
> > >
> > > > I'm wondering if the csound API makes it possible for a host app to
> > > > read/write directly to csound ftables or share memory with csound
> > ftables.
> > > > If so, which part of the API should I look at for that.
> > > >
> > > > Thanks,
> > > > Iain
> > > >
> > > >
> > >
> >
> >
>
>

Did you try it with the -O flag and a named pipe?
csound.

My version of csound says it is the -- flag if you do csound --help but
that is wrong.


Gerard


> Further, anyone know how I can get a host or other process to receive
> csounds redirected standard output in real time? I know this is possible,
> because GVIM can do it. If I use a system call in Gvim to start Csound in
> real time, gvim prints out the csound output line by line as it plays just
> like normal. But when we try a pipe redirect it in BASH or from within
> python it seems like:
>
> - csound blocks until the pipe it's sending to is opened
> - csound plays just fine, but no text appears in the receiving pipe
> - when csound is done, all the text appears at once in the receiving pipe.
>
> Any clue what I might be doing wrong? I'm hoping that by suppressing all
> displays from csound, I can use printks to send messages back to another
> app/host/process.
>
> Alternatively, we could have a "write to pipe" opcode . . . ; )   ( In
> your
> spare time between 2 and 3 in the morning! )
>
> Thanks in advance.
> Iain
>
>
> ----- Original Message -----
> From: "Matt J. Ingalls" 
> To: "Csound Developers Discussion List" 
> Sent: Sunday, May 02, 2004 11:31 PM
> Subject: [CSOUND-DEV:4543] Re: csound API question
>
>
>>
>> ftfind() returns a a pointer to a function [a FUNC struct] for a given
>> table # - so it looks like you would be able to access the function data
>> and read/write/mangle or whatever.
>>
>> this of course could be dangerous, but if the host app knew what it was
>> doing it should be ok i think [as long as table lengths were not
>> changed]
>>
>> ive been planning for a long time to get graphic editing of tables in
>> MacCsound, and was just planning on continuously sending f statements,
>> your idea would be smoother - then again if you are changing breakpoints
>> for a gen5 or something, you would probably need to recalculate the
>> entire function --  i do this in one of my demo csound~ patches, and it
>> actually works in realtime fine -- obviously if you are oscillating that
>> function to produce audio or something, you usually get a click, i cant
>> think of an easy way to 'lowpass' this for all gen types to get rid of
>> the clicks...
>>
>> =m
>>
>>
>>
>>
>>
>> On Sun, 2 May 2004, iain duncan wrote:
>>
>> > > but it should be no sweat to add a ftfind() to the API. [with future
>> > > implementation of named function tables!!]
>> >
>> > The above would do what exactly? I'm thinking it would be cool if the
> area
>> > of memory that ftables live in could actually be shared with another
>> app
> so
>> > that while csound is using the tables they could also be read and
> updated
>> > from a host app or second app. Would this be a pretty major hack of
> csound?
>> > I suppose another option would be to have the tables shadowed in the
> other
>> > app and have csound and the host both send score messages to each
>> other
>> > indicating what they were doing with the
>  tables but that seems a bit
>> > convoluted if not necessary.
>> >
>> > The idea being that a host sequencer could control/read the tables
>> used
>> > within csound for patch data, mixer routing, etc.
>> >
>> > Thanks for the response.
>> > Iain
>> >
>> >
>> > >
>> > >
>> > > BY THE WAY, looking at csound5 i notice the FUNC **flist is still
>> not
> in
>> > > the ENVIRON globals -- dont you think it should!?!??
>> > >
>> > > [although at some point i could see some benefits to having real
> global
>> > > functions, etc that multiple csound processes can share]
>> > >
>> > > -m
>> > >
>> > >
>> > > On Sun, 2 May 2004, iain duncan wrote:
>> > >
>> > > > I'm wondering if the csound API makes it possible for a host app
>> to
>> > > > read/write directly to csound ftables or share memory with csound
>> > ftables.
>> > > > If so, which part of the API should I look at for that.
>> > > >
>> > > > Thanks,
>> > > > Iain
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>>

Hi Iain,

In Java I'm calling csound via Runtime.exec() and that just opens up a
process and allows getting stdin, stderr, and stdout.  I do get text in
4K chunks instead of streaming as it goes.  This changed somehow in the
past year or two as I remember the output from Csound used to come in
line by line (I have no idea if this is a change introduced from Csound
or from code in blue).  I also am using threads to read from the pipe.

Recently I've been using Python on my Zaurus PDA and calling csound with
it via the os.system() function.  That's been outputting to screen line
by line.  I have not tried rerouting the piped data using os.popen() but
I'm assuming it is possible.

steven



On Mon, 2004-05-03 at 01:34, iain duncan wrote:
> Further, anyone know how I can get a host or other process to receive
> csounds redirected standard output in real time? I know this is possible,
> because GVIM can do it. If I use a system call in Gvim to start Csound in
> real time, gvim prints out the csound output line by line as it plays just
> like normal. But when we try a pipe redirect it in BASH or from within
> python it seems like:
> 
> - csound blocks until the pipe it's sending to is opened
> - csound plays just fine, but no text appears in the receiving pipe
> - when csound is done, all the text appears at once in the receiving pipe.
> 
> Any clue what I might be doing wrong? I'm hoping that by suppressing all
> displays from csound, I can use printks to send messages back to another
> app/host/process.
> 
> Alternatively, we could have a "write to pipe" opcode . . . ; )   ( In your
> spare time between 2 and 3 in the morning! )
> 
> Thanks in advance.
> Iain
> 
> 
> ----- Original Message -----
> From: "Matt J. Ingalls" 
> To: "Csound Developers Discussion List" 
> Sent: Sunday, May 02, 2004 11:31 PM
> Subject: [CSOUND-DEV:4543] Re: csound API question
> 
> 
> >
> > ftfind() returns a a pointer to a function [a FUNC struct] for a given
> > table # - so it looks like you would be able to access the function data
> > and read/write/mangle or whatever.
> >
> > this of course could be dangerous, but if the host app knew what it was
> > doing it should be ok i think [as long as table lengths were not changed]
> >
> > ive been planning for a long time to get graphic editing of tables in
> > MacCsound, and was just planning on continuously sending f statements,
> > your idea would be smoother - then again if you are changing breakpoints
> > for a gen5 or something, you would probably need to recalculate the
> > entire function --  i do this in one of my demo csound~ patches, and it
> > actually works in realtime fine -- obviously if you are oscillating that
> > function to produce audio or something, you usually get a click, i cant
> > think of an easy way to 'lowpass' this for all gen types to get rid of
> > the clicks...
> >
> > =m
> >
> >
> >
> >
> >
> > On Sun, 2 May 2004, iain duncan wrote:
> >
> > > > but it should be no sweat to add a ftfind() to the API. [with future
> > > > implementation of named function tables!!]
> > >
> > > The above would do what exactly? I'm thinking it would be cool if the
> area
> > > of memory that ftables live in could actually be shared with another app
> so
> > > that while csound is using the tables they could also be read and
> updated
> > > from a host app or second app. Would this be a pretty major hack of
> csound?
> > > I suppose another option would be to have the tables shadowed in the
> other
> > > app and have csound and the host both send score messages to each other
> > > indicating what they were doing with the tables but that seems a bit
> > > convoluted if not necessary.
> > >
> > > The idea being that a host sequencer could control/read the tables used
> > > within csound for patch data, mixer routing, etc.
> > >
> > > Thanks for the response.
> > > Iain
> > >
> > >
> > > >
> > > >
> > > > BY THE WAY, looking at csound5 i notice the FUNC **flist is still not
> in
> > > > the ENVIRON globals -- dont you think it should!?!??
> > > >
> > > > [although at some point i could see some benefits to having real
> global
> > > > functions, etc that multiple csound processes can share]
> > > >
> > > > -m
> > > >
> > > >
> > > > On Sun, 2 May 2004, iain duncan wrote:
> > > >
> > > > > I'm wondering if the csound API makes it possible for a host app to
> > > > > read/write directly to csound ftables or share memory with csound
> > > ftables.
> > > > > If so, which part of the API should I look at for that.
> > > > >
> > > > > Thanks,
> > > > > Iain
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
> 
> 

hi Iain,

another thing to try, using fout with a named pipe. That should work on
linux, there should be no need for a special opcode for outputting to a
pipe.

Gerard

>> Alternatively, we could have a "write to pipe" opcode . . . ; )   ( In
>> your
>> spare time between 2 and 3 in the morning! )
>>
>> Thanks in advance.
>> Iain

well of course there is the output through the API





On Mon, 3 May 2004, iain duncan wrote:

> Further, anyone know how I can get a host or other process to receive
> csounds redirected standard output in real time? I know this is possible,
> because GVIM can do it. If I use a system call in Gvim to start Csound in
> real time, gvim prints out the csound output line by line as it plays just
> like normal. But when we try a pipe redirect it in BASH or from within
> python it seems like:
>
> - csound blocks until the pipe it's sending to is opened
> - csound plays just fine, but no text appears in the receiving pipe
> - when csound is done, all the text appears at once in the receiving pipe.
>
> Any clue what I might be doing wrong? I'm hoping that by suppressing all
> displays from csound, I can use printks to send messages back to another
> app/host/process.
>
> Alternatively, we could have a "write to pipe" opcode . . . ; )   ( In your
> spare time between 2 and 3 in the morning! )
>
> Thanks in advance.
> Iain
>
>
> ----- Original Message -----
> From: "Matt J. Ingalls" 
> To: "Csound Developers Discussion List" 
> Sent: Sunday, May 02, 2004 11:31 PM
> Subject: [CSOUND-DEV:4543] Re: csound API question
>
>
> >
> > ftfind() returns a a pointer to a function [a FUNC struct] for a given
> > table # - so it looks like you would be able to access the function data
> > and read/write/mangle or whatever.
> >
> > this of course could be dangerous, but if the host app knew what it was
> > doing it should be ok i think [as long as table lengths were not changed]
> >
> > ive been planning for a long time to get graphic editing of tables in
> > MacCsound, and was just planning on continuously sending f statements,
> > your idea would be smoother - then again if you are changing breakpoints
> > for a gen5 or something, you would probably need to recalculate the
> > entire function --  i do this in one of my demo csound~ patches, and it
> > actually works in realtime fine -- obviously if you are oscillating that
> > function to produce audio or something, you usually get a click, i cant
> > think of an easy way to 'lowpass' this for all gen types to get rid of
> > the clicks...
> >
> > =m
> >
> >
> >
> >
> >
> > On Sun, 2 May 2004, iain duncan wrote:
> >
> > > > but it should be no sweat to add a ftfind() to the API. [with future
> > > > implementation of named function tables!!]
> > >
> > > The above would do what exactly? I'm thinking it would be cool if the
> area
> > > of memory that ftables live in could actually be shared with another app
> so
> > > that while csound is using the tables they could also be read and
> updated
> > > from a host app or second app. Would this be a pretty major hack of
> csound?
> > > I suppose another option would be to have the tables shadowed in the
> other
> > > app and have csound and the host both send score messages to each other
> > > indicating what they were doing with the tables but that seems a bit
> > > convoluted if not necessary.
> > >
> > > The idea being that a host sequencer could control/read the tables used
> > > within csound for patch data, mixer routing, etc.
> > >
> > > Thanks for the response.
> > > Iain
> > >
> > >
> > > >
> > > >
> > > > BY THE WAY, looking at csound5 i notice the FUNC **flist is still not
> in
> > > > the ENVIRON globals -- dont you think it should!?!??
> > > >
> > > > [although at some point i could see some benefits to having real
> global
> > > > functions, etc that multiple csound processes can share]
> > > >
> > > > -m
> > > >
> > > >
> > > > On Sun, 2 May 2004, iain duncan wrote:
> > > >
> > > > > I'm wondering if the csound API makes it possible for a host app to
> > > > > read/write directly to csound ftables or share memory with csound
> > > ftables.
> > > > > If so, which part of the API should I look at for that.
> > > > >
> > > > > Thanks,
> > > > > Iain
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>

Whare is the link to the soundforge sources?
I've never been there:)
Josep M Comajuncosas

-----Mensaje original-----
De: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu] En nombre de Matt J. Ingalls
Enviado el: lunes, 03 de mayo de 2004 19:17
Para: Csound Developers Discussion List
Asunto: [CSOUND-DEV:4554] Re: csound API question


well of course there is the output through the API

To get everything

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/csound login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/csound co csound5

Or browse

http://cvs.sourceforge.net/viewcvs.py/csound/

==John

Hi Josep,

The sourceforge site for csound is:

http://www.sourceforge.net/projects/csound

There's a link for CVS and that will take you to a page with information 
to get the sources.

steven

Josep MComajuncosas wrote:

>Whare is the link to the soundforge sources?
>I've never been there:)
>Josep M Comajuncosas
>
>-----Mensaje original-----
>De: owner-csound-dev@eartha.mills.edu
>[mailto:owner-csound-dev@eartha.mills.edu] En nombre de Matt J. Ingalls
>Enviado el: lunes, 03 de mayo de 2004 19:17
>Para: Csound Developers Discussion List
>Asunto: [CSOUND-DEV:4554] Re: csound API question
>
>
>well of course there is the output through the API
>
>
>
>
>  
>

>Whare is the link to the soundforge sources?

Hi Josep,
You can browse the CVS in html, but if you want to download the sources you 
need to get a cvs client. If you're on windows, WinCVS is easy to use, You can 
get it at:
www.wincvs.org

To download the Csound5 sources using CVS, run the following commands:

cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/csound login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/csound co csound5

You can copy paste these in the lower frame of win cvs and press return first 
on the first line and then on the second. Make sure you are browsing the 
folder where you want the csound sources to end up. The Csound5 folder is 
created for you.
When you've downloaded the sources, you can then read csound.pdf and there 
you'll see other dependencies you'll need to download to get csound5 to 
compile.

Cheers,
Andres
-- 
Andres Cabrera
TELESET
Calle 79A #8-63
Tel. 321 2100
Bogotá, Colombia

Hi,
I've been trying unsuccesfully to build libportaudio for v19. The included 
makefile doesn't do the trick out of the box like it did for v18.
I get:

$ make -f makefile.in
c:\dev-cpp\bin\make.exe: *** No rule to make target 
`lib/pa_common/pa_allocation.o', needed by `lib/libportaudio.a'.  Stop.

both on msys and normal DOS box. I haven't found any clue in the portaudio 
list, so I turn here because some of you may have had the same problem.
I've also tried (after changing CC= i586-mingw32msvc-gcc to CC=gcc) :

$ make -f makefile.mingw all
gcc -c -I./pa_common pa_common/pa_lib.c -o pa_common/pa_lib.o
In file included from pa_common/pa_lib.c:54:
pa_common/pa_host.h:85: parse error before "PaDeviceID"
pa_common/pa_host.h:85: warning: no semicolon at end of struct or union
pa_common/pa_host.h:86: warning: data definition has no type or storage class
pa_common/pa_host.h:92: parse error before '*' token
pa_common/pa_host.h:92: warning: data definition has no type or storage class
and a long list of errors follows...

Anyone can help?

Thanks,
Andres

I thought that one had to do a ./configure to convert the Makefile.in
to a Makefile?
==John ffitch

Thanks John and Steven
Josep M Comajuncosas


-----Mensaje original-----
De: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu] En nombre de steven yi
Enviado el: lunes, 03 de mayo de 2004 22:44
Para: Csound Developers Discussion List
Asunto: [CSOUND-DEV:4560] Re: csound API question

Hi Josep,

The sourceforge site for csound is:

http://www.sourceforge.net/projects/csound

There's a link for CVS and that will take you to a page with information

to get the sources.

steven

Josep MComajuncosas wrote:

>Whare is the link to the soundforge sources?
>I've never been there:)
>Josep M Comajuncosas
>
>-----Mensaje original-----
>De: owner-csound-dev@eartha.mills.edu
>[mailto:owner-csound-dev@eartha.mills.edu] En nombre de Matt J. Ingalls
>Enviado el: lunes, 03 de mayo de 2004 19:17
>Para: Csound Developers Discussion List
>Asunto: [CSOUND-DEV:4554] Re: csound API question
>
>
>well of course there is the output through the API
>
>
>
>
>  
>