exit(1) :)

[smoothdeveloper]

j'ai vu passer ça:

libMidifilePerformer/src/core/Renderer.h

Lines 151 to 165 in fe66230

	throw std::runtime_error("INVALID MAP ENTRY FOR KEY");
	} catch (std::runtime_error e) {
	// Original idea (early 2022) :
	// This can only happen if two controllers pressed the same key on the same channel
	// This should not happen
	// Update 08/07/22 ; this is FAR more common than we thought.
	// For example, this happens if the system is launched with a key already held;
	// The release of that key will trigger the exception because no note was associated with the key.
	// This causes an instant segfault in the ossia binding.
	// So the question is, should we keep it that way ?
	std::cout << e.what() << std::endl;
	exit(1);
	}

peut être il faudrait modéliser les types de cas d'erreur que l'algorithme rencontre (LogicError), et plutôt que de lancer une exception, router ça vers un handler (std::function?).

Le composant ou application qui intègre la librairie peut alors attacher son propre écouteur et décider si exit(1) est le bon choix, ou d'autres alternatives.

[smoothdeveloper]

pour le cas précis, de deux instruments midi qui envoient un même note-off, il faut peut être garder l'état des notes reçues dans un registre, et ne le mettre à jour via note-off, que si la note était déjà on dans le registre?

[josephlarralde]

Ça me rappelle une discussion récente dans #8 :)
Le problème de ce cas précis est également discuté dans #6 : je pense qu'il n'y a pas lieu de lancer une exception mais plutôt accomoder l'algorithme pour soit permettre la polyphonie sur une même note (avec une pile / file des doublons et les commandes associées), ou faire ce que tu dis et que je suggère aussi dans #6

Pour les autres cas d'erreur l'idée est la bonne, mais pour l'instant j'ai l'impression qu'on n'a pas encore suffisamment de cas d'erreurs pour mettre en place un tel système.