Hi,

I've made a document detailing the current state of bus communication
with the API, which shows how bad the current situation is.

https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit

I hope to come up with a system for Csound6 that supports the existing
opcodes, but that is simpler to use for hosts and that supports
generic data types for the new type system. It could also be made
thread safe, although that is trickier...

Cheers,
Andrés

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforg

Andres,

it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use 
slightly differently).

Regards

Victor
On 8 Nov 2012, at 02:12, Andres Cabrera wrote:

> Hi,
> 
> I've made a document detailing the current state of bus communication
> with the API, which shows how bad the current situation is.
> 
> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
> 
> I hope to come up with a system for Csound6 that supports the existing
> opcodes, but that is simpler to use for hosts and that supports
> generic data types for the new type system. It could also be made
> thread safe, although that is trickier...
> 
> Cheers,
> Andrés
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The interface makes sense to me. In terms of implementation, ideally I think it shpuld be lock free, if at all possible.

VL


On 13 Nov 2012, at 03:16, Andres Cabrera  wrote:

> Hi,
> 
> I've been thinking it would be nice if the API functions looked something like:
> 
> CS_VARIABLE csoundGetBusVariable(CSOUND *, const char * channel, const
> char * type_name);
> CS_VARIABLE *csoundGetBusVariablePointer(...);
> 
> int csoundSetBusVariable(CSOUND *, const char *channel, const
> CS_VARIABLE * var);
> 
> Only the second function would not be realtime safe, but would be
> available if a host wants to process variables synchronously with
> Csound.
> 
> In practical terms, I think what would need to happen is pass a
> pointer to an allocated message to the Csound engine containing the
> data, and have the Csound engine flip an atomic switch within it to
> signal the function that it can return.
> 
> I'm even thinking that this should somehow be extended to variables in
> general for debugging. One should be able to access variables within
> instrument instances.
> 
> One more thing that comes to mind is that there should be a thread
> safe interface for table queries too.
> 
> Cheers,
> Andrés
> 
> On Wed, Nov 7, 2012 at 11:38 PM, Victor Lazzarini
>  wrote:
>> Andres,
>> 
>> it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
>> it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use
>> slightly differently).
>> 
>> Regards
>> 
>> Victor
>> On 8 Nov 2012, at 02:12, Andres Cabrera wrote:
>> 
>>> Hi,
>>> 
>>> I've made a document detailing the current state of bus communication
>>> with the API, which shows how bad the current situation is.
>>> 
>>> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
>>> 
>>> I hope to come up with a system for Csound6 that supports the existing
>>> opcodes, but that is simpler to use for hosts and that supports
>>> generic data types for the new type system. It could also be made
>>> thread safe, although that is trickier...
>>> 
>>> Cheers,
>>> Andrés
>>> 
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_nov
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sour

Hi,

I've been thinking it would be nice if the API functions looked something like:

CS_VARIABLE csoundGetBusVariable(CSOUND *, const char * channel, const
char * type_name);
CS_VARIABLE *csoundGetBusVariablePointer(...);

int csoundSetBusVariable(CSOUND *, const char *channel, const
CS_VARIABLE * var);

Only the second function would not be realtime safe, but would be
available if a host wants to process variables synchronously with
Csound.

In practical terms, I think what would need to happen is pass a
pointer to an allocated message to the Csound engine containing the
data, and have the Csound engine flip an atomic switch within it to
signal the function that it can return.

I'm even thinking that this should somehow be extended to variables in
general for debugging. One should be able to access variables within
instrument instances.

One more thing that comes to mind is that there should be a thread
safe interface for table queries too.

Cheers,
Andrés

On Wed, Nov 7, 2012 at 11:38 PM, Victor Lazzarini
 wrote:
> Andres,
>
> it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
> it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use
> slightly differently).
>
> Regards
>
> Victor
> On 8 Nov 2012, at 02:12, Andres Cabrera wrote:
>
>> Hi,
>>
>> I've made a document detailing the current state of bus communication
>> with the API, which shows how bad the current situation is.
>>
>> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
>>
>> I hope to come up with a system for Csound6 that supports the existing
>> opcodes, but that is simpler to use for hosts and that supports
>> generic data types for the new type system. It could also be made
>> thread safe, although that is trickier...
>>
>> Cheers,
>> Andrés
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_nov
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https

The only thing against this interface, by the way, is that it might not suit audio-rate signals, as it would be awkward to pass vectors.
We could have an alternative like this:

/*
 Reads the contents of a channel into the variable pointed by var, returning the number of items read
*/
int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
             char * type_name, int size);


which could be implemented like this:

int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
             char * type_name, int size) {
    channel_t   *chn;
    chn = csound->GetChn(channel, type_name);
    return csoundReadCircularBuffer(csound, chn->buffer, var, size);
}

and used like this (scalars):

while(!cnt) 
cnt = csoundGetBusVariable(csound, &ksig, "kout", "ko", 1);

or like this (vectors):

while(cnt != ksmps){
 cnt += csoundGetBusVariable(csound, &asig[offset], "aout", "ao", ksmps - cnt);
 offset += cnt;
}

The opposite direction could be similarly implemented.

Regards

Victor

On 12 Nov 2012, at 19:43, Victor Lazzarini wrote:

> The interface makes sense to me. In terms of implementation, ideally I think it shpuld be lock free, if at all possible.
> 
> VL
> 
> 
> On 13 Nov 2012, at 03:16, Andres Cabrera  wrote:
> 
>> Hi,
>> 
>> I've been thinking it would be nice if the API functions looked something like:
>> 
>> CS_VARIABLE csoundGetBusVariable(CSOUND *, const char * channel, const
>> char * type_name);
>> CS_VARIABLE *csoundGetBusVariablePointer(...);
>> 
>> int csoundSetBusVariable(CSOUND *, const char *channel, const
>> CS_VARIABLE * var);
>> 
>> Only the second function would not be realtime safe, but would be
>> available if a host wants to process variables synchronously with
>> Csound.
>> 
>> In practical terms, I think what would need to happen is pass a
>> pointer to an allocated message to the Csound engine containing the
>> data, and have the Csound engine flip an atomic switch within it to
>> signal the function that it can return.
>> 
>> I'm even thinking that this should somehow be extended to variables in
>> general for debugging. One should be able to access variables within
>> instrument instances.
>> 
>> One more thing that comes to mind is that there should be a thread
>> safe interface for table queries too.
>> 
>> Cheers,
>> Andrés
>> 
>> On Wed, Nov 7, 2012 at 11:38 PM, Victor Lazzarini
>>  wrote:
>>> Andres,
>>> 
>>> it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
>>> it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use
>>> slightly differently).
>>> 
>>> Regards
>>> 
>>> Victor
>>> On 8 Nov 2012, at 02:12, Andres Cabrera wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I've made a document detailing the current state of bus communication
>>>> with the API, which shows how bad the current situation is.
>>>> 
>>>> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
>>>> 
>>>> I hope to come up with a system for Csound6 that supports the existing
>>>> opcodes, but that is simpler to use for hosts and that supports
>>>> generic data types for the new type system. It could also be made
>>>> thread safe, although that is trickier...
>>>> 
>>>> Cheers,
>>>> Andrés
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Andres,

Regarding inspecting of variables within an instrument instance, the
new typesystem has the basis for doing this.  Currently during
compiling, CS_VARIABLE's are generated that have a reference to the
name of the variable, the type, memblock size, and memBlockIndex.  The
sum of all variables' sizes is used for the instrument template of
memory to alloc, and the memBlockIndex is used to index into the big
block of memory.  From this, one can create a function like:

void* getMemForVariable(INSDS* instr, char* variableName);

Then cast it to read from it.  Something like this might be useful too:

CS_VARIABLE* getCsVarForName(INSDS* instr, char* variableName)

so that once the variable is returned, you could do:

void* memblock = getMemForVariable(instr, "kenv");
CS_VARIABLE* var = getCsVarForName(instr, "kenv");

if(var->varType == CS_TYPE_A) {
   MYFLT* asig = (MYFLT*)memblock;
  ...etc...
}

(Assuming the code in csound_standard_types.c get modified into
something that could be put into the header for reference elsewhere)

For the bus, I think we also need to think about it in terms of types
being generic.  It should be possible to read/write anything to the
bus, whether it's an f-sig, a-sig, array of w-sig, array of k-sig,
etc.

steven

On Tue, Nov 13, 2012 at 3:16 AM, Andres Cabrera  wrote:
> Hi,
>
> I've been thinking it would be nice if the API functions looked something like:
>
> CS_VARIABLE csoundGetBusVariable(CSOUND *, const char * channel, const
> char * type_name);
> CS_VARIABLE *csoundGetBusVariablePointer(...);
>
> int csoundSetBusVariable(CSOUND *, const char *channel, const
> CS_VARIABLE * var);
>
> Only the second function would not be realtime safe, but would be
> available if a host wants to process variables synchronously with
> Csound.
>
> In practical terms, I think what would need to happen is pass a
> pointer to an allocated message to the Csound engine containing the
> data, and have the Csound engine flip an atomic switch within it to
> signal the function that it can return.
>
> I'm even thinking that this should somehow be extended to variables in
> general for debugging. One should be able to access variables within
> instrument instances.
>
> One more thing that comes to mind is that there should be a thread
> safe interface for table queries too.
>
> Cheers,
> Andrés
>
> On Wed, Nov 7, 2012 at 11:38 PM, Victor Lazzarini
>  wrote:
>> Andres,
>>
>> it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
>> it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use
>> slightly differently).
>>
>> Regards
>>
>> Victor
>> On 8 Nov 2012, at 02:12, Andres Cabrera wrote:
>>
>>> Hi,
>>>
>>> I've made a document detailing the current state of bus communication
>>> with the API, which shows how bad the current situation is.
>>>
>>> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
>>>
>>> I hope to come up with a system for Csound6 that supports the existing
>>> opcodes, but that is simpler to use for hosts and that supports
>>> generic data types for the new type system. It could also be made
>>> thread safe, although that is trickier...
>>>
>>> Cheers,
>>> Andrés
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_nov
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Victor,

Arrays can be accomodated inside the CS_VARIABLE struct, thanks to
Steven's work, so what would be done internally for audio arrays is
copying the data from the audio buffer to the CS_VARIABLE.

I'm now thinking that the variable should be allocated in the host,
with a pointer passed to Csound, which would only fill the data there,
otherwise, since the size of arrays may not be known, Csound itself
would have to do the allocation, either blocking the audio thread, or
with some other very convoluted solution. So the API would look like:

int csoundGetBusVariable(CSOUND *, const char * channel, const
char * type_name, CS_VARIABLE* allocated_var);

I'm not sure a circular buffer would be ideal here, as there is no
guarantee that the reader is trying keeping up with the writer or
viceversa. You could be writing ocasionally to the buffer and reading
at completely different times, so the only significant data is the
very last one. However, the csoundGetBusVariablePointer function could
work for this, as the CS_VARIABLE struct would point internally to a C
array.

One of the things that would be nice to iron out is getting the values
easily from the CS_VARIABLE struct. Maybe helper functions should be
written and put in the API for the common types?

In the tradition of writing RFC to the wiki, I've done:
https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_9-Variable_and_Bus_data_API

Cheers,
Andrés

On Tue, Nov 13, 2012 at 1:46 AM, Victor Lazzarini
 wrote:
> The only thing against this interface, by the way, is that it might not suit audio-rate signals, as it would be awkward to pass vectors.
> We could have an alternative like this:
>
> /*
>  Reads the contents of a channel into the variable pointed by var, returning the number of items read
> */
> int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
>              char * type_name, int size);
>
>
> which could be implemented like this:
>
> int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
>              char * type_name, int size) {
>     channel_t   *chn;
>     chn = csound->GetChn(channel, type_name);
>     return csoundReadCircularBuffer(csound, chn->buffer, var, size);
> }
>
> and used like this (scalars):
>
> while(!cnt)
> cnt = csoundGetBusVariable(csound, &ksig, "kout", "ko", 1);
>
> or like this (vectors):
>
> while(cnt != ksmps){
>  cnt += csoundGetBusVariable(csound, &asig[offset], "aout", "ao", ksmps - cnt);
>  offset += cnt;
> }
>
> The opposite direction could be similarly implemented.
>
> Regards
>
> Victor
>
> On 12 Nov 2012, at 19:43, Victor Lazzarini wrote:
>
>> The interface makes sense to me. In terms of implementation, ideally I think it shpuld be lock free, if at all possible.
>>
>> VL
>>
>>
>> On 13 Nov 2012, at 03:16, Andres Cabrera  wrote:
>>
>>> Hi,
>>>
>>> I've been thinking it would be nice if the API functions looked something like:
>>>
>>> CS_VARIABLE csoundGetBusVariable(CSOUND *, const char * channel, const
>>> char * type_name);
>>> CS_VARIABLE *csoundGetBusVariablePointer(...);
>>>
>>> int csoundSetBusVariable(CSOUND *, const char *channel, const
>>> CS_VARIABLE * var);
>>>
>>> Only the second function would not be realtime safe, but would be
>>> available if a host wants to process variables synchronously with
>>> Csound.
>>>
>>> In practical terms, I think what would need to happen is pass a
>>> pointer to an allocated message to the Csound engine containing the
>>> data, and have the Csound engine flip an atomic switch within it to
>>> signal the function that it can return.
>>>
>>> I'm even thinking that this should somehow be extended to variables in
>>> general for debugging. One should be able to access variables within
>>> instrument instances.
>>>
>>> One more thing that comes to mind is that there should be a thread
>>> safe interface for table queries too.
>>>
>>> Cheers,
>>> Andrés
>>>
>>> On Wed, Nov 7, 2012 at 11:38 PM, Victor Lazzarini
>>>  wrote:
>>>> Andres,
>>>>
>>>> it's good that you plan to do it. Regarding threading, if you do all the reads/writes via a circular buffer (see InOut/circularbuffer.c), then
>>>> it should be thread safe. For an example of their use see InOut/rtauhal.c (but since the application is different, you might want to use
>>>> slightly differently).
>>>>
>>>> Regards
>>>>
>>>> Victor
>>>> On 8 Nov 2012, at 02:12, Andres Cabrera wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've made a document detailing the current state of bus communication
>>>>> with the API, which shows how bad the current situation is.
>>>>>
>>>>> https://docs.google.com/document/d/1VqpFrE3V5tDoFMfREeb7AdpeYiE772TukxbyB4uqrJ8/edit
>>>>>
>>>>> I hope to come up with a system for Csound6 that supports the existing
>>>>> opcodes, but that is simpler to use for hosts and that supports
>>>>> generic data types for the new type system. It could also be made
>>>>> thread safe, although that is trickier...
>>>>>
>>>>> Cheers,
>>>>> Andrés
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Everyone hates slow websites. So do we.
>>>>> Make your web apps faster with AppDynamics
>>>>> Download AppDynamics Lite for free today:
>>>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_nov
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Monitor your physical, virtual and cloud infrastructure from a single
>>> web console. Get in-depth insight into apps, servers, databases, vmware,
>>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>>> Pricing starts from $795 for 25 servers or applications!
>>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourc

Sounds good. Maybe the circular buffer is not the way with scalars, but I think it should be used in the case of audio, as you will want to read all that is written to the bus. 

Victor
On 13 Nov 2012, at 19:12, Andres Cabrera  wrote:

> Hi Victor,
> 
> Arrays can be accomodated inside the CS_VARIABLE struct, thanks to
> Steven's work, so what would be done internally for audio arrays is
> copying the data from the audio buffer to the CS_VARIABLE.
> 
> I'm now thinking that the variable should be allocated in the host,
> with a pointer passed to Csound, which would only fill the data there,
> otherwise, since the size of arrays may not be known, Csound itself
> would have to do the allocation, either blocking the audio thread, or
> with some other very convoluted solution. So the API would look like:
> 
> int csoundGetBusVariable(CSOUND *, const char * channel, const
> char * type_name, CS_VARIABLE* allocated_var);
> 
> I'm not sure a circular buffer would be ideal here, as there is no
> guarantee that the reader is trying keeping up with the writer or
> viceversa. You could be writing ocasionally to the buffer and reading
> at completely different times, so the only significant data is the
> very last one. However, the csoundGetBusVariablePointer function could
> work for this, as the CS_VARIABLE struct would point internally to a C
> array.
> 
> One of the things that would be nice to iron out is getting the values
> easily from the CS_VARIABLE struct. Maybe helper functions should be
> written and put in the API for the common types?
> 
> In the tradition of writing RFC to the wiki, I've done:
> https://sourceforge.net/apps/mediawiki/csound/index.php?title=RFC_9-Variable_and_Bus_data_API
> 
> Cheers,
> Andrés
> 
> On Tue, Nov 13, 2012 at 1:46 AM, Victor Lazzarini
>  wrote:
>> The only thing against this interface, by the way, is that it might not suit audio-rate signals, as it would be awkward to pass vectors.
>> We could have an alternative like this:
>> 
>> /*
>> Reads the contents of a channel into the variable pointed by var, returning the number of items read
>> */
>> int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
>>             char * type_name, int size);
>> 
>> 
>> which could be implemented like this:
>> 
>> int csoundGetBusVariable(CSOUND *csound, MYFLT *var, const char * channel, const
>>             char * type_name, int size) {
>>    channel_t   *chn;
>>    chn = csound->GetChn(channel, type_name);
>>    return csoundReadCircularBuffer(csound, chn->buffer, var, size);
>> }
>> 
>> and

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.source