Deal with tempo

[Theodeus]

Some effects depend on BPM. Need to figure out how to deal with this in a consistent way. A global BPM for Tuna (pass to constructor etc.) or set per node?

[echo66]

Greetins, Theodeus! Take a look at https://github.com/echo66/bpm-timeline.js .

[Theodeus]

Hey!

Spontaneously, it seems like bpm-timeline might be more than we'd need in Tuna, though I'll definitely keep it in mind as we explore what the requirements we have are!

[echo66]

In order to integrate tuna in applications that deal with dynamic tempo, besides my implementariam, you have Tone.Transport, in Tone.js. But BPMTimeline allows a seamless mapping between beats and seconds, unlike Tone.js (i.e.: Tone.js tempo is controlled, by what it seems to be, step functions with the smallest time measure as the tick).

[errozero]

A global bpm for tuna sounds good, maybe it could have a default bpm if one is not passed in.
Then when changing the tempo in your app, you could also update the tuna object, or call a method with the new tempo which would re-calculate delay times etc.

[positonic]

Some effects depend on BPM. Need to figure out how to deal with this in a consistent way. A global BPM for Tuna (pass to constructor etc.) or set per node?

Why not both as errozero suggests. Pass it in the constructor, and then a method (function) to update it, which would re-calculate existing effects?

[Theodeus]

Yeah, that sounds like a simple solution!

Do you guys think there should be a separate BPM based delay, or should all delay types be "syncable" to the BPM?

[errozero]

@Theodeus I don't think there needs to be a separate BPM based delay if there is a way to resync to a new global tempo. Maybe the existing delay fx could have a toggle to state if they should sync or not.