UnUnUnium

I've working on various elements of a larger instrument I plan to build, but I've come to a stumbling block.

Essentially, I am trying to build a 'master clock' patch that defines the length of phrases, delays, buffers, etc, based around a common BPM.

I'm taking the BPM and dividng it by different divisions of a minute to get fractions of a beat. The first problem I'm having is that when I divide the BPM by 30,000, then by 7500, to get two different beat lengths respectively. Assumedly, if I multiply the second figure (the one divided by 7500) by 4, I would get the same amount as the other figure (as 7500*4=30000)..It doesn't happen though, it ends up being almost the same sumber, but not quite. This is illustrated on the right side fo the patch where I've labeled it "! BAR". I've included an audio rate version of the calculation as well, just for comparison.

The second problem is that when I use ANY of the figures to size a buffer (bottom middle of screen), the figure OFTEN comes out different than the number I'm using to seze the buffer...this sometimes takes a few tries, because sometimes (depending on the BPM setting)it IS the same...maddening. Mess with the BPM and query the buffer length using the info~, you'll see what I mean.

Note: all numbers are floating point. You have to change the BPM to trigger the calculations the way I have it set up.

ANyway, sorry for the long post, but if anyone can take a look at the patch, I would be very happy.

New to the list, and to MaxMSP.
   I've working on various elements of a larger instrument I plan to build, but I've come to a stumbling block.
   Essentially, I am trying to build a 'master clock' patch that defines the length of phrases, delays, buffers, etc, based around a common BPM.
   I'm taking the BPM and dividng it by different divisions of a minute to get fractions of a beat. The first problem I'm having is that when I divide the BPM by 30,000, then by 7500, to get two different beat lengths respectively. Assumedly, if I multiply the second figure (the one divided by 7500) by 4, I would get the same amount as the other figure (as 7500*4=30000)..It doesn't happen though, it ends up being almost the same sumber, but not quite. This is illustrated on the right side fo the patch where I've labeled it "! BAR". I've included an audio rate version of the calculation as well, just for comparison.
   The second problem is that when I use ANY of the figures to size a buffer (bottom middle of screen), the figure OFTEN comes out different than the number I'm using to seze the buffer...this sometimes takes a few tries, because sometimes (depending on the BPM setting)it IS the same...maddening. Mess with the BPM and query the buffer length using the info~, you'll see what I mean.
   Note: all numbers are floating point. You have to change the BPM to trigger the calculations the way I have it set up.
   ANyway, sorry for the long post, but if anyone can take a look at the patch, I would be very happy.
  thanks, Jeremy....patch follows

trouble-with-numbers

i've just taken a quick look at your patch. watch out for your 

patching style to have an explicit order of events. if you want to 

devide two numbers, make sure to first set the right inlet 

(denominator). take a look at the example below.

also, rather than relying on graphical layout of your patch (right 

before left) you should better use [trigger] to sort out your data flow.

concerning the calculated buffer length, which seems to be incorrect 

sometimes, i guess that a valid buffer length must be an integer 

multiple of a sample duration, which itself is dependent on the 

sampling rate. so you can't have buffers of arbitrary length.

On 05 Nov 2006, at 16:10, Jeremy Keenan wrote:

> I've working on various elements of a larger instrument I plan 

> to build, but I've come to a stumbling block.

> Essentially, I am trying to build a 'master clock' patch that 

> defines the length of phrases, delays, buffers, etc, based around a 

> I'm taking the BPM and dividng it by different divisions of a 

> minute to get fractions of a beat. The first problem I'm having is 

> that when I divide the BPM by 30,000, then by 7500, to get two 

> different beat lengths respectively. Assumedly, if I multiply the 

> second figure (the one divided by 7500) by 4, I would get the same 

> amount as the other figure (as 7500*4=30000)..It doesn't happen 

> though, it ends up being almost the same sumber, but not quite. 

> This is illustrated on the right side fo the patch where I've 

> labeled it "! BAR". I've included an audio rate version of the 

> calculation as well, just for comparison.

> The second problem is that when I use ANY of the figures to size 

> a buffer (bottom middle of screen), the figure OFTEN comes out 

> different than the number I'm using to seze the buffer...this 

> sometimes takes a few tries, because sometimes (depending on the 

> BPM setting)it IS the same...maddening. Mess with the BPM and query 

> the buffer length using the info~, you'll see what I mean.

> Note: all numbers are floating point. You have to change the BPM 

> to trigger the calculations the way I have it set up.

> ANyway, sorry for the long post, but if anyone can take a look 

hi,
i've just taken a quick look at your patch. watch out for your  
patching style to have an explicit order of events. if you want to  
devide two numbers, make sure to first set the right inlet  
(denominator). take a look at the example below.
also, rather than relying on graphical layout of your patch (right  
before left) you should better use [trigger] to sort out your data flow.
concerning the calculated buffer length, which seems to be incorrect  
sometimes, i guess that a valid buffer length must be an integer  
multiple of a sample duration, which itself is dependent on the  
sampling rate. so you can't have buffers of arbitrary length.
hope that helps.
volker.

>
>  Hello everyone.
>
> New to the list, and to MaxMSP.
>    I've working on various elements of a larger instrument I plan  
> to build, but I've come to a stumbling block.
>    Essentially, I am trying to build a 'master clock' patch that  
> defines the length of phrases, delays, buffers, etc, based around a  
> common BPM.
>    I'm taking the BPM and dividng it by different divisions of a  
> minute to get fractions of a beat. The first problem I'm having is  
> that when I divide the BPM by 30,000, then by 7500, to get two  
> different beat lengths respectively. Assumedly, if I multiply the  
> second figure (the one divided by 7500) by 4, I would get the same  
> amount as the other figure (as 7500*4=30000)..It doesn't happen  
> though, it ends up being almost the same sumber, but not quite.  
> This is illustrated on the right side fo the patch where I've  
> labeled it "! BAR". I've included an audio rate version of the  
> calculation as well, just for comparison.
>    The second problem is that when I use ANY of the figures to size  
> a buffer (bottom middle of screen), the figure OFTEN comes out  
> different than the number I'm using to seze the buffer...this  
> sometimes takes a few tries, because sometimes (depending on the  
> BPM setting)it IS the same...maddening. Mess with the BPM and query  
> the buffer length using the info~, you'll see what I mean.
>    Note: all numbers are floating point. You have to change the BPM  
> to trigger the calculations the way I have it set up.
>    ANyway, sorry for the long post, but if anyone can take a look  
> at the patch, I would be very happy.
>   thanks, Jeremy....patch follows


Thank you very much! I see what you are saying- I will try to set up my calculations in the way that you suggest and see if it get more consistent results...I am still a bit unsure about using the trigger...I just haven't quite wrapped my head around it and it's obviously essential palce in the MaxMSP universe. 

So you're saying I can't define the buffer length by an aribitrary float because it is tied to the sampling rate, huh? Hmm...Bummer. I guess I'll have to take a different approach to that one....

Thank you very much! I see what you are saying- I will try to set up my calculations in the way that you suggest and see if it get more consistent results...I am still a bit unsure about using the trigger...I just haven't quite wrapped my head around it and it's obviously essential palce in the MaxMSP universe. 
  So you're saying I can't define the buffer length by an aribitrary float because it is tied to the sampling rate, huh? Hmm...Bummer. I guess I'll have to take a different approach to that one....
   Thanks again, Jeremy


you might want to go at it from the other direction

24 of these divisions would be a quarter note

12 of these divisions would be an 8th note

6 of these divisions would be a 16th note

3 of these divisions would be a 32nd note

could also use 1/96 or 1/960 (1/some multiple of 24)

like the old ppqn (pulses per quarter note)

then multiply by integers to get larger durations/periods

calculate a smallest unit (quanta)
1/24 - quarter note divided by 24 
24 of these divisions would be a quarter note
12 of these divisions would be an 8th note
6 of these divisions would be a 16th note
3 of these divisions would be a 32nd note

could also use 1/96 or 1/960 (1/some multiple of 24)
like the old ppqn (pulses per quarter note)

then multiply by integers to get larger durations/periods


I don't know if this will help or not, but this is an object I wrote several years ago to do all my BPM calculations. It handles multiple time signatures as well. At one point in time, I checked it pretty rigorously against Logic Audio's calculations (i.e. gave it a tempo and it's output against the length of a bounced logic file). So I think its fairly accurate.

The patch takes in a list of a float and three integers. The first number (the float) is the tempo. The second number is the numerator of the time signature. The third is the denominator of the time signature. The fourth is a quasi-optional duration. I say quasi because if any of the numbers are zero, you'll get a divide by zero error. The duration can be anything- 4 for a quarter note, 8 for an 8th note etc. Multiples of three will be triplets.

The output of the patch is the length of a measure at the given tempo/time signature in variousy units (ms, samples, Hz for phasor~). The duration (the fourth element of the input list) is given in the same units.

The patch also outputs the number of ticks in the measure based on 48 parts per quarter note. I've based all of the little sequencers I've written off of 48ppq and haven't had any trouble. With 48ppq I get 192 ticks in a measure at 4/4. If you wanted to build a clock around this, you could take the length of a measure 

in milliseconds and divide it by the number of ticks per measure to get the duration of one tick. This can be used to set a metro. I typically have the output of a metro connected to a counter who's maximum count is the number of ticks in a measure - 1. Meaning at 192, the counter's maximum would be 191 so it counts from 0 to 191 for a total of 192 ticks.

Anyways, here is the patch, maybe it will help.

I don't know if this will help or not, but this is an object I wrote several years ago to do all my BPM calculations. It handles multiple time signatures as well. At one point in time, I checked it pretty rigorously against Logic Audio's calculations (i.e. gave it a tempo and it's output against the length of a bounced logic file).  So I think its fairly accurate.  

The patch takes in a list of a float and three integers. The first  number (the float) is the tempo. The second number is the numerator of the time signature. The third is the denominator of the time signature. The fourth is a quasi-optional duration.  I say quasi because if any of the numbers are zero, you'll get a divide by zero  error. The duration can be anything- 4 for a quarter note, 8 for an 8th note etc. Multiples of three will be triplets. 

The output of the patch is the length of a measure at the given tempo/time signature  in variousy units (ms, samples, Hz for phasor~). The duration (the fourth element of the input list) is given in the same units.  

The patch also outputs the number of ticks in the measure based on 48 parts per quarter note. I've based all of the little sequencers I've written off of 48ppq and haven't had any trouble. With 48ppq I get 192 ticks in a measure at 4/4. If you wanted to build a clock around this, you could take the length of a measure 
in milliseconds and divide it by the number of ticks per measure to get the duration of one tick. This can be used to set a metro. I typically have the output of a metro connected to a counter who's maximum count is the number of ticks in a measure - 1. Meaning at 192, the counter's maximum would be 191 so it counts from 0 to 191 for a total of 192 ticks. 

Anyways, here is the patch, maybe it will help. 

Yes, I get it...that is very helpful indeed! It seems like a "bottom up" approach is be favored- Your seems like an elegant solution...I'll have to study it in depth, I'm a bit shaky with using experssions, to be sure!

Yes, I get it...that is very helpful indeed! It seems like a "bottom up" approach is be favored- Your seems like an elegant solution...I'll have to study it in depth, I'm a bit shaky with using experssions, to be sure!
  Thank you, Jeremy


Yes, I think this is the approach I will take, perhaps caluclated from the sampling rate...Thank you for your help! 

Yes, I think this is the approach I will take, perhaps caluclated from the sampling rate...Thank you for your help! 
 Best, Jeremy


Trouble with numbers