Re: [Csnd-dev] subinstr

vlz <[email protected]>
Newsgroups gmane.comp.audio.csound.devel
Message-ID <[email protected]>
Well, it does for the code that has used it. It's a dead-end for development, hence my suggestion.


Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Jul 2025, at 14:32, joachim heintz <[email protected]> wrote:
> 
> i understand your both positions, but i am not sure that the subinstr feature can really be substituted by UDO.
> i remember many years ago alex hofmann and me discussed csound code with a particular effects chain, and subinstr was the only feature we could find to do that.
> i also guess that there are a number of people using subinstr which never wrote a single UDO.
> as the backwards compatibility promise of csound (at least when there is no third party library involved) is so central and important, i think we should be very cautious here.
> 
>> On 14/07/2025 15:06, Eduardo Moguillansky wrote:
>> Keeping code which does not work properly is not really keeping backwards compatibility. I would argue that the best way forward is to mark subinstrs as deprecated and, eventually, remove the code from new versions. Anyone depending on that feature can always adapt the code to use udos or dig an old release.
>> On Mon, Jul 14, 2025 at 10:34 AM Victor Lazzarini <000010b17ddd988e- [email protected] <mailto:000010b17ddd988e-dmarc- [email protected]>> wrote:
>>    I was looking at an issue just opened on subinstr, and I was
>>    wondering whether we could mark it as deprecated (but of course keep
>>    it in the code).
>>    This was introduced before UDOs, which do a much better job, and now
>>    with Csound 7.0, instruments are more flexibly handled.
>>    Trying to keep patching it to behave correctly takes a lot of
>>    effort, as the design was not great to start with.
>>    Victor
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.