octal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Octal-dev] Re: timing


From: Dave O'Toole
Subject: Re: [Octal-dev] Re: timing
Date: Mon Jul 24 22:43:03 2000

> Lets say your sixteenth(tick) is 250 samples long according to your
> tempo (just an example). Ok now the engine always takes blocks of this
> size and
> parses it through the machines/effects and then to the master. (if i

Well, actually ticks are generated a bit at a time. The block size is
smaller than a tick. But this is a detail...

> if we calculate the blocksizes to match the both we get:
> |    250     | 83|  167   |   167  | 83|   250      |
> 
> as fractions:
> |     3      | 1 |   2    |    2   | 1 |     3      |
> |    --      |-- |  --    |   --   |-- |    --      |
> |    12      |12 |  12    |   12   |12 |    12      |

This can be done easily. You want to divide a beat into four parts (for
your 16th notes) and also into three parts (for your 8th triplets.) So
the beat's size needs to be evenly divisible by both four and three.
Conveniently, 4 * 3 = 12 is such a number. So tell the tracker that you
want 12 ticks per beat (Buzz has a setting for this but it doesn't seem
to be connected to the interface highlighting, which I plan to correct.)
A beat is a quarter note, 4 ticks is an 8th triplet, and 3 ticks is a
16th note. 

You can apply it to other situations too. Does this work for you? 

Forget about the fooling with block sizes, that won't really work
anyway. Use ticks as your unit of measurement and we can do 95% of what
we want. 

The case you are talking about (3 and 4) would be a common case and can
be done with the existing simple architecture. If someone really insists
on simultaneously subdividing each beat into two different prime numbers
larger than three then they should just use CSound. 

-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal


reply via email to

[Prev in Thread] Current Thread [Next in Thread]