Unpredictable behavior in play_setVoiceParameter_path

[goofy2k]

When adding a third note to the sequencing loop in play_setVoiceParam_path (approx line 849 in faust_mqtt_tcp5_v1\main), the program seems to hang. The routine is started, but also the first two notes are not played after adding the third! The program does not hang really. It does receive and display MQTT messages.

This is all at ESP-logging level INFO.

When the logging level is increased to VERBOSE, the loop plays with three notes ! ??????? And even withs six

• interaction with logging level
  • stack problem?
  • timing problem?
  • what if logging is off?

VERBOSE level the does not "repair" defective the play_keys routine
Test with logging only ERRORS or None ongoing....

Both routines play well at ERROR level debugging. No logging not tested as this is not a viable solution.

[goofy2k]

The behaviour may have to do with the use of vTaskDelay for determining note duration. This method blocks other tasks. See mai notes from Oct 5th

[goofy2k]

• A potential solution may be to specify software timers and switch note status in the callback function of the timer when it expires.
• Try to find a way how to deal with a complete sequence of notes.
• Maybe the timer for the next note must be defined when the previous is expired. BUT: this may be too late for overlapping notes.
• BETTER: sort the notes on their start time and define timers in that order....

[goofy2k]

The solution for the hanging code is: do not use vTaskDelay. This is blocking other freeRTOS tasks. For playing a sequence of non-overlapping notes, use the self-defined non-blocking function nbDelay (as of faust_mqtt_tcp5_v1). It was tested in sequence playing procedures ending with _nb and found OK for non-overlapping notes. These routines now play the sequence independent of the logging level!