Blair

I want to make a simple synced counter that goes from 0 - 1, so I can use it to modulate the volume of sounds. But it sounds ever so slightly out of time. In the screenshot you can see little gaps at the start, they are all slightly different sizes of gaps as well which is not good. How can I make it perfectly start on the bar every time?

image.png

scale

cycle~

flonum

metro

snapshot~

phasor~

plugout~

I want to make a simple synced counter that goes from 0 - 1, so I can use it to modulate the volume of sounds. But it sounds ever so slightly out of time. In the screenshot you can see little gaps at the start, they are all slightly different sizes of gaps as well which is not good. How can I make it perfectly start on the bar every time?


I want to make a simple synced counter that goes from 0 - 1, so I can use it to modulate the volume of sounds. 

synced-phasor~-counter-not-perfectly-in-sync

Pretty much don't use max-objects in msp and keep everyting in the msp-realm

, I need to convert the signal to a float number because its for an FFT effect, is it still possible to keep it in sync but not as a signal?

Ty LUVULONGTIME, I need to convert the signal to a float number because its for an FFT effect, is it still possible to keep it in sync but not as a signal?

No, don't think so* but i'm not convinced you'd even actually need the float? I mean if it's for FFT can't you just keep it within MSP?

*anytime you get something from MSP you'll get desynchronization because of the way Max and MSP are structured under the hood. Look it up here:

https://docs.cycling74.com/max8/tutorials/03_msphowmspworks

<Edit> The example above is better because the phasor~ steps through the phase of cycle~ without any Max-object and outputs the value as a float without being (directly) in the signal-chain

No, don't think so* but i'm not convinced you'd even actually need the float? I mean if it's for FFT can't you just keep it within MSP? 


*anytime you get something from MSP you'll get desynchronization because of the way Max and MSP are structured under the hood. Look it up here:
https://docs.cycling74.com/max8/tutorials/03_msphowmspworks


 <Edit> The example above is better because the phasor~ steps through the phase of cycle~ without any Max-object and outputs the value as a float without being (directly) in the signal-chain

Unfortunately i have to keep it as a float because i am sending it to a multislider, which some special effects are being applied to, and then all multislider vals are being put into the fft. 

Would a synced counter that doesnt use a phasor be able to be synced perfectly? If so what would that look like?

Unfortunately i have to keep it as a float because i am sending it to a multislider, which some special effects are being applied to, and then all multislider vals are being put into the fft. 

Would a synced counter that doesnt use a phasor be able to be synced perfectly? If so what would that look like?

"Unfortunately i have to keep it as a float because i am sending it to a multislider, which some special effects are being applied to, and then all multislider vals are being put into the fft."

Ok, my take on this would be to store the values coming from cycle~ in a buffer and perform your effects on this instead and you connect the buffer to the fft. You can do all of this inside MSP if you really need the UI-aspect of the multislider . Have a look at the patch

Hmm okay I am starting to understand. Thanks for the help, I'll try implement this into my project tomorrow

Better use this patch instead as i cleaned it up a bit, no need for a second phasor. You can also drive it from the main one as well to keep everything in sync. And keep in mind that the resolution of multislider is set to 100 which means you have the same value for every 480 samples. Multislider has a max of 4096 so you'll have to figure out a way to make up for those other values if you need a higher resolution.

Okay cheers, luckily i only need 256 sliders :)

I took the essence of your idea with the peek~ index~ and buffer~ and figured something out. I now have a bit of random preringing problems but other than that it works pretty great so thanks! There is just one feature I dont know how to add if i'm using an audio ramp, I have a feature that rotates the multislider to create a sort of phaserish sound spectrally. But how would I constantly rotate it using the audio ramp?

inside an fft you would use things like piwrap or count~ or the fft index inlet.

for the phasor~ object you can do phase offset like this:

for the phasor~ object you can do phase offset like this:

[phasor~]
[+ 0.4]
[%~ 1.]


Could you explain the piwrap / count / index inlet idea a bit more I'm not sure i understand and could only see an fft index outlet on the fftin~ object

here's a patch that can help you further understand the inner working of pfft~, it uses the old-school capture~ object to help you see the exact bin-count and you can feel free to stick capture~ anywhere else if you need to understand exactly what's going on within a pfft~(very useful to understand how 'magnitude' can differ from 'amplitude' and how 'phase' will wrap between pi and -pi, etc...), just don't leave capture~ in your final patcher, it can still drain cpu unnecessarily:

(^if you save that on your desktop as 'pfftest.maxpat' then you can just create a quick patch in Max like so 👇...

Screenshot 2023-01-25 at 2.55.38 PM.png

...and then just double-click on the pfft~ to open it up and double-click on capture~ within to see the signal values right there within the context of the pfft~ voice)

This is just to explain one way to synchronize different things to the bin-index outlet of fftin~ and help you snoop how things work within better(see count~ helpfile under the 'signal' tab and that can explain how you can use count~ as well, but the phase-vocoder tutorial i linked you to in the other thread also shows a usage of count~ as well).

Synced Phasor~ counter not perfectly in sync