Embarrassed? I will be! Phase shifting control waveforms.
I suspect this is going to be very, very obvious (hence the pre-emptive red face), but I’ve been unable to figure this out…
I’m using [function] (with curve turned on) to create curves to control LED lights via DMX.
There are 4 banks of three lights, mainly using RG&B. I’m going to parallel one light in each bank with the same one in the other banks – ie grouping 1,4,7,10 etc. So I need 4 control waveforms. (I’d be happy to send ramps to each one separately, but I think that’ll depend on the method for controlling the phase of the controlling waveforms and how CPU intensive it is).
So – I can have either a metro/counter or phase~/number~/scale combination stepping through the [function]/ I want to be able to chase the phase of the final output so that eg the reds fade up and down, and the blues start 1/3 of the way thru the cycle.
So I have to either apply "phase shift" to the float numbers coming out of a single [function], which I suppose I could do with [pipe], or
use several locked [phasor~]s to drive thru several copies of the [function] (which would allow me to have different curves for each bank of colour) and change the phase of the signal from the phasors. I thought I could do this by sending a float from 0.-1. to the right inlet of phasor~, but it doesn’t do anything (at least not with [phasor~ 1n @lock 1])
I’ve played with [+~] & [wrap~] & [pong~], but the effect is not actually to just shift the control waveform in time. I thought [delay~] might be the answer, but I can’t seem to get it to do anything with the output of a [phasor~] (I guess [delay~] only works with audio rate signals?)
So that’s where I’ve gotten to. All I want to do is to continuously move control waveforms in and out of phase with each other. Any input?
ok, sorted it. [delay~] was the answer. but for some reason it took a bit of fiddling with it to get it to do what i wanted.
well, delay~ won’t really phaseshift anything. It’ll just delay it, so you won’t be able to, say, go negative phase, for instance, right?
Yes, it’s positive only, though I’m still shifting the phase of one LFO wave relative to another aren’t I? (OK, maybe not a technically correct use of the language on my part :-) ).
So is there a way to -ve & +ve phaseshift then?
"hence the pre-emptive red face"
"I thought I could do this by sending a float from 0.-1. to the right inlet of phasor~, but it doesn’t do anything (at least not with [phasor~ 1n @lock 1])"
ya, not with lock.
if you combine this idea: "or use several locked [phasor~]s"…
…with this idea: "I’ve played with [+~] & [wrap~] & [pong~],…"…
maybe this idea might be more helpful:
----------begin_max5_patcher---------- 655.3oc6XssiaBCD8YxWgEu1zU1FLW1m19cTsphXbHtKwFANpo6pMe6EafT1 1DhSZpUdHuvkgwCm4blY3xay77WH2xZ7AOB9Jvy6sYddFSZCd8m64uNaKsLq w3leCUVw14Ou6RUYJ5Jtn3a0LppKLoo3GfyAgQI5cHr4rzvGffm6WjXyZ4FU ISYhHr2JO2De4hu+Yb3P7oYkTpbivDaBBO3agP1dGK4zWzW.0adwlkM7WYZS XRTuwkETYortCbHMXf62fFgpEi8Cdb+Jp44evy.bZXKxN1QgDXZx3bmKFRcr 116ylo2L+Jy+AwAWN+Gbm+OF+KX+nkhF3GEaqgZ7+zt16ULYBcAgIFo.AMBC wPEX3Q0kARcoTnFXUjNBcl67T8yJVW38aZEkrR+8Qardh7GELQ1ZyZ7+RMuc A+mIlJonXG.Af.jMjSfgbhCcH4fOSxI3JW0LYQCJJsqngXFpRbGufRu4KZFH m.hyKZfNnnw1Q833K+Qsnj6i5ujlV7jcsvDRWWajqG0ihu46ZGHmfHW20hhb PWqRVTTxl7YcXyC4BgCYtU4+eknbcq5gxRxAyEz0SnU0YhlJYsZxgycxb+HZ b7IRyzyTl0Y+786VVJyNxAGxqCyagNn0w1Y5njK+02Q2e88ydz0prFYc6vKA 3oRI8kImf0KQQcBEJwgCvfNnDk8ZdFcxRTjoNHnKyC2+lo1WgFcRvZhkeIW7 m+cBCdz1+XFzH2TSGXvApB7aHkyZTbQlhKEibR+gQibZEOOmIFi4077JY6zi dP.d9f7osXR+oFmFSgtESVwSANESVoc5uOwk7DxFdB6VdJ0FLAuA0tX2hoXa vTzMHO439tHavThawDwFL8uLyr8j2m8KeKDN+B -----------end_max5_patcher-----------
thanks for that, and yes, that looks like something that’ll do what I want. I actually went back to the idea of using sequenced bangs to trigger curve~, and that’s working nicely now. However, i’ll revisit the original idea in light of your input, so thanks again.
@raja_tra I must be gerring slow – I didn’t notice that one at all. as you say – hahahaha :-)