Re: [Csnd-dev] [EXTERNAL] [Csnd-dev] RFC: OENTRY refactor

Eduardo Moguillansky <[email protected]>
Newsgroups gmane.comp.audio.csound.devel
Message-ID <[email protected]>
On 04.01.24 04:34, Steven Yi wrote:
> 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?

What cannot be decided at the moment is if an opcode which has iopadr 
and kopadr acts at init time at all or only performs some internal init. 
This is the case for some string opcodes and some other odd ones.

One thing that I would like to see is the ability of an opcode to report 
the need for asynchronous init, and the ability of the csound process to 
provide that service. At the moment this is only possible with 
--realtime, which has other implications. At the moment, opcodes which 
need to perform some blocking action at init time need to either glitch 
or implement their own threading.

Regarding metadata, it would be nice if an opcode could report the name 
of its args. This should be optional and does not make sense for all 
opcodes, but it could be useful for both error messages and debugging, 
particularly for situations like generating opcodes via faust. For such 
cases it would be nice to have those names listen for some variant of 
`csound -z`


>
> 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.