< Back to IRCAM Forum

killall

Antescofo
#1

antescofo::killall seems to abort all actions (besides running processes) up to the event where the command is issued, regardless whether the actions should have been performed before or after the killall (i.e. also actions which have a delay which schedules them to be performed later). The function contract in Antescofo Reference however reads: “abort all running processes and actions”. Is it intended that this includes actions which are not yet running but are only scheduled under the same event?

By the way, when will Antescofo 1.0, which had been announced during the Ateliers du Forum in March, finally be available for IRCAM Forum members? Jean-Louis Giavitto mentioned some very interesting new features…

#2

Hello Kyl.

Yes, the semantics of antescofo::killall is to abort all action that have been triggered, including those that are waiting the expiration of a delay. The qualifier ‘running’ may be misleading but it means to include all pending computations. Notice also that antescofo::killall inhibit the triggering of the @abort clauses.
You can use abort on a process (or a group, loop, …) identifier to kill all instances of this process (group, loop, …). Or you can use the exe associated to a running process to specifically kill this instance.
However, you will face the same problem: the kill of a process will also cancel all planned actions. As a matter of fact, all the computations spanned by a process can be flattened into a timed sequence of elementary instantaneous actions. Cancelling a process (an instantaneous action) at instant t, means cancel all actions that have a date t’ ≥ t.

Antescofo 1.0 is a major release which has implied a lot of recoding. The beta version is currently under test and will be available before the summer, I think.

#3

Hello Jean-Louis,

thank you for the clarification. I’m using the killall command in initialisations which are conditionally executed after a fast-forward to a rehearsal mark (see also topic loops-and-fast-forwarding). It can be quite hard in this situation to determine which loops or iterations (e.g. curves) are currently running. On the other side, fast-forwarding (i.e. antescofo::startfromlabel instead of antescofo::gotolabel) is needed for the use case because of some global variables in my score which should be updated up from the beginning (e.g. cue points into sample buffers). Well, now I understand that antescofo::killall should be the last statement under the event with the rehearsal mark label, and all other initialisations should have completed at that point.

The announcements of 1.0 are very intriguing, so I’m almost impatient…