boonier: I didn't realize Pd's [metro] is that tight. I guess I just assumed I'd run into the same problems I did with Max.

Here's the setup I use for [phasor~] clocks:

[phasor~]
|
[*~ 2] <--used to divide beats, e.g. if [phasor~] cycles at a rate of one 4/4
| measure, 2 will give half-notes, 4 gives quarters, and so on
[wrap~]
|
[expr~ $v1<.5]
|
[edge~]
|
[bng]

What's also nice about this is all of your beat divisions can link up to one [phasor~]; and if you stop the [phasor~] inbetween beats, you can pick up exactly from that point without things getting out of sync, which you can't do with [metro]. I haven't done this yet, but you could also use one of the [wrap~]s to lookup, say, a drum loop in an array, so when you speed up or slow down, the loop will stay tightly in sync as well, albeit with pitch changes.

Ok: what it does is derive a second phasor from its input phasor.

If you want to go from [phasor~ 2] to [phasor~ 4], you can just use [*~ 2] and [wrap~]. If you want to go from [phasor~ 2] to [phasor~ 1] or [phasor~ 3], just using [*~] and [wrap~] won't do the job.

The patch I posted does some differentiation and integration, taking into account the jump in phasor~ and wrapping the output while integrating (to avoid float precision problems)

And now I realize that this is the solution to a different problem - will see what I can come up with for the real problem...

I'm not sure that the annoying scratchy sound is caused as you say. More likely it's aliasing that you will get whenever you frequency modulate a phasor. The best way around this is to use a band limited sawtooth instead of a phasor.

Any instantaneous change in frequency will be heard abruptly, so you really want the smoothest change possible throughout the duration of each cycle. You could control the phasor frequency with a smoothed audio rate signal [sig~]-[lop~ 3]-[phasor~].

To answer the last question. Make your own phasor with [vline~] and [metro]. The slope remains constant between bangs.

To get reverse playback you could subtract the (phasor output x sample size) from sample size, ie. for sample size of 44100:-

(phasor~)
|
(*~ -44100)
|
(+~ 44100)
|
(tabread~)....etc

To jump around slices you could use a sample + hold object to add chunks of a specified number of samples at each phase wraparound, like this:-

{100} {200} {300} {400} etc... messages to send to samphold~
|
| (phasor~)
| |
(samphold~)
|
(+~ ) ... add phasor output times the chunk size (eg. 100 in this case)

the phasor output triggers the samphold object to output its current value at the start of each phase, so that each time a chunk has finished being played back, the index for tabread can be forced to jump to a new location. shouldn't be too hard to send an automatically cycling pattern of index numbers to the tabread object, and then introduce reverse in there too...

Brett

Short version: Is there a phasor~ analog which functions in the control realm of pd?

Long version: I've been messing around with using Signals to play samples with Tabread4~ and the modulationg them etc. The basis of most of these "loops" is a single phasor~. It would be great if there were a control rate phasor that would allow me to sync two tables, one for audio data and one for performance/control data. I've been using Counter from the GEM and a metro but this does not seem like the most elegant approach as it has dependency and is harder to sync with the phase of the phasor~.

Any suggestions?
--Nestor

_for example: I want that a bang message is sent whenever a [phasor] obj
is at 0 . _

I don't know whether there is an object that does that, but you could make an abstraction to do it.

You can use [expr~] with relational operators ( > , < , = , etc ), and I think Zexy has an object [avg~] which outputs the average of each signal block (signals are processed in blocks of (usually) 64 samples).

One thing you have to be aware of is that there may not be a time when the phasor~ is exactly zero, because the period of the waveform might not be an exact number of samples.

Something like this might work, though:

[phasor~]
|
[expr~ &#036;v1 < 0.05] <-- change 0.05 by trial and error so you get one bang per cycle of the phasor~ (try [expr~ &#036;v1 < &#036;f2] )
|
[avg~]
|
[> 0]
|
[select 1]
|
outputs a bang at (very slightly after) the start of the [phasor~]'s cycle

Hi,

I'm just getting started with Pd on Fedora Core 3; installation was pretty painless thanks to the CCRMA repositories, but I've run into an issue when I first tried to make some sounds with Pd. I recreated Miller Puckette's example of a constant amplitude scaler. When I start the audio, the signal seems to take a few seconds to 'settle' into a constant frequency; I get a few seconds of static that eventually turns into the sine wave I was expecting. When I click the DIO errors button, I get a bunch of A/D/A sync errors, as follows:

audio I/O error history:
seconds ago error type
0.73 A/D/A sync
0.73 A/D/A sync
0.75 A/D/A sync
0.94 A/D/A sync
0.94 A/D/A sync
0.95 A/D/A sync
1.01 A/D/A sync
1.01 A/D/A sync
1.10 A/D/A sync
1.10 A/D/A sync
1.11 A/D/A sync
1.11 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.17 A/D/A sync
1.27 A/D/A sync
1.31 A/D/A sync
1.31 A/D/A sync
1.36 A/D/A sync

If I let the steady sine wave tone continue, eventually there's a bit of a 'hiccup' in the sound, and then I get the following errors:

audio I/O error history:
seconds ago error type
1.25 DAC blocked
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late
1.25 data late

Can anyone help me out in diagnosing this problem and fixing it? Where should I start looking to fix this?

Thanks!