Wouldn't it be better to use Jack?

Original Message:
-----------------
From: iain duncan iainduncan@telus.net
Date: Mon, 3 May 2004 01:34:06 -0700
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4545] Re: csound API question


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


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .