Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] RFC: OENTRY refactor
Steven Yi <[email protected]>
| Newsgroups | gmane.comp.audio.csound.devel |
|---|---|
| Message-ID | <CANtcCs40wWAtuHiOi1F2ZRR2u7k7kDW3KKXM0O5=t+J+O-2zEQ@mail.gmail.com> |
Now is certainly the time to add/subtract/modify things. What metadata are you thinking of? We can tell if an opcode acts just at init-time now by looking to see if it only has an iopadr (or initFunc as proposed) and no kopadr/aopadr (or perfFunc), then report that. Or am I missing something for that example? I suppose a good way we could work through this is to have some kind of example error message for a given code example then go implement it. On Wed, Jan 3, 2024 at 10:10 PM Eduardo Moguillansky < [email protected]> wrote: > If a refactor of OENTRY is in the works, could there be some discussion to > include some metadata about a given opcode, in order to make reflection or > error messages clearer? For example, at the moment there is no way to tell > if a given opcode acts at init time or only needs some initialization. This > information could be added > > On Wed, Jan 3, 2024, 20:51 Victor Lazzarini <[email protected]> > wrote: > >> Sounds good to me. It’s quite a big change though we’ll need make >> throughout the code to replace all the OENTRY etc >> (we’ll also have to think about the plugins in the plugins repo and >> update those for this). >> >> ======================== >> Prof. Victor Lazzarini >> Maynooth University >> Ireland >> >> > On 3 Jan 2024, at 22:42, 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. >> > Hi All, >> > >> > I was looking at OENTRY and think we can make a change to simplify it >> by: >> > >> > 1. Remove .thread >> > 2. Remove .aopadr >> > 3. Rename .iopadr to initFunc >> > 4. Rename .kopadr to perfFunc >> > >> > There's little code to check ->thread and I think it can be refactored >> to check the presence of initFunc or perfFunc. I think initFunc and >> perfFunc might be a little easier to understand for modern devs vs. iopadr >> and kopadr. >> > >> > Thoughts? >> > >> > Steven >> >>