Post by nonjohn on Jul 2, 2018 21:13:15 GMT
Nic,
I tried the hold counter code inserted after the DT. It certainly can stop stuck notes, but as it requires that I stop playing all notes to get the stuck notes to stop, it doesn't really achieve the functionality I am looking for.
I hope I am not making this more complicated than necessary, but it seems that to prevent stuck notes when placed after "A, B, C, D, etc to A" mappings, all the DT module needs to do is to keep track of the total number of unresolved instances of Note-ons for "A". This is what I had previously described as an "Instances" variable.
So if the DT module was altered in the way I envision, it would continue to store the delta transposition values of each of the 128 MIDI note numbers, but would incorporate 128 "Instances" variables, one for each of the 128 possible MIDI Note numbers.
The 128 "instances" variables would allow the DT module to keep track of how many Note-offs need to be sent to prevent a given MIDI note number from becoming a stuck note.
So, for example, here are two examples of how the altered DT module would function:
If I have mapped MIDI notes A, B, and C onto A and the DT module is currently set at zero transposition, and then I play notes A,B, and C, the DT will received three instances of note-ons for A. Since the current tranpose value was set to zero, a delta of zero would be stored for note A, and the DT module would send out 3 note on events for note A. Also, the instances variable for A would be incremented by 3. If I released note C, the DT module would sent out a note-off for note A, and decrement the "Instances" variable for A from 3 to 2. As the A and B keys were subsequently released, two more note offs for A would be sent and the Instances variable for A would be decremented from 2 back to zero.
If the the DT module were to receive an isolated note-off for a note that already has an "Instances" variable of value zero, the DT module would need to know to NOT decrement that note's "Instances" variable below zero.
In a second example, let's say I have mapped MIDI notes A, B, and C onto A and the DT module is currently set at +1 transposition, and then I play notes A,B, and C, the DT will received three instances of note-ons for A. Since the current tranpose value was set to +1, a delta of +1 would be stored for note A, and the DT module would send out 3 note on events for note A Sharp. Also, the instances variable for A sharp would be incremented by 3. If I released note C, the DT module would sent out a note-off for note A Sharp, and decrement the "Instances" variable for A Sharp from 3 to 2. As the A and B keys were subsequently released, two more note offs for A Sharp would be sent and the Instances variable for A Sharp would be decremented from 2 back to zero.
The DT module does not need to "know" how the receiving sound module will apply each note off that the DT sends. Rather, the DT module only needs to have a book-keeping method, so that ultimately, for each of the 128 MIDI note number, DT ultimately sends out (when keys are released) a number of note offs for a given MIDI note number that is exactly equal to the number of note ons that DT has sent out for that same MIDI note number.
Maybe there is a simpler way to do this, but at this time I cannot conceive of what it would be.
If there is any way the DT code can be altered to add 128 "instances" variables for each of the potable MIDI note numbers, while at the same time continuing to maintain the storage of the 128 delta variables, I think DT can maintain full functionality even when being placed after a remapping in which multiple MIDI note have been mapped to the same MIDI note number. And not having to release all notes on a keyboard to stop stuck notes would be most welcome. That is, in many instances, I want to hold down a chord in one key, send a transpose command, and then play notes in another key, while still holding the non-transposed chord.
Nic, thanks for any help you can lend in helping to create a special version of the DT module that incorporates 128 "instances" variables.
With continued appreciation,
John
I tried the hold counter code inserted after the DT. It certainly can stop stuck notes, but as it requires that I stop playing all notes to get the stuck notes to stop, it doesn't really achieve the functionality I am looking for.
I hope I am not making this more complicated than necessary, but it seems that to prevent stuck notes when placed after "A, B, C, D, etc to A" mappings, all the DT module needs to do is to keep track of the total number of unresolved instances of Note-ons for "A". This is what I had previously described as an "Instances" variable.
So if the DT module was altered in the way I envision, it would continue to store the delta transposition values of each of the 128 MIDI note numbers, but would incorporate 128 "Instances" variables, one for each of the 128 possible MIDI Note numbers.
The 128 "instances" variables would allow the DT module to keep track of how many Note-offs need to be sent to prevent a given MIDI note number from becoming a stuck note.
So, for example, here are two examples of how the altered DT module would function:
If I have mapped MIDI notes A, B, and C onto A and the DT module is currently set at zero transposition, and then I play notes A,B, and C, the DT will received three instances of note-ons for A. Since the current tranpose value was set to zero, a delta of zero would be stored for note A, and the DT module would send out 3 note on events for note A. Also, the instances variable for A would be incremented by 3. If I released note C, the DT module would sent out a note-off for note A, and decrement the "Instances" variable for A from 3 to 2. As the A and B keys were subsequently released, two more note offs for A would be sent and the Instances variable for A would be decremented from 2 back to zero.
If the the DT module were to receive an isolated note-off for a note that already has an "Instances" variable of value zero, the DT module would need to know to NOT decrement that note's "Instances" variable below zero.
In a second example, let's say I have mapped MIDI notes A, B, and C onto A and the DT module is currently set at +1 transposition, and then I play notes A,B, and C, the DT will received three instances of note-ons for A. Since the current tranpose value was set to +1, a delta of +1 would be stored for note A, and the DT module would send out 3 note on events for note A Sharp. Also, the instances variable for A sharp would be incremented by 3. If I released note C, the DT module would sent out a note-off for note A Sharp, and decrement the "Instances" variable for A Sharp from 3 to 2. As the A and B keys were subsequently released, two more note offs for A Sharp would be sent and the Instances variable for A Sharp would be decremented from 2 back to zero.
The DT module does not need to "know" how the receiving sound module will apply each note off that the DT sends. Rather, the DT module only needs to have a book-keeping method, so that ultimately, for each of the 128 MIDI note number, DT ultimately sends out (when keys are released) a number of note offs for a given MIDI note number that is exactly equal to the number of note ons that DT has sent out for that same MIDI note number.
Maybe there is a simpler way to do this, but at this time I cannot conceive of what it would be.
If there is any way the DT code can be altered to add 128 "instances" variables for each of the potable MIDI note numbers, while at the same time continuing to maintain the storage of the 128 delta variables, I think DT can maintain full functionality even when being placed after a remapping in which multiple MIDI note have been mapped to the same MIDI note number. And not having to release all notes on a keyboard to stop stuck notes would be most welcome. That is, in many instances, I want to hold down a chord in one key, send a transpose command, and then play notes in another key, while still holding the non-transposed chord.
Nic, thanks for any help you can lend in helping to create a special version of the DT module that incorporates 128 "instances" variables.
With continued appreciation,
John