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



I'd be leaning towards making it opaque and doing the same for PVSDATEXT. 

On Fri, 9 Aug 2024 at 14:56, Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> 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

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  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  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 <000010b17ddd988e-dmarc-request@listserv.heanet.ie> 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

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  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  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  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 <000010b17ddd988e-dmarc-request@listserv.heanet.ie> 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

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  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  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  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  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 <000010b17ddd988e-dmarc-request@listserv.heanet.ie> 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