BML Asap

The BMLA extension provides Behavior Realizers with capabilities to incrementally construct ongoing behavior plans and to provides them with on the fly behavior adaptation and (gracious) interruption. Here we present a short overview of the BMLa elements and their syntax. The namespace for BMLA is, we use bmla as the prefix for that namespace throughout this document.

BMLa behavior elements


The bmla:activate behavior activates a preplanned block.

targetstring|requiredid of the target block to activate

Sync attributedescription


<bmla:activate xmlns:bmla="" id="a1" target="bml1"/>


The BMLA interrupt behavior provides the capability of specifying precisely when specific running or scheduled behaviors should be interrupted.

targetstringrequiredid of the target BML block to interrupt
includecomma separated list of stringsoptionalset of behaviors to interrupt in the target BML block (unspecified is all)
excludecomma separated list of stringsoptionalset of behaviors NOT to interrupt in the target BML block (unspecified is none)

Sync attributedescription

Interrupt all behaviors in BML, except bml1:speech1 and bml1:gesture1.

<bmla:interrupt xmlns:bmla="" id="i1" target="bml1" start="shake1:stroke" exclude="speech1,gesture1"/>


The parametervaluechange behavior allows the modification of certain parameter values of ongoing behavior.

targetstringrequiredid of the behavior the parametervaluechange targets
paramIdstringrequiredid of the targeted parameter

Sync attributedescription
start start of the change
end end of the change

Change the volume of bml1:speech1:

<bmla:parametervaluechange xmlns:bmla="" id="p1" target="bml1:speech1" paramId="volume"
start="bml1:speech1:sync1" end="bml1:speech1:sync1+1">
<bmla:trajectory type="linear" targetValue="90"/>

The bmla:parametervaluechange behavior contains a trajectory element that specifies the trajectory and value of the parameter that is changed.

targetValuefloatrequiredtarget value of the parameter
typestringrequiredtype of the trajectory (e.g. linear, instant)
initialValuefloatoptionalstart value of the parameter, if omitted the start value is obtained from the targeted behavior

The parametervaluechange behavior sets the parameter value on the target behavior according to the trajectory, in such a way that the targetValue is reached at the end of the parametervaluechange behavior. The parameter should remain at this value after the parametervaluechange finished (unless new parametervaluechange behaviors overwrite it).

Synchronization to Predicted Events

We allow synchronization to external, possibly predicted events. This does not require an extension of BML, other than allowing a synchronization to reference ids that are not in the BML script. Example: link conducting beat 1, 2 and 3 of a procedural conducting to tick 1, 2 and 3 of a metronome.

<bmlt:procanimation id="conduct1" name="3-beat"/>
<constraint id="c1">
  <synchronize ref="conduct1:start">
    <sync ref="anticipators:metronome1:tick1"/>    	
  <synchronize ref="conduct1:beat2">
    <sync ref="anticipators:metronome1:tick2"/>    	
  <synchronize ref="conduct1:beat3">
    <sync ref="anticipators:metronome1:tick3"/>    	

Preplanning and activation

Scheduling a BML block typically takes a non-negligible amount of time, especially if the timing of speech is to be obtained through speech synthesis software. This is problematic for developing highly responsive virtual humans. BMLa provides pre planning as a mechanism to construct a behavior plan that can be activated later on. In a typical usage scenario of pre-planning, the SAIBA Behavior Planner already knows what behavior to execute, and wants to execute it (near) instantly later on, for example in reaction to some event such as an incoming response from the user. Preplanning is set up for a BML block, using the BMLa preplan attribute in that block. Preplanned BML blocks can be activated using an BMLa activate behavior. The preplanned BML block is activated as soon the activate behavior starts. Preplan bml1:

<bml id="bml1" xmlns:bmla="" bmla:preplan="true">

The BMLA BML attributes

The interrupt shorthand

The interrupt attribute is a shorthand for the SAIBA Behavior Planner to remove a selected set of BML blocks from the multimodal behavior plan before scheduling the content of the BML block it is in. Example:

<bml id="bmlNew" xmlns:bmla="" bmla:interrupt="bml1,bml2,..,bmln">
bmlNew content

This example is a shorthand for:

  1. Send a BML block to the Realizer that interrupts bml1..bmln:
    <bml xmlns:bmla="" id="bmlInterrupt">
      <bmla:interrupt id="interrupt1" target="bml1"/>
      <bmla:interrupt id="interrupt2" target="bml2"/>
      <bmla:interrupt id="interruptn" target="bmln"/>
  2. Wait for block end feedback of bmlInterrupt (to make sure bml1..bmln are properly removed from

the multimodal behavior plan).

  1. Send the new BML block bmlNew:
    <bml id="bmlNew">
    bmlNew content

The onStart shorthand

The onStart attribute is a shorthand for the SAIBA Behavior Planner to activate a selected set of BML blocks in the multimodal behavior plan whenever a certain BML block starts. Example:

<bml id="bmlNew" bmla:onStart="bml1,bml2,..,bmln">
  bmlNew content

This is a shorthand for:

<bml xmlns:bmla="" id="bmlActivate">
  <bmla:activate id="activate1" target="bml1"/>
  <bmla:activate id="activate2" target="bml2"/>
  <bmla:activate id="activaten" target="bmln"/>
  bmlNew content

Composing a behavior plan out of multiple BML blocks

BMLA offers several BML extensions that provide more flexibility and incrementality for Behavior Planners in composing their behavior out of multiple BML blocks.


Chunking allows co-articulation between blocks. A BML block that is chunked after another block, starts as soon as all behaviors in that block are either finished or in their relaxation phase. This allows the behaviors in the new block to fluently connect to the behaviors in the previous block. BML blocks may also be chunked before not-yet-started blocks. chunkBefore and chunkAfter may be use simultaneously, to allow e.g. filler blocks to be inserted between other blocks.

<bml id="bml1" bmla:chunkAfter="bml2,bml3">
<bml xmlns:bmla="" id="bml1" bmla:chunkBefore="bml2,bml3">

Appending and Prepending

BMLA extends BMLs append composition strategy with the ability to specify exactly after which BML blocks the block is to be appended (or prepended).

<bml xmlns:bmla="" id="bml1" bmla:appendAfter="bml2,bml3">
<bml id="bml1" bmla:prependBefore="bml2,bml3">

Deprecated: the notation below is used for compatibility with SmartBody and to support old scripts.

<bml id="bml1" composition=APPEND-AFTER("bml2,bml3")>

Absolute gaze/pointing/... targets

Look towards absolute coordinate (1,0,0):

<gaze target="1,0,0" .../>

BMLA Feedback

Special attributes are introduced in BMLA to specify (predicted) POSIX timestamps of behavior (=number of milliseconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970), in order to more easily provide synchronization with e.g. the Behavior Planner.


The BMLA posixStartTime and posixEndTime are used to indicate the (predicted) POSIX timestamps of a bml block. Example:

<predictionFeedback xmlns=""  xmlns:bmla="">
   <bml id="bml1" globalStart="3.270249043" globalEnd="7.270249043" bmla:posixStartTime="1392983704584" bmla:posixEndTime="1392983708584"/>


The BMLA posixTime attribute indicate the POSIX timestamp of a bml block start/end. For example:

<blockProgress id="bml1:end" globalTime="10.659687042236328"  xmlns:bmla="" bmla:posixTime="1392983711970" xmlns=""/>


The BMLA posixTime attribute indicate the POSIX timestamp of a syncpoint. For example:

<syncPointProgress id="bml1:gesture1:stroke" time="10" globalTime="1111" xmlns:bmla="" bmla:posixTime="1392983711970"/>