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

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- 
> dmarc-request@listserv.heanet.ie  request@listserv.heanet.ie>> 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
> 

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  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- dmarc-request@listserv.heanet.ie > 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

Btw, in Csound 7, subinstr have been superseded. 
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 14 Jul 2025, at 14:32, joachim heintz  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- dmarc-request@listserv.heanet.ie > 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