Antescofo 1.0 vs 0.92

[algH]

Hi,
I have begun, a few months ago, a new Max Patch with Antescofo 0.92 that works fine. Now, I have downloaded the new Antescofo version (1.0) and I’m testing it on the same patch. When I ask Antescofo to jump to a label in the score the Max window reports a message like this : “antescofo~: Cowardly refuse to send 8774 messages: keep the first 512”
I understand that my score messages or curves are partially send.
In the normal reading (from the score beginning) I have been constrained, with 1.0 version, to change my curves grain attribut from 10ms to 50ms or 60ms.

Thanks for your help.

Cheers, Henri

[giavitto]

Hello algH.

Antescofo is reluctant to send too much messages to Max, because a burst of messages may lead Max to crash. The exact behavior depends of the kind of objects addressed by the messages, the priorities, the kind of messages (i.e. if they are send in response to a Max message, as a computation triggered by the exhaustion of a delay, as a computation triggered by a musical event detection), etc.

If your object is recent enough, you can change (at your own risk) the Antescofo limit with the function :

       @set_max_message_sent_instantaneously(xxxx)

where xxxx is the new limit (an integer). If you change this limit, consider enlarging the Pooll Throthle and the Queue Throtle in Max’s preferences.

If this function is unknown with your object, I can send you a more recent version of the antescofo object. The version 1.1 will be available in jully.

[algH]

Thanks for your reply Jean-Louis !

[baskind]

Dear all,

let me try to reactivate this post, since I have exactly the same problem: I’m aware of the @set_max_message_sent_instantaneously message and tried to put it with 4000 as argument in my score text file. This is recognized by Antescofo, since I don’t get an error message “antescofo~: Unknown function XXX in cpu domain ‘default’”.

But nothing happens, I mean I still get the error message “Cowardly refuse to send YYY messages: keep the first 512”.

Poll and queue throttle set to 2000, so it’s not the issue.

Any clue?

If this can help, here is a minimal patch that reproduces the problem:

Bug Antescofo.zip (13.8 KB)

Besides that: why is it required in the external to dump the whole score in one event tick? Wouldn’t it be possible to stack messages for bach.roll and deliver them defered at a slower pace?

Thanks in advance for the help!

Alexis

[giavitto]

Hello.
There is a typo in the score. You have written

@set_max_message_sent_instantaneouslySS(4000)

with two ‘S’ which does not exist. A message on the console signal the error

.

However, this is not the problem. The function call is not evaluated when loading the score, so the limit is not upgraded whn you trigger the bachscore message. It is easy to evaluate it by simply using a playstring message before the bachscore message in your patch

You can also use a eval_when_load section.

Jean-Louis.

PS : For the more general question of why we do not use several ticks, it is because the handling of the message bachscore is just a wrapping of the @bach_score function. And a function evaluation is “instantaneous” (i.e. takes place in one tick). Using the increases of the max message limits, this is not a constraint.
An alternative would have been to write a process. But for now, Antescofo provides only a predefined library of functions, not processes. Developing a standard library of useful processes for Antescofo is definitively a good idea, but the efficient representation of processes (beyond their coding in plain Antescofo) is a question (that said, using the @bach_score function it is almost immediate to write this process in Antescofo).
I will be happy to know what kind of standard processes would be relevant and useful for the Antescofo users.

[baskind]

Hi Jean-Louis,

thanks for the super-quick and informative answer, this is exactly what I needed. Now it works!

The typo was not a real one, actually I changed the name of the function in the score to be sure that it’s being actually read by antescofo… and I forgot to revert before sending.

Good to know for the playstring and eval_when_load commands. I guess it would be good to extend the doc accordingly, I’m sure not the only one having to deal with big scores.

Regarding the way the message are being sent (tick or process etc…): I’m not a professional C/C++ developer, so please pardon me in advance if I say nonsense. Surely a separate process is the cleanest solution, especially since sync between processes is here not an issue. But: wouldn’t it be possible to send a series of defered messages using a big stack and the defer() or defer_low() functions of the Max API? The “bachscore” message could trigger a first series of 512 messages immediately, and, if there are more, create a defered send with the next 512 messages, which itself would create a defered send for the next 512… and so on until the stack is empty (then send a message like “bachscore_dumped” at one output to inform the rest of the patch). It’s a little bit dirtier, but I don’t see any reason why it wouldn’t work, and then they wouldn’t be a need for a dedicated message and for tweaking the Max advanced preferences.

Best wishes,

Alexis