How do I convert the attached polyrhythm patch to work from a phasor~
I have attached a polyrhythm patch I have been working on. I was looking for a way to drive it by a phasor~ rather than a metro and transport Raw Ticks. Can anyone show me a way to do this please?
Okay. I think I have accomplished it. It may be useful to someone else. A much simpler and tidier implementation.
often these things are simpler in audiorate, but, as weird as your patch is, if your aim is to output midi or max messages again at the end, there are good reasons not to use signals at all.
clock division using signal ramps is more or less [phasor~] [*~ 16] [% ~ 1.] ... and of course this works likewise with [*~ 12].
if you also need clock multiplying, or if you want relations such as [*~ 1.5] (which can only be reached by multiplying), you simply make the master phasor 8 times slower as it should be and derive the normal 1/1 beat from it by [*~ 16] already.
x4 will be like x0.25 and x24 will be like x1.5 in this case.
use scope to debug.
p.s.: btw, in non-audio rate you can do almost the same by using line~ as data rate phase accumulator. in an ideal case you would set its "grain" to the lcm() of all beats you want to output. this will be very close to the use of midi style 1920 ppm stuff, just more dynamic.
i am not mentioning rate~, what~ and whatnot here because of the 110 land constitution, if someone feels called to do so, just go for it.
Cheers for your input Roman. I generally like to work with the phasor~ object, as I just assumed it was tighter timing in max. You may correct me. I'm not an expert in that.
I am looking for "weird" timings and I just halved the Global Transport to 60BPM for slower timing, so I could do longer loops. I wanted to do time sigs like 17/19 and the likes.
In effect I have a polyrhythm and polymeter sequencer in one when I change the column numbers and the timing intervals to 1n, 1nt, 1nd........... etc. I found that by accident tbh, but I really like the implementation.
Yes, and the scope is useful.
I will add that the polyrhythms and polymeters come with multiple instances running in tandem with different settings. But I'm sure you realised that.
signal is only more tight if you do not convert it to data afterwards.
today there are some options which let you switch the domains without accuray loss, but to find out when and how only makes it more complicated. where it does not work, you end up in a fixed rate of 0.7ms where metro would offer 0.001 or less.
if midi is the aim, metro is superexact, about thousand times more than the VST plug-in you might trigger, not to speak of hardware.
17 over 19... both primes... lcm is 323. possible with signals, but requires scaling stuff for 4-5 digits.
and in theory you would want all, isnt it ... 1-20 already requires 232793560 as base. :P
https://www.wolframalpha.com/input?i=factors%28lcm%281%2C2%2C3%2C4%2C5%2C6%2C7%2C8%2C9%2C10%2C11%2C12%2C13%2C14%2C15%2C16%2C17%2C18%2C19%2C20%29%29
to be fair, 1920 ppq offers far less, it can only do 1, 2 ,3 ,4 ,5 ,6 ,8, 10, 12, 16. (that means 7 over 8 already jitters.)
using individual metros is simple...
...and would allow any speed relation you wish, without any restrictions.
but dont let yourself be sidetracked from my comments; build it using signals and see what works best for you.
You have so much knowledge. Thanks for the insights. For this project I will stick with signals, but it is good to know that metro is perhaps just as useful, if not more. Thanks again.
Hi Roman, as always, I totally agree with your suggestions: if the purpose of the sequencer is to send messages (such as MIDI signals), it can be counterproductive to sequencing at audio-rate for several reasons.
But I'm curious to know what you think of mc.midiplayer?
The object seems specifically designed to overcome the obstacle of switching between domains.
Enrico
(ah and what do you think of 720720 to divide all the numbers between 1 and 16?)
any new class of compiled objects is welcome, but i am not sure if midiplayer will really be a general solution which will allow us in the future to switch domains at random and without knowing what we do.
there are enough situations where you can´t avoid to switch domains and where "music signal to midi" is part of the application, then it is of course great when it works less cumbersome than it did in the past.
but what about pure generation of data? what about you; would you use phasor~ to generate midi only because/when it is possible? i.e. without adding any real advantage over creating data at scheduler rate? :)