phase shift rate~ object
hello friends -
can someone lend ideas on rotating the phase of a rate~ object's output?
the behavior of float in the left inlet isn't immediately clear to me, and the documentation lacks on behavior.
for example if i have a master control phasor~ driving rate~, i want to be able to dynamically change the start phase of rate~. eg phasor~ is at 0.5 and rate is at 0.0.
I realize i can do this with delay~, I am just looking for something more elegant.
thanks!
[delay] is not ideal.
+~ 0.5
%~ 1.0
Hi Roman!
I have learned a lot from reading your forum responses over the years, so many thanks!
So what I am trying to do is use [>~] into edge~ for generating midi and other max events. I can then use the right inlet of [>~] in order to move events forward or backward in time.
The problem is:
If 0.5 is "on the grid" so to speak, when the rate~ object driving that control rate is changed, it permutates the event.
For example:
- there are two control rates: a master phasor running at 1n
- a rate object synced to this phasor. the rate object in @sync lock and has a rate multiplier of 0.5.
- [>~ 0.5] into [edge~] is generating bangs at the end of both the master phasor and the [rate~]
- the [rate~] is now "playing" 2n, half notes, except it is offset by one half cycle due to the nature of the calculus.
So, I just need a dynamic solution so that whenever the rate multiplier is changed, the resulting events *eventually* line up (somewhere) with a "downbeat" of the master phasor. I've tried a few things but my brain is not seeing the math solution. I will try some things with the objects you mentioned.
Example patch is attached.
Thanks!
there's been this long-time misconception to simply put >~ 0.5 into edge~ (i'm not sure how that started), but if you want to track the very beginning of any kind of phasor, it takes [phasor~] -> [delta~] -> [<~ 0.] -> [edge~]
- [>~ 0.5] into [edge~] is generating bangs at the end of both the master phasor and the [rate~]
^this is not true. they are generating bangs midway, not at the end.
who started this weird misconception, i've seen it so many times and am inclined to find them, beat them up and steal their lunch money!
it might've been me, too, i've given so much bad advice on forums over the years... *pummels himself*... but no, actually now that i think about it and wipe the blood off of my face from self-flagellation, i'm pretty sure i've been using [phasor~] -> [delta~] -> [<~ 0.] -> [edge~] my whole entire life(that's right: even when i was in the womb, i said, "mommy, the start of your heartbeat can be detected by noting the difference between the current sample of your blood-pressure, minus the previous sample, and the only time that is different than a positive value is at the start of your heartbeat, so i'm going to use "delta~" to track that difference right at the start, and sync my heartbeat to yours", and she said, "good boy, now please stop moving around so much, you're such a nuisance goddamnit!")
for me this example lines up with the 'downbeat' of the phasor:
(^from there, you can also work in Roman's suggestion above to shift phase further)
hope it helps(especially to understand why the [delta~] and [<~ 0.] combination is most accurate for tracking the starts of phasors) 🍻
[edit: also, if you're converting all of this to midi and events, might even be preferable not to use this sample/signal based solution, SourceAudio has given good examples elsewhere of more preferable systems for this.]
Hi Raja,
Sorry I wasn't clear: I understand that 0.5 is the middle of a ramp. By "at the end" I meant the end of the chain.
I also understand the usage of delta etc. I want to use 0.5 because then I can shift the execution of an event earlier or later in "time" at audio or max message rate. Time being relative to most of events occurring around 0.5 of a 0.-1. ramp.
Thanks!
Thanks for the example patch as well. I understand it completely and have used that implementation many times. Again, I am looking for something where events can occur "ahead" of the normative "downbeat" if that makes sense.
Thx!
that´s the good old problem with phasor ramps in general; one could think that you would just use > 0 or > 1 to get a transition, but it doesnt work because of how 32 bit / 64 bit numbers work, so you use > 0.5 and that causes the sequencer´s start button now to have an unpredictable delay and makes the math in other parts of the patch more complicated.
(normally it would stupid to give you an complete alternative solution to what you had in mind, and which would be influenced by my personal opinions and requirements. because, as some here know, i would of course like to recommend to stay away from that "1n" stuff and use milliseconds and hertz instead, only because i dont like 1n)
your patch is a great example for a dead end, which you drove in although you saw the sign. :)
the pictures are not the best answer to your question, but maybe you have fun playing with the ideas they contain.
oh, and with raja´s delta~ object. play with this, too.
Thanks!
Yes, the whole point of max is to drive off road///// :)
Thx again!
Here's a way to use gen~s [wrap] object to shift the phase ahead.
@RAJA: I hear you and agree about delta~ and <~ 0. In this case I use >=~ 0.5 to prevent extra triggers when the phase offset changes.
@Holland ^ah, that's a great solution... no worries, i misunderstood the OP's original line/intention about:
"[>~ 0.5] into [edge~] is generating bangs at the end of both the master phasor and the [rate~]"
(thought they were trying to track the end(/beginning) of phasor~)
plus, used it as a chance to be irrationally humorous(with my baby rant 🍼👶). my bad. carry on 🎩
in case the retrig (or speed change) comes from scheduler rate, and phasor speed will never exceed e.g. 100 Hz , a simple gate~ before the edge~, which you send 0 followed by a delay 1, is a safe bet.