From Buzztard

[edit] ensonic

1) audio-plugins elements that implement the tempo-iface, will set the
   control-rate according to tempo, other elements set e.g. sampling-rate/10
   (do this in start())
2) the default control-rate should be -1 (GST_CLOCKTIME_NONE)
3) when going to playing the baseclasses
3.1) check if there is a controller set for the object (self->priv->controller)
3.2) if yes, for audio they check control-rate
4) when playing if self->priv->controller the baseclasses
4.1) if control-rate!=-1 segment the processing loop
4.1.1) call gst_controller_sync_values
4.1.2) call create()/transform()

[edit] slomo

1) tempo interface is implemented in elements, but elements don't set control-rate
2) default control-rate == -1
3) when going to playing the baseclasses
3.1) check if there is a controller set for the object (self->priv->controller)
3.1.1) if yes, for audio they check control-rate
3.1.2) if control-rate == -1
3.1.2.1) check if the element implements tempo and use control-rate base on that
3.1.2.2) otherwise use some sensible default (sampling-rate/10), maybe dependent on interpolation-mode
4) when playing if self->priv->controller the baseclasses
4.1) call suggest_next_sync()
4.1.1) get control-rate
4.1.2) interpolation-mode dependent check if an earlier sync is needed.
       trigger could check if there is a event out of the control-rate grid
4.2) segment the processing loop
4.2.1) call gst_controller_sync_values
4.2.2) call create()/transform()

[edit] slomo 2

1) tempo interface is implemented in elements, but elements don't set control-rate
2) controller has default control-rate == -1
3) whenever gst_tempo_change_tempo() is called it sets the control-rate of the corresponding
   controller to some sensible value based on the tempo being set
4) when going to playing the baseclasses
4.1) check if there is a controller set for the object (self->priv->controller)
4.1.1) if yes, for audio they check control-rate
4.1.2) if control-rate == -1
4.1.2.1) use some sensible default (sampling-rate/10), maybe dependent on interpolation-mode
5) when playing if self->priv->controller the baseclasses
5.1) call suggest_next_sync()
5.1.1) get control-rate
5.1.2) interpolation-mode dependent check if an earlier sync is needed.
       trigger could check if there is a event out of the control-rate grid
5.2) segment the processing loop
5.2.1) call gst_controller_sync_values
5.2.2) call create()/transform()

[edit] ideas

• for ensonic-1), slomo-3.1) and slomo2-3) can't we have a

 gst_controller_make_default_control_rate(controller,bmp,tpb,spt,srat)

• this could look at the provided values (which except srat can be 0) and the interpolation mode

[edit] comparison

[edit] ensonic

• - cannot handle triggers out of the control-rate grid
• - if elements don't set a sensibe control-rate the wont functon nicely
• + no dependency against tempo (tempo can be in plugins-base)

[edit] slomo

• - dependeny against tempo (needs tempo in core)
• + can always handle triggers
• + due to suggest_next_sync() it can optimize sync-intervals based on the scheduled control events

[edit] slomo 2

• - controller has to be added to the element before the tempo is set
• + can always handle triggers
• + due to suggest_next_sync() it can optimize sync-intervals based on the scheduled control events

[edit] problems

[edit] updating the GObjectProperties

gst_controller_sync_values() calls g_object_set() for changed values. this might become a problem when called to often (too quick). for modulators we don't want to change the GObjectProperties for each sample-frame or even for each sync-interval?.

• is this really a probelm (is the overhead as big as we think)?

[edit] notification of triggers

Listening to "notify::" to get trigger changes is not accurate. Its probably better to ask if there is a change schedules for a trigger property (after calling gst_controller_sync_values()). We could call gst_controller_get() for the trigger properties and check the returned value (should be != default for trigger event).