Removing tempo from a plugin

[mwilliamson-fourier]

A tempo can be passed to a plugin by setting the tempo field and CLAP_TRANSPORT_HAS_TEMPO flag in clap_event_transport, and then passing that event into the process() call. If you want to change the tempo for an audio period, you can do so by passing in another event with a different tempo.

However, I'm not clear on how to remove a tempo from a plugin that already has a tempo. If an event is passed into process() that doesn't have the CLAP_TRANSPORT_HAS_TEMPO flag set, does this imply that the plugin should no longer have a tempo, or that it should continue using the tempo that was last specified in an event?

[baconpaul]

In a given process loop, if the transport doesn't support CLAP_TRANSPORT_HAS_TEMPO, then the plugin does not have access to the tempo.

What a plugin does with that fact is up to the plugin.

For instance, if the transport is NULL or the CLAP_TRANSPORT_HAS_TEMPO is not set, surge will go to 120bpm 4/4 for all its internal tempo measures.

I think if a host set tempo as there and then changed it to not there, it would get a variety of behaviors from plugins. The correct behavior would be for the plugin to do whatever it does for a tempo-free hosting environment for that process block. But who knows if plugins would do that correctly!

Does that help?

[mwilliamson-fourier]

Thanks, that makes sense! Maybe this is obvious to everyone else, but is it worth clarifying in the docs for clap_process that the transport field only affects samples in that process block, rather than potentially affecting samples in future process blocks if the relevant fields/flags aren't set or no event is passed in?

[baconpaul]

Yeah I thought the docs said something like the transport event is timed to the start of the block for the duration of the block and inter block changes require a new event.

Honestly I never thought of a daw providing transport for a while then not. Why would that happen?

[mwilliamson-fourier]

Yeah I thought the docs said something like the transport event is timed to the start of the block for the duration of the block and inter block changes require a new event.

I think this describes when the transport event starts, but not explicitly when it ends: that is, the transport event contains the tempo (in this case) until the earlier of the next transport event or the end of the block.

Or, to put it another way: the absence of a CLAP_TRANSPORT_HAS_TEMPO flag indicates that there is no tempo for the samples to which the transport event applies, rather than meaning that the event doesn't specify anything about the tempo, and that the tempo should be inherited from the last transport event that specified tempo information.

Honestly I never thought of a daw providing transport for a while then not. Why would that happen?

This might never actually happen in practice, but if the host's UI allows the user to either set a tempo or have no tempo, then the user might set a tempo, then decide to remove that tempo. In that case, the plugins should reflect the new (absence of a) tempo, rather than continuing to use the stale tempo.

[baconpaul]

Right

So in that case I think you send a transport event with no tempo flag set

The question is whether a null transport means nothing or roll forward last. But an existing non null transport unambiguously covers the block.

So it seems your question is what does it mean when you go from transport to null transport. Going from has tempo to does not have tempo in a non null transport seems pretty unambiguous that the plugin is now in a tempo-less environment and should do whatever it does with that fact.