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 >