Hi,

im having some problems with audio in Pd. Im running extended 0.42.5 in Linux and midi is not working. The midi out test in the "midi and audio test" does not make any sound. This errors ocurrs in the inicialization:

audio I/O error history:
seconds ago error type
2.90 A/D/A sync
2.90 A/D/A sync
2.96 A/D/A sync
2.96 A/D/A sync
2.96 A/D/A sync
2.96 A/D/A sync
2.96 DAC blocked
2.96 A/D/A sync
2.96 unknown
2.96 unknown

does someone knows what is going wrong?

thanks in advance,

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.

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?

Hey
I'm using phasor for an index to a tabread~ to play a sample.
I'm also using line~ as an envelope to control audio output.

The timing for the envelope is set by the size of the sample size and samplerate~ as well as the frequency for the phasor~.

The magnitude of the phasor is adjusted to the sample size.

The sample player can be re-triggered and when this happens a line~ is set to go to 0 in 5ms,
a delay is set for 5ms,
then bangs another line~ to go to velocity in 0,
as well as setting phasor~ frequency to 1/t and phase to zero.

At which time another delay is setup at samplelength in ms.

After the sample is played the phasor~ frequency is set to 0 then
another line~ to 0 in 5ms is sent to the [*~] .

This causes a glitch when the sample is retriggered because the phasor~ is reset to zero and starts replaying the sample.

This glitch can not be heard when the sample is not re-triggered so maybe it's a control vs signal timing issue.

I did hear the glitch at the end of the sample re-triggered or not using vline~.

So my question is how do you do audio rate envelope triggering of envelopes ? I would post the patch but it is a mess. A good answer or pointer to some reference material would be greatly appreciated. I haven't quite wrapped my head around the sample and hold sampler examples yet.

At first I was gonna write: "Strange. The only thing going into phasor~ in my patch is a number representing the speed (it's about 0,002 with the song I'm using as test-song). I don't see how that fits with what you're telling me. ??" and not try it out. But I didn't want to ask about things if I didn't have to.
I tried it out, and discovered that I was right: The number that goes into phasor~ controlls the speed. In other words: When I put a line going from 30000 to 500000 into it, all I heard was noise because the song played really(!!) fast in a loop. This also reflected in the time-bar below the waveform.
Is there something I have overlooked or misunderstood??
Anyway, if it is and I can use this: I need the start and stop to be flexible, so I can set it along the way. I messed around with this a bit, using $ (from the slider_resize.pd) and pack/unpack and stuff, but nothing worked.

The resize-tip gave me nothing new, but thank you anyway.

I'm hoping this 0-1 square wave conversion may solve the following similar issue:-

How to automatically stop a phasor one cycle after re-setting the phase.

I have tried using the samphold~ object combined with env~ or snapshot~, so that when the phasor wraps around, the samphold~ samples a 1 signal, which can then be used to set the phasor to zero (effectively stopping the phasor). See below:-

[r $0-phasestop]
|
[0(
|
[phasor~}
| \
| \
| [sig~ 1] \
| | \
| [samphold~]
| |
| [env~]
| |
| [sel 1]
| |
| [bng]
| |
|

However, it doesn't seem to work, perhaps it creates a feedback loop. Is there any way of telling the phasor to run for only 1 cycle at a time?

Well, I was about to refer you to a post on hard syncing I did, but I realized it was in response to you. So now I'm thinking I don't fully understand your question. Syncing oscillators should always be done with a master [phasor~], so you wouldn't really toggle it so much as you would alter the output of the master [phasor~]. (Just in case my earlier response didn't make that clear.) Are you maybe asking about phase offset? If so, you can do it like this:

[phasor~]
|\
| \
| \
| [tabread4~ mywave]
|
[+~ .5]
|
[wrap~]
|
[tabread4~ mywave] <--will be synced to above oscillator,
but 180 degrees out of phase

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

oh, thanks, that's cool - i'm bad at maths, but if i got it right, the factor in the [*~] object is the result of dividing the sync osc's frequency by the frequency of the osc that's getting synced, right?
what, if i want a sine osc as syncing source? i have always to build my own one with a phasor~ and cos~, so that i have a phasor~ to sync other osc's?
sorry for my poor english, hope you got me......

Hello I installed Pd, jackd and Alsa via apt-get i have debian 5.0(lenny)

Sometimes the sound works, when work it appear an error message:

audio I/O error history:
seconds ago error type
0.14 A/D/A sync
1.00 unknown
1.52 A/D/A sync
5.76 unknown
5.76 unknown
tried but couldn't sync A/D/A
audio I/O error history:
seconds ago error type
1.40 A/D/A sync
3.38 A/D/A sync
3.69 A/D/A sync
7.12 A/D/A sync

when don't works appear this:
couldn't open MIDI input device 0
couldn't open MIDI output device 0
opened 0 MIDI input device(s) and 0 MIDI output device(s).
audio I/O error history:
seconds ago error type
4.69 unknown
4.69 unknown

thnx