Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] arrays in the API

Ok, see what you think of the current state and if you feel we need to modify the interface and introduce CS_VARIABLEs, then we need to come up with a plan. At the moment, I have basically kept the same interface and extended it to handle arrays.

I think opaque types are probable the best way forward in any case.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 10 Aug 2024, at 21:26, Steven Yi <[email protected]> wrote:
> 
> I need to catch up with all of this, but I had the thought we could be
> exposing channels as CS_VARIABLE's and creating an API around
> reading/writing CS_VARIABLE. It'd make it a little easier for channels
> to have one csoundGetChannelVar() function and then have functions to
> interrogate the type and call appropriate functions to work with the
> variable.
> 
>> On Sat, Aug 10, 2024 at 2:28 PM vlz <[email protected]> wrote:
>> 
>> Ok I have changed the interface. We get the channel pointer and then use API to
>> access the array data.
>> Here’s a test program
>> 
>> int main(int argc, char **argv) {
>> 
>>  CSOUND  *csound;
>>  ARRAYDAT *adat, *adat2;
>>  const MYFLT *data;
>>  MYFLT indata[4] = {5,6,7,8};
>>  int   n, siz;
>> 
>>  const char *code = R"ORC(
>>   instr 1
>>   kArr[] fillarray 1,2,3,4  // array data for output
>>   kArr2[] init 4    // array data for input
>> 
>>   chnset kArr, "testout" // set channel
>>   kArr2[] chnget "testin" // get channel
>> 
>>   printarray kArr2  // print channel
>>   endin
>>   )ORC";
>> 
>>  csound = csoundCreate(NULL, NULL);
>>  csoundSetOption(csound,"-n");
>>  csoundCompileOrc(csound, code, 0);
>>  csoundEventString(csound, "i1 0 1", 0);
>>  csoundStart(csound);
>> 
>>  // perform once
>>  csoundPerformKsmps(csound);
>> 
>>  // access channels directly
>>  csoundGetChannelPtr(csound, (void **) &adat, "testout", CSOUND_ARRAY_CHANNEL
>>                      | CSOUND_OUTPUT_CHANNEL);
>>  csoundGetChannelPtr(csound, (void **) &adat2, "testin", CSOUND_ARRAY_CHANNEL
>>                      | CSOUND_INPUT_CHANNEL);
>> 
>>  // get channel data
>>  data = (const MYFLT *) csoundGetArrayData(adat);
>>  siz = csoundArrayDataSizes(adat)[0];
>>  for(n = 0; n < siz; n++)
>>    printf("[%d]: %f \n", n, data[n]);
>> 
>>  // set channel data
>>  csoundSetArrayData(adat2, (void *) indata);
>> 
>>  // perform again
>>  csoundPerformKsmps(csound);
>>  csoundDestroy(csound);
>> 
>>  return 0;
>> }
>> 
>> 
>> 
>> 
>>>> On 10 Aug 2024, at 18:06, vlz <[email protected]> wrote:
>>> 
>>> *Warning*
>>> This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
>>> Agreed. I have a design for this and I'll go ahead and implement.
>>> 
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 9 Aug 2024, at 18:49, Rory Walsh <[email protected]> wrote:
>>>> 
>>>>  I'd be leaning towards making it opaque and doing the same for PVSDATEXT.
>>>> 
>>>> On Fri, 9 Aug 2024 at 14:56, Victor Lazzarini <[email protected]> wrote:
>>>> I am now wondering about the best way to give access to arrays in the API.
>>>> 
>>>> (1) Expose ARRAYDAT: at the moment the array data structure is transparent, so we can access all its members directly.
>>>> 
>>>> or
>>>> 
>>>> (2) Provide an interface: we can make the object opaque, providing access through API functions.
>>>> 
>>>> I can't decide. At the moment, STRINGDAT is opaque but PVSDATEXT is not. I am thinking of changing that one but have not decided yet.
>>>> 
>>>> Option 2 is safer but may be cumbersome for users.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland