Help with Polyrhythm Sequencer quantized to transport ticks

    Aug 13 2020 | 9:53 pm
    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?

    • Aug 14 2020 | 6:16 am
      Anyone help with this. Still can't work it out. Thanks.
    • Aug 14 2020 | 7:17 am
      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
    • Aug 14 2020 | 8:34 am
      I utilised the workings from this patch by @BENNIY from this post:
      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.
    • Aug 14 2020 | 8:55 am
      Thanks for the magic expr btw.
    • Aug 14 2020 | 10:01 am
      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
    • Aug 14 2020 | 10:26 am
      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?
    • Aug 14 2020 | 10:29 am
      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.
    • Aug 14 2020 | 10:52 am
      No worries.
      Yes i'm on Max 8, Just in Max, not for Live.
    • Aug 14 2020 | 4:01 pm
      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
    • Aug 14 2020 | 4:05 pm
      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.
    • Aug 14 2020 | 9:43 pm
      @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.
    • Aug 14 2020 | 10:12 pm
      "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
    • Aug 15 2020 | 7:29 am
      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
    • Aug 15 2020 | 8:22 am
      @pink ah, I figured someone would have popped that in, yeah. You've gathered some smart people here... and me.
    • Aug 15 2020 | 1:45 pm
      @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. :)
    • Aug 15 2020 | 1:46 pm
      @WETTERBERG You're all smarter than me, by far :))
    • Aug 15 2020 | 1:53 pm
      @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.
    • Aug 15 2020 | 2:48 pm
      If you don't need any midi sync to outer world, than what was the question about ?
    • Aug 15 2020 | 3:51 pm
      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.
    • Aug 15 2020 | 3:55 pm
      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.
    • Aug 15 2020 | 6:23 pm
      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.