If you think of that again, it seems logical that the paste engine does not check for noteoffs.
If you perform a complex mix-paste action how would you expect Renoise to cleverly discover which note-off should be removed and which not?
I see no example which would let Renoise fail when following this procedure:
1] perform complex mix paste
2] for each new note-off, apply the same “InsertSmartOff()” function which gets called on normal note-off insertion
as I have written before, I think that the two-steps procedure described by me should not have problem with your example, anyway the smart note-off’s could also be enabled only when pasting with mix-paste disabled, in which case I really see no reason for which smart note-off’s should not be enabled (other than if it would require a big amount of work for taktik).
The smart thing about the smart note offs is that they will remove unneeded note offs while adding them. The note offs that are inserted are not “marked” as special note offs, but this will just remove unneeded other note offs. So we can not handle them in a special way when pasting them from the clipboard as we dont know which note offs where added as smart ones and which not.
We could add this feature by introducing new note offs, but with the current way of dealing with note offs this is not possible. We can not assume that you always want all note offs to be “smart”.
00 C-4 E-4 G-4
01 --- --- ---
02 off off off
03 --- --- ---
04 C-4 E-4 G-4
05 --- --- ---
06 off off off
07 --- --- ---
08 C-4 E-4 G-4
09 --- --- ---
10 off off off
11 --- --- ---
and I wanted to move all note-off’s one row below:
00 C-4 E-4 G-4
01 --- --- ---
02 --- --- ---
03 off off off
04 C-4 E-4 G-4
05 --- --- ---
06 --- --- ---
07 off off off
08 C-4 E-4 G-4
09 --- --- ---
10 --- --- ---
11 off off off
so I copied the three note-off’s from line 02 and started pasting them to 03, 07 and 11, expecting to see those on 02, 06 and 10 removed automatically by smart note-off mechanism, but it didn’t happen.
this would have been quite handy, but of course it’s not a big deal.
I thought you had some kind of “onNewNoteOff()” trigger which parsed the whole column to see if there were other note-off’s to be removed, but if it is not like this I understand it can be hard to implement this, so you can mark this as a [wontfix]
If its OK to always handle all NoteOffs as smart NoteOffs (I am not sure if it really is), this can of course be more or less easily fixed/added/whatever.
No, please no option for this. Either we go for it or not. An option is just too much detail - more things we have to explain to the user.
The only thing where I can imagine that this could cause problems, is that you get confused when pasting suddenly/sometimes results into something different than what you’ve copied before.
I personally don’t mind we leave the option out, but there is still a lot to explain to the user, your imagination already confirms this.
And it is not that i personally mind things, but i want to prevent situations like what happened after statically setting the “always chordmode/keyjazz on” situation which in short is: The developer determines what a user gets but 50% or more of all users rather would have seen the behavior different.
fmpov I’ld rather point someone who asks a question about how to change this option to a screenshot with options than telling the person the behavior is fixed / limited.
smart note-off could be confusing for the same reason, I think, so once one has got the idea about smart note-off mechanism, he should not have problems understanding that it also works on pasting; it should be a logical consequence, actually.
would be good to have other opinions about this concept, does anyone else want to join the debate?