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

That sounds like probably what we were getting.

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

Cool, I'll give that a shot and see what happens.
Iain

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