Hi all,

I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
in OENTRY. 

At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
works, it seems a bit awkward. 

Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
be able to reuse it for this purpose. For example,

 OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};

Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.

The current deinit routine for an instrument is:

/* call the opcode deinitialisation routines of an instrument instance */
/* called from deact() in insert.c */
int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
{
    int err = 0;

    while (ip->nxtd != NULL) {
      opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
      err |= dp->func(csound, dp->p);
      ip->nxtd = (void*) dp->nxt;
      free(dp);
    }
    return err;
}

and we would possibly modify it to be something simple like this:

int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
{
   int err = 0;
   OPDS dds = (OPDS *) ip;
   while ((dds = dds->nxtp) != NULL) 
    err |= (*dds->dopadr)(csound, dds);
   return err;
}

or thereabouts. 

Any thoughts?
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

I'm in favor of this, it's a much clearer design. I'd also recommend
removing csoundRegisterDeinitCallback() from the API.

On Tue, Mar 26, 2024 at 10:35 AM Victor Lazzarini
 wrote:
>
> Hi all,
>
> I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
> in OENTRY.
>
> At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
> works, it seems a bit awkward.
>
> Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
> be able to reuse it for this purpose. For example,
>
>  OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};
>
> Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.
>
> The current deinit routine for an instrument is:
>
> /* call the opcode deinitialisation routines of an instrument instance */
> /* called from deact() in insert.c */
> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
> {
>     int err = 0;
>
>     while (ip->nxtd != NULL) {
>       opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
>       err |= dp->func(csound, dp->p);
>       ip->nxtd = (void*) dp->nxt;
>       free(dp);
>     }
>     return err;
> }
>
> and we would possibly modify it to be something simple like this:
>
> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
> {
>    int err = 0;
>    OPDS dds = (OPDS *) ip;
>    while ((dds = dds->nxtp) != NULL)
>     err |= (*dds->dopadr)(csound, dds);
>    return err;
> }
>
> or thereabouts.
>
> Any thoughts?
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>

Thanks for the feedback, Mike and Steven.
I’ll get to that soon. It should not be too difficult.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 26 Mar 2024, at 19:33, Steven Yi  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.
> 
> I'm in favor of this, it's a much clearer design. I'd also recommend
> removing csoundRegisterDeinitCallback() from the API.
> 
> On Tue, Mar 26, 2024 at 10:35 AM Victor Lazzarini
>  wrote:
>> 
>> Hi all,
>> 
>> I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
>> in OENTRY.
>> 
>> At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
>> works, it seems a bit awkward.
>> 
>> Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
>> be able to reuse it for this purpose. For example,
>> 
>> OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};
>> 
>> Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.
>> 
>> The current deinit routine for an instrument is:
>> 
>> /* call the opcode deinitialisation routines of an instrument instance */
>> /* called from deact() in insert.c */
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>    int err = 0;
>> 
>>    while (ip->nxtd != NULL) {
>>      opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
>>      err |= dp->func(csound, dp->p);
>>      ip->nxtd = (void*) dp->nxt;
>>      free(dp);
>>    }
>>    return err;
>> }
>> 
>> and we would possibly modify it to be something simple like this:
>> 
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>   int err = 0;
>>   OPDS dds = (OPDS *) ip;
>>   while ((dds = dds->nxtp) != NULL)
>>    err |= (*dds->dopadr)(csound, dds);
>>   return err;
>> }
>> 
>> or thereabouts.
>> 
>> Any thoughts?
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>> 



Please don't remove the API call.

 One thing that is not clear about deinitialization is what is guaranteed to exist at this point. For example, should  an opcode be able to read its arguments at this point? For example I tried implementing a "defer" opcode, somewhat similar to go's defer, and found that reading input arguments could lead to invalid memory access.

On Wed, Mar 27, 2024, 00:31 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for the feedback, Mike and Steven.
I’ll get to that soon. It should not be too difficult.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 26 Mar 2024, at 19:33, Steven Yi <stevenyi@GMAIL.COM> 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.
>
> I'm in favor of this, it's a much clearer design. I'd also recommend
> removing csoundRegisterDeinitCallback() from the API.
>
> On Tue, Mar 26, 2024 at 10:35 AM Victor Lazzarini
> <Victor.Lazzarini@mu.ie> wrote:
>>
>> Hi all,
>>
>> I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
>> in OENTRY.
>>
>> At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
>> works, it seems a bit awkward.
>>
>> Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
>> be able to reuse it for this purpose. For example,
>>
>> OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};
>>
>> Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.
>>
>> The current deinit routine for an instrument is:
>>
>> /* call the opcode deinitialisation routines of an instrument instance */
>> /* called from deact() in insert.c */
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>    int err = 0;
>>
>>    while (ip->nxtd != NULL) {
>>      opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
>>      err |= dp->func(csound, dp->p);
>>      ip->nxtd = (void*) dp->nxt;
>>      free(dp);
>>    }
>>    return err;
>> }
>>
>> and we would possibly modify it to be something simple like this:
>>
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>   int err = 0;
>>   OPDS dds = (OPDS *) ip;
>>   while ((dds = dds->nxtp) != NULL)
>>    err |= (*dds->dopadr)(csound, dds);
>>   return err;
>> }
>>
>> or thereabouts.
>>
>> Any thoughts?
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>



I have code which, at the moment, needs to register deinit calls dynamically, the actual routine depends on the arguments passed. It can be adapted to using a static callback, so if there is a need to remove the API call, it's fine.  It would be great if deinit is called while the arguments to the opcode are still valid

On Wed, Mar 27, 2024 at 10:06 AM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

We can make sure the deinit happens before the other cleanup if this is important.

Why would we keep the callback? It seems to me that we should offer one way to deinit, not two.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 27 Mar 2024, at 06:12, Eduardo Moguillansky <eduardo.moguillansky@gmail.com> wrote:



Please don't remove the API call.

 One thing that is not clear about deinitialization is what is guaranteed to exist at this point. For example, should  an opcode be able to read its arguments at this point? For example I tried implementing a "defer" opcode, somewhat similar to go's defer, and found that reading input arguments could lead to invalid memory access.

On Wed, Mar 27, 2024, 00:31 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for the feedback, Mike and Steven.
I’ll get to that soon. It should not be too difficult.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 26 Mar 2024, at 19:33, Steven Yi <stevenyi@GMAIL.COM> 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.
>
> I'm in favor of this, it's a much clearer design. I'd also recommend
> removing csoundRegisterDeinitCallback() from the API.
>
> On Tue, Mar 26, 2024 at 10:35 AM Victor Lazzarini
> <Victor.Lazzarini@mu.ie> wrote:
>>
>> Hi all,
>>
>> I have been thinking that we could regularise the opcode api by adding an (optional) deinit field
>> in OENTRY.
>>
>> At the moment, opcodes requiring deinit need to explicitly register a callback with Csound. While this
>> works, it seems a bit awkward.
>>
>> Since we have already removed the use for the “a” function field in the OENTRY, I thought we may
>> be able to reuse it for this purpose. For example,
>>
>> OENTRY o = { “name”, S(STATE), 0,  3,  "a",  “aki", init_func, perf_func, deinit_func};
>>
>> Not all opcode need this, but for the ones who do, this seems a more natural way to set it up.
>>
>> The current deinit routine for an instrument is:
>>
>> /* call the opcode deinitialisation routines of an instrument instance */
>> /* called from deact() in insert.c */
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>    int err = 0;
>>
>>    while (ip->nxtd != NULL) {
>>      opcodeDeinit_t  *dp = (opcodeDeinit_t*) ip->nxtd;
>>      err |= dp->func(csound, dp->p);
>>      ip->nxtd = (void*) dp->nxt;
>>      free(dp);
>>    }
>>    return err;
>> }
>>
>> and we would possibly modify it to be something simple like this:
>>
>> int csoundDeinitialiseOpcodes(CSOUND *csound, INSDS *ip)
>> {
>>   int err = 0;
>>   OPDS dds = (OPDS *) ip;
>>   while ((dds = dds->nxtp) != NULL)
>>    err |= (*dds->dopadr)(csound, dds);
>>   return err;
>> }
>>
>> or thereabouts.
>>
>> Any thoughts?
>> ========================
>> Prof. Victor Lazzarini
>> Maynooth University
>> Ireland
>>