Hi devs, thanks for the suggestions on the main list. So further to that conversation, I'd like to know if I'm off base in thinking it would just make more consistent sense for overlapping notes that share a fractional inum to be legato automatically if they overlap. It seems to me to be more consistent with the way the rest of things work, and what one would logically expect given they share the same allocation. I do understand (and respect) the prioritization of backwards compatibility, but am wondering if this is a case where no one would have cause to be attached to current behaviour, or where a variant could be opt in with a flag. It would make real-time score feeding systems much cleaner, in my humble opinion. I'm thinking that: 

- if you share a voice allocation  and want non-legato, all one must do is not code in any legato behaviour in the instrument, and it should do what one expects

- if you share a voice allocation and want legato, this would get rid of the (kinda hacky) resorting to negatives or having to resort to notes that believe they last forever and are then forced off.

It would make things a lot easier for realtime systems like csound6~ if we didn't have to resort to negatives, but of course it can be hacked around if this is a non-starter. If we changed this behaviour we could do it with a flag so that one has to opt in to the "fixed" behaviour. I'd like to know people's thoughts though as it might be a fun way for me to get into core. (I guess I could always use my own private fork too.)

thanks for listening

iain

further articulating my thoughts. It seems to me for my proposal to break someone's pience, one would have had to:

a) use fractional inums

b) have deliberately coded in legato behavior into the instr def

c) be expecting non-legato initiation *with* overlapping durations and identical fractional inums, despite having done b.

To me, this seems to be an extremely unlikely case, because it makes so little sense to do all three, but I'm probably revelling in my own ignorance. :-) I actually think "fixing" this issue (even if opt in) would be a big deal for users of csound in Max because the whole advantage of csound (in Max or Pd) is the very different and thus complementary object allocation paradigm. Being able to (more) cleanly control allocations would be pretty nice.

my thoughts from the peanut gallery!

 

On Tue, Apr 26, 2022 at 7:03 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hi devs, thanks for the suggestions on the main list. So further to that conversation, I'd like to know if I'm off base in thinking it would just make more consistent sense for overlapping notes that share a fractional inum to be legato automatically if they overlap. It seems to me to be more consistent with the way the rest of things work, and what one would logically expect given they share the same allocation. I do understand (and respect) the prioritization of backwards compatibility, but am wondering if this is a case where no one would have cause to be attached to current behaviour, or where a variant could be opt in with a flag. It would make real-time score feeding systems much cleaner, in my humble opinion. I'm thinking that: 

- if you share a voice allocation  and want non-legato, all one must do is not code in any legato behaviour in the instrument, and it should do what one expects

- if you share a voice allocation and want legato, this would get rid of the (kinda hacky) resorting to negatives or having to resort to notes that believe they last forever and are then forced off.

It would make things a lot easier for realtime systems like csound6~ if we didn't have to resort to negatives, but of course it can be hacked around if this is a non-starter. If we changed this behaviour we could do it with a flag so that one has to opt in to the "fixed" behaviour. I'd like to know people's thoughts though as it might be a fun way for me to get into core. (I guess I could always use my own private fork too.)

thanks for listening

iain

I'm also from the peanut gallery... (sorry devs)... but...  this behaviour change would break some of my pieces and UDO's. In particular I use envelope UDO's and glissandos for instruments that are flexible for both legato and non-legato instances. They use the negative p3 value that gets passed through. They also use the tival opcode which I wonder would also end up behaving differently?

That all being said, assuming the same functionality can be provided some other way, I could rewrite my pieces. And in general... I do also wish writing legato instruments could be a bit more elegant.

Thorin

 

On Wed, Apr 27, 2022 at 12:12 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

further articulating my thoughts. It seems to me for my proposal to break someone's pience, one would have had to:

a) use fractional inums

b) have deliberately coded in legato behavior into the instr def

c) be expecting non-legato initiation *with* overlapping durations and identical fractional inums, despite having done b.

To me, this seems to be an extremely unlikely case, because it makes so little sense to do all three, but I'm probably revelling in my own ignorance. :-) I actually think "fixing" this issue (even if opt in) would be a big deal for users of csound in Max because the whole advantage of csound (in Max or Pd) is the very different and thus complementary object allocation paradigm. Being able to (more) cleanly control allocations would be pretty nice.

my thoughts from the peanut gallery!

 

On Tue, Apr 26, 2022 at 7:03 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hi devs, thanks for the suggestions on the main list. So further to that conversation, I'd like to know if I'm off base in thinking it would just make more consistent sense for overlapping notes that share a fractional inum to be legato automatically if they overlap. It seems to me to be more consistent with the way the rest of things work, and what one would logically expect given they share the same allocation. I do understand (and respect) the prioritization of backwards compatibility, but am wondering if this is a case where no one would have cause to be attached to current behaviour, or where a variant could be opt in with a flag. It would make real-time score feeding systems much cleaner, in my humble opinion. I'm thinking that: 

- if you share a voice allocation  and want non-legato, all one must do is not code in any legato behaviour in the instrument, and it should do what one expects

- if you share a voice allocation and want legato, this would get rid of the (kinda hacky) resorting to negatives or having to resort to notes that believe they last forever and are then forced off.

It would make things a lot easier for realtime systems like csound6~ if we didn't have to resort to negatives, but of course it can be hacked around if this is a non-starter. If we changed this behaviour we could do it with a flag so that one has to opt in to the "fixed" behaviour. I'd like to know people's thoughts though as it might be a fun way for me to get into core. (I guess I could always use my own private fork too.)

thanks for listening

iain

I don't think this should be done. 

Regards, 

Mike

On Wed, Apr 27, 2022, 04:27 thorin kerr <thorin.kerr@gmail.com> wrote:

I'm also from the peanut gallery... (sorry devs)... but...  this behaviour change would break some of my pieces and UDO's. In particular I use envelope UDO's and glissandos for instruments that are flexible for both legato and non-legato instances. They use the negative p3 value that gets passed through. They also use the tival opcode which I wonder would also end up behaving differently?

That all being said, assuming the same functionality can be provided some other way, I could rewrite my pieces. And in general... I do also wish writing legato instruments could be a bit more elegant.

Thorin

 

On Wed, Apr 27, 2022 at 12:12 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

further articulating my thoughts. It seems to me for my proposal to break someone's pience, one would have had to:

a) use fractional inums

b) have deliberately coded in legato behavior into the instr def

c) be expecting non-legato initiation *with* overlapping durations and identical fractional inums, despite having done b.

To me, this seems to be an extremely unlikely case, because it makes so little sense to do all three, but I'm probably revelling in my own ignorance. :-) I actually think "fixing" this issue (even if opt in) would be a big deal for users of csound in Max because the whole advantage of csound (in Max or Pd) is the very different and thus complementary object allocation paradigm. Being able to (more) cleanly control allocations would be pretty nice.

my thoughts from the peanut gallery!

 

On Tue, Apr 26, 2022 at 7:03 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hi devs, thanks for the suggestions on the main list. So further to that conversation, I'd like to know if I'm off base in thinking it would just make more consistent sense for overlapping notes that share a fractional inum to be legato automatically if they overlap. It seems to me to be more consistent with the way the rest of things work, and what one would logically expect given they share the same allocation. I do understand (and respect) the prioritization of backwards compatibility, but am wondering if this is a case where no one would have cause to be attached to current behaviour, or where a variant could be opt in with a flag. It would make real-time score feeding systems much cleaner, in my humble opinion. I'm thinking that: 

- if you share a voice allocation  and want non-legato, all one must do is not code in any legato behaviour in the instrument, and it should do what one expects

- if you share a voice allocation and want legato, this would get rid of the (kinda hacky) resorting to negatives or having to resort to notes that believe they last forever and are then forced off.

It would make things a lot easier for realtime systems like csound6~ if we didn't have to resort to negatives, but of course it can be hacked around if this is a non-starter. If we changed this behaviour we could do it with a flag so that one has to opt in to the "fixed" behaviour. I'd like to know people's thoughts though as it might be a fun way for me to get into core. (I guess I could always use my own private fork too.)

thanks for listening

iain

I don't think this should be done. 

Regards, 

Mike

On Wed, Apr 27, 2022, 04:27 thorin kerr <thorin.kerr@gmail.com> wrote:

I'm also from the peanut gallery... (sorry devs)... but...  this behaviour change would break some of my pieces and UDO's. In particular I use envelope UDO's and glissandos for instruments that are flexible for both legato and non-legato instances. They use the negative p3 value that gets passed through. They also use the tival opcode which I wonder would also end up behaving differently?

That all being said, assuming the same functionality can be provided some other way, I could rewrite my pieces. And in general... I do also wish writing legato instruments could be a bit more elegant.

Thorin

 

On Wed, Apr 27, 2022 at 12:12 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

further articulating my thoughts. It seems to me for my proposal to break someone's pience, one would have had to:

a) use fractional inums

b) have deliberately coded in legato behavior into the instr def

c) be expecting non-legato initiation *with* overlapping durations and identical fractional inums, despite having done b.

To me, this seems to be an extremely unlikely case, because it makes so little sense to do all three, but I'm probably revelling in my own ignorance. :-) I actually think "fixing" this issue (even if opt in) would be a big deal for users of csound in Max because the whole advantage of csound (in Max or Pd) is the very different and thus complementary object allocation paradigm. Being able to (more) cleanly control allocations would be pretty nice.

my thoughts from the peanut gallery!

 

On Tue, Apr 26, 2022 at 7:03 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hi devs, thanks for the suggestions on the main list. So further to that conversation, I'd like to know if I'm off base in thinking it would just make more consistent sense for overlapping notes that share a fractional inum to be legato automatically if they overlap. It seems to me to be more consistent with the way the rest of things work, and what one would logically expect given they share the same allocation. I do understand (and respect) the prioritization of backwards compatibility, but am wondering if this is a case where no one would have cause to be attached to current behaviour, or where a variant could be opt in with a flag. It would make real-time score feeding systems much cleaner, in my humble opinion. I'm thinking that: 

- if you share a voice allocation  and want non-legato, all one must do is not code in any legato behaviour in the instrument, and it should do what one expects

- if you share a voice allocation and want legato, this would get rid of the (kinda hacky) resorting to negatives or having to resort to notes that believe they last forever and are then forced off.

It would make things a lot easier for realtime systems like csound6~ if we didn't have to resort to negatives, but of course it can be hacked around if this is a non-starter. If we changed this behaviour we could do it with a flag so that one has to opt in to the "fixed" behaviour. I'd like to know people's thoughts though as it might be a fun way for me to get into core. (I guess I could always use my own private fork too.)

thanks for listening

iain