You provide motivation to finally expose time information to Lua DSP scripts.
Nice! That’s exactly what I need, thanks a lot.
Plugins have a local latency-compensated time.
Ok, I see. That’s probably why my BBT changes detected with that method were always a bit off.
It works, and by is shown in Window > Log.
Ah yes, that’s good to know.
Please let me know if that works for you and if you have further suggestions before we finalize this API with the 7.5 release.
Looks good to me. But would it be possible to have actual BBT and the length of the current cycle in ticks as well? Having that kind of information readily available would make things a little easier for my purposes, although that information can be computed relatively easily from the data that’s already there, I guess.
But would it be possible to have actual BBT and the length of the current cycle in ticks as well?
Scratch that. Ticks won’t actually be all that useful in this context. If you want to do sample-accurate playback then something like a sample count since the last quarter beat might be more useful. In any case, it should be possible to get all these numbers from what’s already there.
BTW, what’s up with all the foo["bar"] indexing in the sample Lua code, is that a stylistic thing, or personal preference? I’m sure you know that in a Lua table, you can always just write the equivalent foo.bar instead (of course, this only works if the symbol is a proper Lua identifier). I also find it more convenient and readable to write something like
One more thing, though: The sampleTime from the time_info table is local latency-compensated time, right? So I can just pass that to Temporal.TempoMap:bbt_at() to get accurate and up-to-date BBT information?
The reason I still need the BBT info from the tempo map is that I need to be able to properly deal with more esoteric time signatures such as 11/8 or 13/16 that don’t evenly divide into quarters. Now one could derive that data from what time_info provides, but that would be cumbersome – Ardour already knows how to compute those values, so I’d rather use those. I can still put time_info to good use to detect meter changes and base pulses, so that I only need to invoke the BBT calculation when a new beat is due.
I am thinking of changing it to underscores. e.g. “sample_time”, which is more consistent. Even more Lua-like would be nested tables: time.sample.start, time.sig.numerator etc. except there is the problem that end is reserved keyword we we cannot use time.sample.end, but time.sample_time_end work.
I think I also was too quick last night, exposing “sample-position of the last beat”. The value is not useful if there are tempo-ramps, or if the tempo-changed since the last beat.
I agree that it’s better to remove it again. It’s of limited use anyway, and this kind of information can be determined through the tempo map if needed.
And what about musicTimeEnd? That one is actually much more useful, since it lets you detect imminent beat increments, in order to schedule MIDI notes at the right sample time. For that to work, it should always equal the next cycle’s musicTime. Is that always true, regardless of any tempo changes?
I’m also not a big fan of using camelCase here
I’m firmly with you on that one. Lowercase + underscores FTW!
I’m tempted to remove time["bar"], which is somewhat ill defined (and assumes 4/4). Are you using that?
Not really. I’m using beat and ts_denominator to detect beats, so that I don’t have to access the tempo map in each cycle, and then sample to get proper BBT information from the tempo map. I think that for sample-accurate triggering I’ll also need beat_end and sample_end, and maybe tempo and tempo_end, but that’s about it.
This is looking good. I have a basic arpeggiator working now, which already does the job fairly well. I still need to figure out sample-accurate triggering, though, where things are likely to get complicated. I’ll look into that tomorrow.
Perhaps, when the transport is stopped MIDI messages can be passed though as-is?
Also transport start/stop should perhaps send all-note-off messages.
Good ideas, will do.
Yeah, it’s a little thing, but I also found it to be stupidly fun, especially when I hook it up to the avldrums. Hope the students will like it, too. (I’m doing a DAW course this semester, mostly about Ardour. It’s a lot of fun, especially after I rediscovered its Lua interface. You’ve done a great job with this, it’s come a long way since I last dabbled around with it.)
I’d still like to do an alternative version of the plugin with better auto-generated velocities, using Barlow indispensabilities. I already have that as Lua code, so it will be easy to port over.