Howdy.

I'm very new to pd, having just installed it to see if I could use it to create a synth I have already designed.

At the heart of the synth is a pair of sync oscillators. So, to recreate it, I'll need to be able to reset an oscillator to the beginning of its cycle every time a master oscillator crosses zero.

After searching, I read a couple old posts dealing with generally ineffective ways to detect zero crossings, and then chanced upon a post that mentions [zerox~]. Apparently, it detects all zero crossings (2 per cycle of a sine wave) and there is no help file to speak of.

Does anyone have any experience with this object? I'm interested in knowing if it is practical for audio-rate detection.

I'll be doing some experiments of my own, which will progress slowly as I familiarize myself with pd.

Thanks

If you plan on using [xerox~] to phase sync two oscillators, it probably won't cut it. Generally, you want those things to be sample accurate. [xerox~] will give you a click corresponding to zero crossings out its right outlet, but, as far as I know at least, Pd's oscillators can't really use that for phase syncing ([xerox~] is actually based on a Max object, yet strangely Max's oscillators can't use it either). It would require a conversion to message rate to reset the phase, which kills sample accuracy, not to mention the fact that the phase input of [phasor~] quantizes to block boundaries (default 64 samples in Pd), which also kills sample accuracy.

However, if you know the ratio between your two oscillators, phase syncing can be achieved using a master [phasor~] to run both oscillators. Use the master sync frequency to drive the [phasor~], then multiply the output of the [phasor~] by the ratio between the synced (slave) oscillator and the master one. In other words, it should be multiplied by:

slave frequency / master frequency

Then, you just [wrap~] the signal and viola, you have a new synced phasor signal to drive the slave oscillator. The attached patch should hopefully clarify.

http://www.pdpatchrepo.info/hurleur/phase-sync.mmb.pd

Ah. Great. Thank you.

That's really helpful. I'm glad that there's a practical method for this. I'm enjoying working with pd so far, and I'd have hated to have to compromise with some other program if this didn't go through.

I'll experiment with this technique and see how far it will go in terms of getting a "nice" hard sync sound. I'll have to get more familiar with the concepts, but I'll post my findings eventually.

Thanks again

phase-sync.mmb.pd is pretty great and very clever but I am wondering if there is a more direct approach and I one in mind that I can't implement.

Example:

If the master [phasor~] is playing 440hertz and someone wanted to sync it to 880hrz wouldn't it be possible to hard sync that [phasor~]@440 by banging "440" into it repeatedly, at a rate of 880 times per second, reseting it's phase to zero each time? I know that [bang] does not operate at an audio rate up to 44.1k, but if it did... I would prefer this method. Is there any way to do that?

Well, the result of that would be equatable to

[phasor 880]
|
[*0.5]

The catch with the sync is that there's basically always a more efficient alternative.

If you want a construct that's equatable to
bang X frequency X times a second

you could use phase-sync.mmb.pd and add two frequency controls that calculate the ratio between the two. Then feed the phasor~ with the first frequency and send the ratio to the *~

so

frequency 1 = 440
frequency 2 = 880

440/880 = 0.5

send frequency 2 to [phasor~] and 0.5 to [*~]

like above

you don't lose anything by driving this construct with control messages or with audio rate control. The considerations are only superficially different than using bang.

It's been a while since I've looked at phase-sync.mmb.pd, so it might do this already.

If you're interested in using sync as an oscillator feature,

if you can understand this, I personally can't digest it:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.1036&rep=rep1&type=pdf

otherwise, casio-style is handy:
http://en.wikipedia.org/wiki/File:Casio.CZ101.resonance.png

and if you're okay with the licencing implications, there are objects in extended that offer competent band limited sync. I forget the name, but the group that I'm thinking of has sync saw and a band limited comparator for PWM and square sync.

The reason using bangs to reset [phasor~] doesn't work is because the phase updates at block boundaries. So if you reset [phasor~] in the middle of a block, the phase won't update at that sample; it will be at the beginning of the block.

I made an abstraction that gets around this limitation and so allows the phase update to be sample-accurate. While this might seem more intuitive, I'm not sure it would be more efficient than the above method. And, you won't be able to smoothly change the sync rate. You can download the abstraction here:

http://puredata.hurleur.com/sujet-4039-phasor-sample-accurate-phase-reset

Thanks, you two. You both seem to be on the same page as I in terms of what we want Pd to do. I am working about 30 hours a week on building something like a Casio VZ/opl2 chip; having both phase modulation and phase distortion w/ a sync function for the phase accumulator. Also, sine functions will be able to flip shape to halfsine, quartersine, etc much like the 2op Yamaha opl2 chip. LarsXI: I use your [expr~ if($v1<$v2, ($v1*(1/$v2))/2, ((($v1-$v2)*(1/(1-$v2)))/2)+0.50] for PDist DAILY.

THANK YOU!

Also, LarsXI I am well aware of the CZ waveforms you linked me to. I have never owned a CZ but I am assumed they are derived by hardsyncing the phase accumulator (or sine function...for some reason?). Do you have any idea whether the knee adjusting phase distortion occurred before or after the hardsyncing on CZ's? I am just wondering what order of function would be best and I am leaning toward:

[phasor~] --> knee adjustor --> hard-sync --> phase modulation input --> [cos~] --> [dac~]

But really, I am just taking stabs in the dark for most of that.

Any suggestions?

JF

P.S. Sorry if the above was FAR off the topic of this thread!

Haha. It's a coincidence. A couple months ago, I was stabbing around in the dark as well along similar lines.

I came to a conclusion about a good way to do cz style sync with FM, I'll attach a mock-up. This patch is a pretty solid solution.

This might not be the best way to do it, but it's an improvement over a lot of earlier trial and error oscillators I threw together.

I'd say the weak point is the saw knee generator, actually. With a good enough construct, you should be able to get a better variety of useful angles and avoid using expr~. I've recently done something with this, using simple audio math and a couple of clippers to get better ramps.

Another idea is to use an angle generator that doesn't result in the classic CZ shapes, but has a different range of sounds and is more suited to pure data. I haven't really tried that yet, but it's a case of just trying a couple things that are more intuitive to puredata and seeing how it turns out.

http://www.pdpatchrepo.info/hurleur/lxi_czFMstyle.pd

The one thing about that patch, is that it brings the FM input in first so that the incoming modulation also impacts the sync envellope, that way, everything stays relatively pretty.

Hey guys, I don't really have anything to add to this CZ discussion, but going back to the phase sync approaches, it just occurred to me that my [vphasor.mmb~] abstraction actually uses phase sync to reset the phase. So I threw together this abstraction to illustrate phase syncing using that method. Since it uses two separate [phasor~] objects, you might find it more intuitive. And I'm sure it's efficient as well.

http://www.pdpatchrepo.info/hurleur/phase-sync2.mmb.pd

Ah, that is intuitive.

And this could be used as the basis for a pretty decent hardsync sound, I'll have something in a day or two.

Maelstorm:
Yeah, that's a much better approach and think I might use that instead.

LarsXI:
So you put the knee adjusting phase distortion after the phase-sync...interesting. I can't find very accurate info on how the CZ worked but I am starting to realize that there are much more interesting ways to manipulate phase than what I read the CZ used. I have gotten some interesting results by truncating or compressing the phase with [clip~] and addition or multiplication respectively. Btw... (and this may reveal how new I am to Pd) your knee adjustor expression creates a divide by zero error... is this harmless?

The divide by zero is harmless as long as its taken into account.

What I do with it is make sure I send the whole function a 0.5 on start-up and then I just build my modulation structures so that the function never is fed a 0 or a 1, as that's when the thing falls apart. So I cap my modulation at 0.0001 and 0.9999 or something like that. Sometimes it's useful to limit it more just to cut back on upper partials.

Math-wise there might be a better way. I've gotten a little less new at pd, but I still have zero math background.

I'll attach my alternate knee generator, I just dug this up, it should work as a replacement for the other knee generator, let me know if it works.

http://www.pdpatchrepo.info/hurleur/lxi_newKnee.pd