Help with Polyrhythm Sequencer quantized to transport ticks
I have a little polyrhythm sequencer running from a metro quantized to transport ticks. It seems the ticks are passing through the live.grid and its not responding as i'd like, but I can't figure it out. I just need a single bang per highlighted cell in the live.grid, but as you can see from the highlighted counter before the click~ object it is counting up in ticks.
Can anyone suggest a fix please?
Anyone help with this. Still can't work it out. Thanks.
operating with floats outputs integer result multiple times
insert change between + 1 and live.grid.
By the way in what relation to actual tempo should it run ?
Dividing elapsed ticks by 100. ?
Also - if you use any uneven duration or division, you will get fluctuations
I utilised the workings from this patch by @BENNIY from this post: https://cycling74.com/forums/using-euclideanbjorklund-algorithm-for-rhythm-generation-purely-in-max
It was just to illustrate the difference between polyrhythms and polymeters.
I haven't yet understood the dividing ticks by 100. I am still experimenting with this one.
If you know of any better way to implement a simple polyrhythm patch with better relation to BPM, I am interested to see.
Thanks.
Thanks for the magic expr btw.
It depends on what you mean by polyrhythm.
I see it (not taking care about terminology)
in relation to some other clock (to keep pattern in sync)
1- one can divide one length of time into free slices.
for example 1 bar of 3/4 divided into 13 steps.
or 2 seconds of real time into 7 steps.
2- use common division (like number of ticks for example)
and make pattern consisting of free number of steps.
like 11 16th notes
both way pattern will stay in sync with running clock.
If you decide to work with BPM based clock, you need to
use ticks, because that would be the common clock.
or shortest time unit.
so you would use metro with 1 tick resolution
and use divider, modulo etc to slice the time and steps
Or make own midi clock, or use transport, or plugsync in Live etc
For my purposes here, I see polyrhythm as one static length of time divided into as many divisions as I require, but still keeping to that same one static length of time. I can then highlight as many of those divisions/cells as required to make my desired rhythm. I can then have as many of said sequencers as needed to make complex patterns.
I would prefer to work with BPM based clock, but as you said in your first answer, there is a question over dividing ticks by 100.
Would you be able to give an example patch to suggest a way illustrate a better relationship to bpm to utilise in this patch?
I have to go out, and will do so, as soon as I come back.
I am using max 6 this moment, and in Max 8 few things run
a bit different, so I should make examples in Max 8.
Are you going to use this in Live or in Max ?
I ask because of sync options.
No worries.
Yes i'm on Max 8, Just in Max, not for Live.
calculations are simple :
tempo is expressed in beats per minute
to translate that into ms
60000. / $f1 (tempo) gives us length of 1 quarter note in ms
with standard PPQ of 480, we divide that by 480, to get
length of 1 tick in ms
example
tempo 120.
60000. / (120. *480.) = 1.041667
or in tempo 171 = 0.730994 ms
1 tick is in midi world smallest time unit one can sync to.
--------
In this modern times you can use transport
set to metro with interval of 1 tick.
It does all the rest itself.
It is now only a matter what do you want to use as the
"static length" as you name it, to divide it into different number of slices.
You could use a bar, set it to 3/4 and that would be in tempo 100
3x480=1440 ticks or 3x600 = 1800 ms
dividing in ticks would allways have rounding errors.
If you would want to divide that 3/4 bar into 17 steps
1440/17 = 84.7 ticks - that does not work
if one would go for ms 1800 / 17 = 105.882355
it would be no problem at all to set metro to that value
and run counter 1-17.
As you see using BPM is a bit imperfect when you want to divide
as free as possible.
BPM calculation can be used to stay compatible
with devices or constructs that need BPM timing and maybe sync,
one could also generate Midi Clock Out,
but divide the bar for polyrhythm internaly
Easy fix:
look at the count going to the live.grid - try printing it, you're getting tons of duplicates, due to the division.
squeeze a change object in there, you should be good.
@SOURCE AUDIO
You're right, its all there as long as you know how to decipher to information from the transport information given. I can understand this a lot easier than the patch I posted initially and much more elegant. And as you have shown it is quite easy and logical. I have learned a lot from your generosity. I appreciate the time you have given me and the explanation of everything from start to finish. This is very useful to me. Thank you.
@WETTERBERG Thanks for the tip on the change object. SOURCE AUDIO beat you to it, but good to get clarity. Cheers.
"or in tempo 171 = 0.730994 ms"
... and when you send that over USB MIDI you have 27% jitter, which is about a triplet :D
Midi Beat Clock is sent 24 times per quarter note, or each 20 ticks,
not on every tick change.
Midi Clock + Song Position Pointer can not be used
to precisely start remote slave from any position in timeline
if division does not match 16th notes that easy.
Bar oriented sync which triggers some kind of ramp
with divisions could work, but again not out of the box
because even if one inserts change at bar progress output,
it will false trigger on any position in the bar if new bar does not match
last one...
Another option would be to translate SPP 16th note
into it's position in the Bar, and start ramp from that offset.
I had that kind of sync running in max 3.5.9 year 1998
@pink ah, I figured someone would have popped that in, yeah. You've gathered some smart people here... and me.
@Source Audio I understand what you are saying, but would find that difficult to implement. I'm gonna be cheeky again, and ask you for an example patch from you? It would be peace of mind to have this working in complete sync. And would help me to understand fully how do do it. :)
@WETTERBERG You're all smarter than me, by far :))
@Roman Is that sarcasm? :)) I know you don't like the transport in Max ;)
Actually, I just want to use this for Max only patches. No USB Midi needed.
If you don't need any midi sync to outer world, than what was the question about ?
I use the global transport to sync everything in my patches. I occasionally use external midi and vsts, but at the moment I was building the sequencer to trigger max built samplers for drums.
I don't use that global transport.It is first thing I trash out of patches.
You probably noticed I named that transport with divisions,
just to make sure it does not get affected by that global transport.
If you want me to add sending of Midi Clock and Song Position Pointer to that patch - no problem.
At this point in time, I have no need for the midi clock sync. I was just interested to see how it could be done with your explanation.
Thank you for spending the time to explain everything in such detail. I appreciate it.
@source audio I'm sorry to raise again this old subject about syncing multiple patterns of variable number of steps by using the transport tick count, dividing it and then adding a % for the number of steps. Although this works in my current patch, each time that I change the division number or the number of steps before stabilizing itself in the new step interval measured in ms it jumps through other values. When I use for instance the tempo object and I change the number of beats per bar or the number of steps it jumps directly into the new value without going through random ones. I hope that this is understandable, I can provide an example patch if needed. Thanks in advance.
tempo objects uses new calculated beat division interval to output next number.
It does not respect bar quantisation.
means not suitable for on the fly change if it needs to sync to bar.
You can quantise division changes to bar beginning
to prevent any jumps when changing divisions.
Thanks for your answer. Yes, I already know your patch which I have learned a lot from. What I meant was that for instance if you set a bpm of 100 at 480 ticks with a division of 8 you get a step interval of 75 ms. If you change the division to 4 it doesn't directly go to 150 ms but readjusts itself outputting random intervals in between. This doesn't happen with the tempo object. It sort of waits till readjusting to the new step interval. I hope this makes it more understandable. Thanks for your help.
I understand the point, but also you have to understand my reply.
You can not compare tempo with scaled output in that example.
if scale receives new scaling factor it will scale input to new divisor
and so jump to new calculated number.
Tempo object adjusts speed of output to next division point after it produced last beat in previous division, but does not care about position in a bar.
Example: lets say you divide by 9.
current count passed 7 and you switch to 12.
Tempo produces 8 in old speed, then adjust the interval and next number it outputs is 9
It is totaly out of sync.
Line or any other object that scales bar progres into divisions will immediately adjust
to absolute count position when it receives new divisor.
due to rounding to int in change object it will hickup most of the time.
That is why you need to adust divisor at bar start.
If you don't need absolute sync to a bar then use whatever you want to produce bangs
in set speed, like tempo, metro, delay ...
many choices.
but you can't produce division counter like that.
Sorry, I checked again your patch and I had failed to notice the modification in order to wait for the trigger of the new divisor at bar start. What if I want to prevent hiccups not at the step division level but at the time signature one? What bang should the time signature change wait for?
edit: I figured it out, thanks for pointing me in the right direction.
>What bang should the time signature change wait for?
If you want to observe the time sig, I think it's important to stress that you're not working with bangs, you're working with changing numbers, and YOU are generating the bang by observing integers.
in the case of the time sig it's a duplet of two integers. I think I'd personally use zl.change into [t b], but I'm a dummy.
I opted for calculating the length of the current bar in ms and then sending the new value with a delay of that length minus 1 ms just when the bar hits its last beat.
If you want to change time signature while extracting bar progress from absolute tick count,
you will allways have hickups and jumps because calculated bar length will change
and with it bar start point.
If you use transpot, reset it to 0 ticks when sending time signature.
You can do so quantised to bar, beat or unquantised.
Will lost any trace to real elapsed time.That is so if one uses any counter
not capable of taking into account tempo and timesignature map, like real DAWs do.
-----
depending on what kind of polyrhythmic relations you want to have,
you could even run transport with unchanged time signature, but change duration of your divisor.
For example you run transport in 4/4, start dividing tick count with 1920,
and have several divisions running in sync to that bar length.
Then you change from 1920 to 1440 (6/8) which would mean that now you have
2 time signatures running parallel, but your sub divisions will run as if 1440 was
set from beginning.
Or go with metros and counters instead of tick progress.
Thanks for your additional recommendation. Actually, as you suggested, I'm not using the transport time signature but changing the divisor by multiplying and dividing it ($f1 * (1920/$f2)) and then adding a % for the number of steps (I'm not doing polyrhythmic but polymetric sequencing). As I said, I already solved the issue by triggering the new value with a delay of the length of the step interval in milliseconds minus 1 ms at the start of the last step in the case of time signature or at any change of the % in the case of the step number. The new value always lands before the tick count of the % object changes to the new integer value:
@source audio Hi again, I have encountered an issue that I wasn't aware of while sequencing multiple patterns using the % object as step number counter. If a sequence ends in 0, then the following sequence starting with 0 won't trigger the first step since it doesn't change its integer value but will jump to the second step with 1. Is there a way to prevent this from happening? And also: there's no way of having sequences of just 1 step with this approach, right? Thanks in advance.
only 1 step with change object inserted - no, unless one manages to reset
change object at some point before bang should happen.
You seem to use delay 1 ms earlier than 0 time when changing divisor length,
you could use that maybe ?
send set -1 message to change object.
Do same when resetting transport to zero, otherwise it will miss first beat.
The whole construct with % inserted in ticks progress was designed for that original patch
and was not meant to serve as 1 step bang sequencer, or to change time signatures on the fly.
I didn't think of that, it totally worked! Thanks so much!