POlyrytms
Currently I use different temp modules , all slaved to the the same master master bmp and set temp module division for each tempo module separatly .
Are there any better ways ?
unless you want to limit yourself to a small set of small integer ratios such as {2, 3, 4, 6} or {2, 4, 8, 16} using multiple tempo/metro objects is your only chance.
your 3, 5, 16 example makes it already impossible to use only one clock; it would have to run at 1/240 speed (4,16 milliseconds at 120 BPM?) - and 90% of the bangs had to be filtered out.
if you use hundreds you might want to put them into a poly~, otherwise your approach seems correct.
> Are there any better ways ?
Yes there are. I kinda disagree with Roman, even though he's usually a fount of knowledge.
If your resolution is high enough, doing divisions down from a central clock is perfectly flexible and tight.
The gist of it:
[transport] has a "Raw Ticks" output, which outputs what is essentially a count @ 1/1920th notes.
This can be divided down. For example, /120 will give you 16th notes. Apply a [change] object, and you have a clean pulsing 16th, counting infinitely upwards, along with the playback position.
From there, the modulo operator ([% 16], for instance) will give you a "length".
To sum up; a fast count, and / + % will get you where you want to go.
For reference, this is what we're using in my group:
https://drive.google.com/file/d/0B9l5GHMkELeuS0plRUc5SzZaWEk/view?usp=sharing
This might look daunting, because it does a ton of other stuff, but it basically allows arbitrary subdivisions, offsets, a wild array of swing methods etc etc.
The core of it is still:
An incoming number stream being divided and modulo'ed.
1920 wont allow 14, 13, 11, 9, and 7, but yea it will be only half the data stream. and a great exercise too, to split the stream using counter and gate.
what i find a bit critical is to do the "original" of that 1920 thing in the real midi world. since the day midi connects via usb, clock is... but i am getting sidetracked now.
sometimes i wonder if it wouldnt be best to use [del] for a complex all-in-one sequencer and only produce one bang per bar, then only play the events which are currently set to play? :)
this has been talked in another thread not long ago,
someone asked to divide bar length into any number of steps.
Today one does not need to stick with ticks, BPM is only a representation of
how long 1 beat in realtime is.
that chunk of time can be divided, multiplied or whatever using any kind of time
units, being ms, samplecount or ...
so you say tempo 100 , make a bar of 11/8 and divide it into 13 steps.
At least in Max this is all possible.
In Live one will have trouble to do anything like that relying on
Live's realtime progress which does not exist.
yeah, the compromise is that when doing the divisions you sorta accept that the odds will be "really really close but not mathematically on point". In my experience, I can do septuplets that sound great... I don't think anyone will be able to discern whether they're "suffering from rounding errors". At least I hope not.
In a way, it's an exercise in practicality: If I tell myself that 1920 can't do 7, then it won't. But if I examine the math, 1920/7 = 274.285714286 - so each septuplet is 274.29 ticks, and the rounding error applied by this method ( .285714286 of a tick) is less than a millisecond @120 bpm, if I'm not wrong?
If I set up two of these dividers, and tell one of them "hey, the "bar" is no longer 1920 ticks, it's 1919", I hear cutesy little Reichian phasing. So the "precision within the imprecision" is there, at least.
I think the history of "art music" is full of systems that sorta "start this thing and then play out an algorithm that starts at the right time, and then it's "ms intervals" for the rest of it. From time to time I do wish that was my bag, too.
> Today one does not need to stick with ticks, BPM is only a representation of how long 1 beat in realtime is. that chunk of time can be divided, multiplied or whatever using any kind of time units, being ms, samplecount or ...
Lots of people use sample-rate sequencing for stuff. I've never been too keen on it, since the CPU cost rapidly explodes if you go this route. My rig has dozens of the above client abstraction, I think I would need a laptop just to run the sequencing part. Also, the precision it offers largely goes out the window if you're then triggering stuff over DIN midi afterwards.
Ticks is of course a compromise, but it's a handy standard for a few key reasons.
1) It's right there in the transport object. Transport speaks live link and all sorts of handy stuff.
2) midi clock is still set up in this way, too. 480 PPQ comes out to 1920
3) 1920 divides very nicely.
"Today one does not need to stick with ticks"
interesting enough, that this stuff has been added to max around that time when it got out of fashion.
and now everbody is using it (not only ppq but all of this global tempo stuff), instead of learning how to convert units.
and maybe they are right? i once needed a week until [110.msbeat2bpm] worked - and later i noticed i made an error, so since 2005 all my 1/8s are 1/16s. :)
here i am running "all" from 1 to 16 - and you only turn on those you need.
(in addition it outputs numbers, not bangs, but thats irrelevant)
combinations with polymetric systems is not intended for this one.
"In a way, it's an exercise in practicality"
220,3 milliseconds is fine, but 30,99 milliseconds is where the trouble begins.
the trouble continues if you layer 7 and 14 - and the events they produce arent synched and might even arrive in different audio vectors, maybe also in bigger audio vectors.
you would also betray the original idea of using only one stream if you do 7 && 14 that way. :)
now it is time for someone chiming in argueing for 64 bit precision clocks. :D
I love you, Roman.