@nicnut especially since the freq is so low, it shouldn't matter. But I agree with you--if it sounds good then that's all that matters.

@nicnut [osc~] is equivalent to [phasor~]->[cos~] (and there's no way to mix my way with your way as far as I know), but you're enforcing sync on the positive zero crossing of the base freq oscillator, and my way syncs on 1 (i.e. the start of the cosine cycle). You can shift the phase of my scheme to be equivalent to yours by subtracting 0.25 from the base phasor, thereby making the output of the following cos~ a sine wave filtermodwrap.pd. To my ear, this sounds the same as yours.

But in the title of your thread, you asked how to make all the oscillator's positive zero crossings line up with that of the base freq oscillator. If that's really what you want, then you should shift all the oscillator's phases (filtermodwrap.pd ),

Edit: this used to be much more of a stream-of-consciousness mess, but I saw you hadn't logged on in a while so I took the liberty to revise what I wrote to make it clearer. Ha, and now I see we cross-posted, oh well.

@nicnut I think your solution is fine for low frequencies, but things get funny at higher ones (that aren't really very high at all in the scheme of things, e.g. 87hz). That's because threshold~ has to wait until the current audio block has been processed before it can sync your other 2 oscillators, hence the jump at the yellow arrow. The way I suggested doesn't have that issue.

@nicnut If the frequencies are integer multiples of a base frequency, then you can generate them using a phasor, a multiplier and wrap like this:

@PD-Pi Oh sorry, I didn't mean to digress, I honestly thought this was relevant to your original question.

@manuels That's clever, thanks! I especially like how you get the slope of the input phasor (compensating for that downward jump every cycle) and how you construct the output phasor. But I think there are two issues with it. Firstly, a sync will reset the phase of the output phasor at an arbitrary point unless the output phasor frequency is an exact multiple of the input frequency. Secondly, without sync, I think the output phasor may drift WRT the input phasor due to floating point roundoff error. Agree?

Backing out to look at the big picture again, i.e. Brendan's question, this means that it couldn't be used to make either a "hardsync" synthesizer (disclaimer: I don't really know what that is) or a "phasor~-synchronized system", assuming that both require a precise phase relationship between the input and output phasors and that the output phasor doesn't contain discontinuities. What do you think?

@ddw_music Yep, more reasons why it would be great to see a patch.

This morning I'm thinking that in the case of equal temperament, would sync between two oscillators even be meaningful? If the ratio between two pitches is a floating-point approximation of an irrational number, well gosh, that's as complicated as having no sync at all, isn't it?

@PD-Pi Yeah, but the devil's in the details. I'd love to see a patch.

@PD-Pi Just read the documentation for rate~...also interesting. I wonder how they do that?

@Obineg Interesting. Can you show me a patch that, say, generates all 12 equally tempered tones starting with middle C from 1 phasor?

@porres Yes, on MacOS 14.4.1 using Pd 0.54.1, I created an aggregate device using the built in speakers and my Yamaha 01V96i. [dac~] inputs 1 and 2 output to the built in speakers, and inputs 3 and 4 output to the first two USB sources on my mixer. I've never tried on a Windows machine though.

PS Oh but to get inputs 1 and 2 working I had to fiddle with the volume control a little, not sure why

PPS And to be clear I used Audio MIDI Setup in MacOS to create the aggregate device, not the "Use Multiple Devices" option in Pd (which may not be an option on a Mac, also not sure)

@PD-Pi Wait, if each clone instance is a voice, then they can't share a single phasor because then they'd all have to play the same pitch, which is not my understanding of a polyphonic synth.

@brendanmac I'm not a synthesis guy, but a friend told me that you sometimes want your ADSR synchronized with oscillator phase to make attacks sound consistent. So maybe that's a reason to not use a single centralized phasor? Looking forward to the replies of more knowledgeable folk.

@EEight Just to add on to what David said, multiplying an audio signal by -1 is the same as using a phase-inverted cable.

@brendanmac The Pd help examples contain two ways to address aliasing. J07.oversampling.pd shows how to use oversampling to create a better alias filter--just replace the phasor with your preferred method of generating square waves. J09.bandlimited.pd replaces the jump with a specific kind of squiggle, but for a sawtooth. If you want to do the same for a square wave, I think all you have to do is replace the phasor~ with the equivalent triangle wave. It's called "transition splicing" in Miller Puckette's book https://msp.ucsd.edu/techniques/latest/book-html/node196.html

@seb-harmonik.ar In other words "technically 32 but really 64" since the effective sample rate inside the blocked patch is half. Sort of like agreeing to repay double your loan but waiting until inflation has eroded the dollar to one half its value.

@seb-harmonik.ar Lovely explanation, thanks, but can you say more about

actually, [bang~] can go lower than 64, it just can't go lower than 64 per the root patch samplerate.

How can I make [bang~] output (and execute control rate logic) after each 32 (for instance) sample audio block is processed?

(Apologies to @mbbaker for hijacking topic)

@mbbaker I never use downsampling so I can't explain that behavior off the top of my head, but I know that the fastest [bang~] will output is once every 64 samples, which you can see documented in {bang~] help. That explains the behavior when there's no downsampling.
I modified your patch to display a ramp that goes from 0 to 1 every 64 samples to see what's going on: tabwrite~ half table.pd Now I can see that 128 1 1 is equivalent to 64 1 0.5, but I'm struggling to understand why.

If you're more interested in doing rather than knowing, try substituting [tabsend~] for [tabwrite~]. That consistently writes the first half of the table but I'm not sure if it is excerpting the signal in the way you expect. Unlike @Maelstorm's windowing solution that @whale-av linked to, it doesn't overwrite the second half of the table. [tabsend~] outputs continuously so if you need to initiate it with a bang then you should look into [switch~]

@oid On Windows Pd sometimes runs weirdly slow when the selected audio interface is unhappy for whatever reason. It's usually accompanied with terrible sound or silence which @ionicle didn't mention, so I was also hesitant to suggest that possibility. @ionicle: maybe try selecting a different output to see if you get better results?

@FFW Thanks, your approach is the way I was originally thinking about it, but since I'm new to dynamic patching and my clone has a lot of connections, I started down a slightly different path. Since I know I can set a $n argument from an enclosing patch, I was thinking I could make a wrapper for my clone patch and instantiate the wrapper instance dynamically with the args set to the values I want. But even this is moot because in my prev post I discovered that there are simpler ways to achieve my goal than trying to parameterize the clone start index flag.