Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:4541] Re: csound API question

Date2004-05-03 02:14
From"iain duncan"
Subject[CSOUND-DEV:4541] Re: csound API question
> 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
> >
> >
>

Date2004-05-03 07:31
From"Matt J. Ingalls"
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
> > >
> > >
> >
>
>