In Gibber I went with using samples for timing, but also provide
variables that store the number of samples for particular metric
values. So, _4 is a variable storing the number of samples in a
quarter note, _8 in an eighth note, _23 in a 23rd(?) note etc. That
way users can use beat synchronized timings if they like, but are also
free to use arbitrary sample values. I'm not entirely sure I'm going
to stick with this approach, but I thought I'd mention it.
An approach I think might be better (and that I might move to) would
be to always assume a metric multiplier in functions that accept a
time parameter, but also provide simple functions that convert
arbitrary sample or ms values to the appropriate metric multiplier
given the current bpm.
So, in pseudo-code:
note( "A4", 1 ); // play a whole note
note( "A4", 1/16 ); // play a sixteenth note
note( "A4", ms(1000) ); // play a note that lasts a second
note( "A4", samp(3153) ); // play a note that lasts 3153 samples
Just brainstorming out loud... - Charlie
On Tue, May 1, 2012 at 1:05 PM, Davide Della Casa <davidedc_at_gmail.com> wrote:
> Trying to think if there is also a simple way to allow the visual and audio
> tempo to be disjoint if one doesn't want them tied by a multiplier. If
> that's even useful, not sure.
>
> D
>
> On 1 May 2012, at 20:44, Kassen wrote:
>
> If you already have a bpm I'd make the visual "tempo" some fraction or
> multiple of that. How about it defaulting to a bar, so a "tempo" of 1
> means a 1 bar vidual repetirion? .25 would mean quarter-note
> movements, while a tempo of 4 would mean a visual loop covering 4
> musical bars?
>
>
Received on Tue May 01 2012 - 21:03:20 BST