Have an option that can be toggled ON or OFF called Chord Mode - Lock Column Assignment.
since there are 12 columns per track and
since when you trigger 2 samples at the same time with Chord = ON and sample instrument setting NNA = cut and Envelopes / Volume = ON a strange thing happens …
when you trigger the 2 samples for the second time sometimes one of the samples lands in a new column (not its previous triggered column) this has the following effect …
the sample in the new column of course does not CUT or (note off) the previouse instance of this triggered sample and …
creates an overlapping sound (flanging or longer loops play syncopated)
I suggest on option that can be turned ON or OFF that would allow for the first 12 notes starting from C-0 > B-0 to be locked to using the first 12 columns
then the next 12 notes from B-0 > A#1 to be locked to using the first 12 columns again and so on fo the rest of the notes.
this option could be made part of the NNA = Cut function not just a standalone option perhaps?
This would only apply to samples being triggered NOT already recorded (edited) notes
I really believe this is a basic operational function that missing/lacking from the logic of how you would expect notes to behave with a sustain and re-triggered > cut
For very short samples this is not a problem since the playback of a sound over itself really does not have time to occur. But for samples that last seconds or minutes and only require to be triggered (toggled) on to play through to its end without having to hold the key pressed or midi note pressed, this its simply ludicrous to think that the logic to cut and re-trigger does not work.
As discussed in the linked thread above, Im not sure if the code changes that would be required to accomplish this would break anything, … but since turning Chord mode ON or OFF in a recorded song does not really break or change anything in that song (correct me if Im wrong) then why would new notes assigned to columns do any different?
I have tried to accomplish something similar in LUA by turning on OSC like in DUPLEX and having pads midi mappable assigned to each note, and triggered in set tracks (i.e Chord =OFF and Pad1 = track1, note C4/ Pad2 = track2, note C#4 ). Does not work properly, sometimes when 2 samples are triggered too quickly it only plays 1. So basically not possible by myself in LUA.
If you are manually editing your songs by typing them in a step edit style then this wont effect you. If you are editing a song while the song is in playback mode (I call this recording) or if you perform in a live way with midi devices or trigger from your computer keyboard then you will know the pain and ineffectiveness of renoise to handle this scenario.
Please help and join me in requesting this option. .
I think you dont get it because you use edit mode and then choose where to put the notes…
if you put the song into playback and edit mode and follow the instructions above … using a midi controller keyboard/pads or computer keyboard for “playing” notes
you will see what I mean…
try it for yourself you will discover that it will not behave as logically expected because renoise always chooses to place the last note played in the first column when chord mode is on and the note is triggered again … you can only tell this is happening if the sample volume envelope is sustained and the sample long enough…
eg…
NNA set to CUT
CHORD mode is ON
song is in playback edit MODE (actually happens even with out playback or edit mode you just cant see visually whats happening)
2 samples LOADED on separate notes
the instrument VOLUME envelope is ENABLED
the instrument VOLUME ENVELOPE is set to MAXIMUM with 1 point
TRIGGER both samples at the same time
**before they finish playing TRIGGER both samples again (repeat)
?? they should both cancel the previous triggered instance, but they dont always ??
say we have a kick with a long tail in sample slot1
and a hi hat with a long tail in sample slot2
and we want to trigger them together
BUT when we trigger them together again we want them to CUT the previously playing instance of both they instead play over the top…randomly (sometimes sample1 will cut not 2 and other times the other way around and sometimes both will cut)
renoise looks at the last note triggered and places that in the first column.
The problem with auto-sorting chords is the way that they’re played and may overlap or progress in places means a simple ordering of lowest-highest may not always be possible without changing how it was played. This has been discussed a few times if you search similar threads.
For drums I can see a related idea being a good step towards making live playing a lot more enjoyable and realistic. The ability to assign a Keyzone to a Note Column. With different types of drums this could effectively give you Mute Groups, so different hats assigned to the same column would mute each other but kicks and snares would be elsewhere etc.
You would still only be able to play them in the same track so the same effects would be applied to all but still an advance in the right direction.
Possibly a mode which always keeps columns dedicated to a single note, lowest on the left if live recording, may be possible. If you play more than 12 notes then a secondary track is made and both are moved into a Group containing the effects of the original.
“Possibly a mode which always keeps columns dedicated to a single note, lowest on the left if live recording, may be possible. If you play more than 12 notes then a secondary track is made and both are moved into a Group containing the effects of the original.”
My ground idea was enumerating the complete track contents into a multidimensional array:
track[x][entry][colz]
colz had the following entities:
track[x][entry][colz][row]
track[x][entry][colz][noteval]
track[x][entry][colz][noteoff_row]
track[x][entry][colz][noteoff_val]
If the noteval was a noteoff, its value would be stored to the last found note of that notecolumn (track[x][entry-1][colz][noteoff_row]= cur_row)
The noteoff itself should not be stored in the table as a noteval since you want to sort on notevalue and not include the note-off value in the sorting.
So far so good.
Now here comes the complicated stuff:
Notes can also be terminated by other other notes, these notes have to be sorted as well, ofcourse for this the noteoff_val has been thought out (so that you can do something if the case of termination is a true note off or a new note: track[x][entry-1][colz][noteoff_row]= cur_row, (track[x][entry-1][colz][noteoff_val]= cur_noteval))
However in this case, you have to be very careful how you sort those notes because perhaps you are not allowed to cut off one of the previous triggered notes, which would mean that you would get chords still not sorted out neatly in adjacent columns.
Another thing is: notes can also be cut off using note cut commands in either pan or volume column, or even in the effect column. Well, i don’t really see much problems in these perhaps that we only end up with some generated note-off symbols where they would actually don’t serve any purpose.
I can tell you at least this:Doing this live looks quite impossible when observing that post processing itself is already not quite as simple as we might think.
