[fixed in v0.102] Hanging notes...pfm3

[Xavier]

Thanks for the clear explanation.
I played a little with the synth, I never got a hanging note!
This is a great improvement, thanks!

Cool  !
Thanks for the report and the test !

As for the mono handling of multiple notes, is there a reason it depends on glide?
You could turn on all of this simply if a patch is set to mono independently of glide, no?

So you would want glide="Overlap" by default for mono patch. It wouldn't add any feature, just a different approach.
Maybe it's a bit confusing, but it's always difficult to change that kind of thing without breaking compatibility with previous patches.

I still get some missing notes and I guess it happens, when more then two notes are on. Would you consider a buffer for mono handling? It could contain maybe the last 5 notes...

I don't consider changing the behaviour for the moment.
I'll definitely take a look if you have missing notes. But for the moment i don't understand from your description when it occurs and what is the problem.

[lokki]

No I would leave glide off by default. But I would enable the bounce back to a previously held key and the non retriggering of the adsr in mono.

I get the feeling that for you glide, adsr triggering etc. are somehow related to each other, but they are really separate.

You might want a mono sound with no glide, but still no retriggering adsr on over lapping notes and most definitely it should bounce back to the pitch of the least recently used key when you release one.

So the golden solution would be settings for mono mode:

Glide off/on/overlap
Adsr retrigger: on/off
Note priority: last/highest/lowest (but for this you need a buffer)

This gives the most freedom, but I get that pfm3 is not a mono synth primarily.

As for the missing notes:

I will try to find a pattern, and a way for you to reproduce it.

I think it happens when I have more then two keys held down, but I will investigate further...

[lokki]

ok, i just sent you a PD patch to show one of the problems i am having with lost notes. as it only happens with rather short notes, i guess it comes from your fix to disregard notes that do not yet sound...

here is some code from axoloti (from the object that handles monophonic incoming midi, with the held down keys saved in an array, and simply ordered by a counter (p++) once a key is released, the code scans the whole array and finds the least recently used key (the one with the highest number stored and plays that. i don't want to "lecture" you or something, but i really would like a proper mono handling on preenfm3, since in this state it does not work correctly for me. and since i know for a fact that many synths do it like on axoloti (or very similar) i thought i post it as an example...

Code: [Select]

if ((status == MIDI_NOTE_ON + attr_midichannel) && (data2)) {
  if ((data1 >= attr_startNote)&&(data1 <= attr_endNote)) {
    _velo = data2;
    _note = data1-64;
    _gate = 1<<27;
    _gate2 = 0;
    np[data1-attr_startNote]=p++;
  }
} else if (((status == MIDI_NOTE_ON + attr_midichannel) && (!data2))||
          (status == MIDI_NOTE_OFF + attr_midichannel)) {
if ((data1 >= attr_startNote)&&(data1 <= attr_endNote)) {
   _rvelo = data2;
np[data1-attr_startNote]=0;
int j;
int np2 = 0;
int n2 = 0;
for(j=0;j<attr_endNote-attr_startNote+1;j++){
   if (np[j]>np2) {
      np2=np[j];
      n2 = j;
   }
}
if (n2>0) {
  int nn = n2+attr_startNote-64;
  if (nn != _note) {
    _gate2 = 0;
    _note = nn;
  }
}
else _gate = 0;
}
} else if ((status == attr_midichannel + MIDI_CONTROL_CHANGE)&&(data1 == MIDI_C_ALL_NOTES_OFF)) {
  _gate = 0;
}

those attr_* "variables" are actually constants that you can choose before you compile a program.
_gate is only triggered on non legato playing, _gate2 is always triggered when a new note is played.
_note contains the pitch obviously
np[] is the array that contains the notes played if non zero and also the order in which they were depressed.


is there a "simple" way to implement something like this within the preenfm3 eco-system? if you point me to the right direction i can also have a look myself. will try to install the cube stuff to compile the firmware.

thanks for considering.

[Xavier]

Hi,

So when you release the key that triggered the playing note, it loops and compare through the 127 (most of the time) np values to retrieve which one was the latest pressed key before this one.
The preenfm3 can have 5 other instruments playing many notes, a high note on/of activity on the other instruments,  and a high CPU usage, so i'm not a big fan of this loop.
It should be possible to have an array of struct that simulate a linked list for better performance and limiting the number of notes in the buffer to 10 (we have 10 fingers )
This mono change would also likely require to modify the "glide" algo to work with this new behavior.

Importing the project in STM32CubeIde should be very easy, you'll have 3 projects (firmware, bootloader, lib).
You'll find some debug config to upload the firmware and debug.
It works very well with any STLink board.
The one i used the most is a part of a nucleo board that i cut and make a nice small STLink 2.1.
4 wires to the SWD pins on the pfm mother board, and that's it.
Upload is very fast, and debugging (breakpoint and watching variables) is very easy.

You can also, create the bin (look in "scripts" folder) and upload through DFU but it's much much longer.

[lokki]

Yes, I thought about those 6x problem as well. A buffer of 10 notes would already be great!

For the moment I don't have a stlink board. Can I still compile and upload via DFU?

[Xavier]

For the moment I don't have a stlink board. Can I still compile and upload via DFU?

Yes, but it's slow to upload, and your only debugging tool will be to display values on the display.
Go in "/scripts/" folder and run create_object_debug.sh, you should get your firmware bin file.

[Xavier]

.. and what you want to look at is in Timbre.cpp : preenNoteOn and preenNoteOff.

[lokki]

Just tried v. 0.102.

it is again better, there are only a few missing notes still. they all happen, when there are notes overlapping, never when only one note is held down. I will again try to find a way to reproduce this on PD or similar. Never got a hanging note! Great work...

I will try to make some sense of timbre.cpp to see if I can implement something.

Your solution with a buffer of 10 notes (a 2d array with not pitch and timestamp?) Sounds very reasonable...

[lokki]

ok, for now i could not wrap my head around it. maybe it will be easier just to add a small buffer (10 notes as you suggest) to the glide part of the code?