Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] opcode deinit
Victor Lazzarini <[email protected]>
| Newsgroups | gmane.comp.audio.csound.devel |
|---|---|
| Message-ID | <[email protected]> |
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]<mailto:[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]<mailto:[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]<mailto:[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 >>