Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] opcode deinit

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 <[email protected]>
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 <
> [email protected]> 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 <[email protected]>
> 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 <[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.
>> >
>> > 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
>> > <[email protected]> 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
>> >>
>>
>>