Hello c-harl-ie.
It is probably an error but not necessarily a serious one. This message means that the incoming audio has not been processed by the listening machine because lack of time.This audio is stored for later processing. It can be the case if they are some heavy computations (or badly behaved computations) somewhere in Max and few cpu resources remain available.
Is this error transient? That is, is antescofo continue running without more such messages? In this case, for some unknown reasons (some heavy processes running outside Max, glitches in audio processing, a temporary network failure when processing OSC, some objects in your patch that have a spurious burst of activity, etc.) the listening machine is temporary behind in its processing. If there is enough processing power, it will catch-up. During catch-up, some musical events may go unnoticed because the detection of the latest events (those that occurred most recently) are privileged.
These messages appear easily if you are in āAudio Interrupt Modeā (you can check in Max menu Options/Audio Status). It is a bad idea to run in Audio Interrupt Mode. In this mode, all antescofo computations are done in the audio thread. This ensure a maximal timing accuracy, but it will exhaust the time resources allocated to the audio processing and when the listening module access its time slot, there may not be enough computing time left. You should use instead āScheduler in overdriveā mode. In this mode, timing accuracy is a high priority but not at the expense of audio processing.
It can be also caused if you have a very small audio buffer (I/O Vector Size) or a very small Signal Vector Size (both accessible in the audio status window). Small buffer or small Signal Vector Size increase the temporal constraint pressure.
If these messages are reproducible, then try to lighten the patch to see if the problem comes for the load implied by some of the objects you use. The CPU load reported by Max is a good indication. However, it may happen that the processing power is sufficient but the deadlines are still not met due to tricky priorities between the activities of the objects in your patch.
The antescofo object itself is usually lightweight. The processing done within the listening machine is negligible (the functioning of the listening machine alone does not exceed 10% of the CPU processing power reported by Max on my machine). The load may come from the processing of the userās actions in antescofo itself although I have seen this only in case of faulty computations (e.g., non terminating userās function). If you send the āinfoā message to antescofo, you will see on the console some statistics that can help to determine if the antescofo usersās actions are too heavy (take a look at the number of messages sent, to the max length of scheduler triggered computations and to the number of scheduler weak-up: this last number must be normalized wrt to the running time but if it is very high, it means that you are trying to manage too much very small delay, i.e. less than 2ms).
Your message seems to imply that Max was running all night. Did this occurs in the context of a batch processing or a non-real-time processing? Antescofo is not meant to run in non-real-time mode (although it might work).
For the sake of completeness, check that you have a release version and not a debug version : the prints on the Max console at antescofo start-up or when you send the āinfoā message to the object, should show āRelease version, Blablablha, 1.0-xxx ā¦ā and not ādevelopment versionā¦ā. The debug version is at least 10x less efficient than the release version.
