Hi people,

Can't seem to get beyond a strange timing glitch with [vline~]. I'm using [metro] to bang a [float] that will send [vline~] the message [0, 1 $1( describing its throw and ramp time. For some reason, no matter what the [metro] time is, the [vline~] will only oscillate from 0-1-0 every 300ms. When viewed in an array, you can see the wave of the [vline~] ramp changes as you change the [metro] time and ramp time, but when measured via [timer], it comes out as 300ms.

I've had the same problem when using [phasor~] too. Here is an example of what I'm talking about: timerproblem.pd

For my example, I have made the [metro] time and the ramp time different, but in my actual patch, I am trying to send the ramp time through a [samphold] triggered by the [vline~] of the same ramp time akin to Maelstorm's timestretch patch:
http://www.pdpatchrepo.info/hurleur/timestretch-vline.mmb.pd

Anybody have any idea whether this is a glitch in my system or am I being dumb? I have the same problem in Pd-extended and Pd 0.49.1.

Macbook running OSX 10.6.8

Cheers

oh shoot! okay. I use a vline~ to feed tabread4~ so the method is a little different

The mtof part is designed to calculate a ratio - so if you input a zero into the left part, the result is one. If you input something like -5, it will give you a value that is less than one. You can multiply that value by the length of the sample in ms to get how long the sample would play back if you wanted it to play at 5 semitones above(?) the base pitch of the sample. You have to choose a midi note to start at. Above that note, the sample will play faster, below that note the sample will play slower. I think I calculate this value by taking the base note and subtracting from that the note from the midi keyboard.

You want to use the tabread4~ method from the (3.7.1.1.) example, but instead of feeding it with a phasor~, try feeding it with a vline~. Then you can calculate the length in samples of your sample. That's the left output of soundfiler. Dividing length in samples by the samplerate~ gives you the lenght of the sample in seconds. Multiply that by 1000 and you have the the length in milliseconds. vline~ takes input in milliseconds. Send it a message to ramp from 0 to the number of samples in your sample in the number of milliseconds you just calculated. If you want to repitch it, also multiply by the midi ratio from above.

If you want to use phasor~ instead, you're setting frequency in Hz. So instead of multiplying the sample length by 1000, you might want to multiply it by the ratio and then get the reciprocal of it with this:

Then feed that to the phasor~

Are you going to use phasor~ in your design? I could double check that there's not a better transposing method with phasor.

Actually, it might be way easier with phasor, You could convert your current input to phasor to midi with ftom, then add transposition in semitones and then convert back to a frequency...

hi folks, thanks for the kind comments!

sure ill share the patch eventually but right now its an uncommented messy laboratory affair. best thing you can do right now is look at the patch image above which is quite self explanatory.

here is the vs rom in one wav file, scan this in 128 chunks of 128 samples and you have the single wave data.

vsallwaves.wav

harmonic aliasing is best described by acreil in the above mentioned blog post because thats where i got the idea from. the rest is trial and error and a lot of listening to integer combinations.

harmonic aliasing is actually my own term for what im trying to do. here is how i would describe it:

• if you repeat 128 samples with a phasor at 128 hz (or 64/32/16/8/4/2) or any multiple of 128 your phasor restarts exactly at the beginning of the wave data and the aliasing frequencies generated by the steppyness of the data will follow the harmonic overtone series 1,2,3 etc. depending on the multiple.

• if you introduce another prime divider ie. 3 as in 128 / 3 the phasor will line up with the sample data every 3rd sample and the osc will alias at the 3rd subharmonic frequency which will be somewhat more disharmonic than any overtone.

• another way to look at it would be the pattern repetitions. at subdivision 5 the phasor starts at 5 different points in the sample data and its easy to imagine that the readout patterns are all slightly different ... but the whole thing cycles after 5 phasor rounds = 5th subharmonic..

• if you subdivide 128 further with a higher prime ie. 563 you will get 562 different sounding samples until nr. 563 lines up again. get the idea?

this is all very easy to hear once you experiment with prime subdivisions and multiplications. just remember its all based on synching the data flow from the sample with the frequency of the index phasor. this will work with ANY sample data, the vs rom is just cool to use for vintage synth fans.

whats important for proper aliasing is that you use a simple [tabread] into the data without any interpolation like tabread4 or oversampling!

all the other elements in the synth like delay, waveshaper, sequencer follow the same rule as they are just repetition devices like the wavetable oscillator.

if you finally synch everything to the sample rate of your soundcard the voltages that hit your speakers will repeat in exact patterns. thats the idea of this synth: precision number repetition controlled by harmonic/disharmonic integer combinations ... just like the great 80s synths waldorf microwave or prophet vs.

update: version 2.0 is available, see below

Hi folks,

My first contribution to the Patch Repo (and greater Pure Data community at large)!

In my own performance patch, I found myself re-creating this concept over & over again with slightly different parameters, and eventually realized I should just make an abstraction to save myself a lot of time & energy in the future.

The basic idea is simple—essentially just feeding [random] into [line] so that values will float around within a defined range at unpredictable intervals (without discontinuities between the ramps). You can set a center value and deviation percentage, so that the ramps will stick close to a value within the overall range. For example: playing sound files with [phasor~] and [tabread4~], I often like to add a touch of warping to the speed, so with this module I can send the phasor speed to argumentname-randcenter, set a range of values around the center (with small deviation %), and let the warping begin without having to redo all of the math.

Also, the module's output is sent to both the outlet and also to a [send] which is set by the creation argument, thus you can use the receive name of an existing slider in your patch as a creation argument, set the min/max and other preferred parameters, and it's ready to go.

Finally, I added the low clip % control to prevent the "jumpiness" that results when very low values of [random] are fed into the right inlet of [metro] (which can sound like discontinuities in certain applications). So, for instance, if your maximum rate in milliseconds (set by rate_range) is 3000, and you set low clip to 10%, none of the ramps will be faster than 300 ms. And, setting low clip % to 100% will result in a regular metro pulse at the specified maximum rate.

Hope you find it useful! Feedback/improvements welcome of course. (and apologies for the messy patching with the min/max/center calculations, still learning how to keep simple math from looking incomprehensible with cables running all over the place…)

randmodule.zip
update: version 2.0 is available, see below

Cheers,
-Jon

Hello everyone, long time no see.

I've been getting back into Pd lately and have been messing around with some granular stuff. A few years ago I posted a [vphasor.mmb~] abstraction that made the phase reset of [phasor~] sample-accurate using vanilla objects. Unfortunately, I'm finding that with pitch-synchronous granular synthesis, sample accuracy isn't accurate enough. There's still a little jitter that causes a little bit of noise. So I went ahead and made an external to fix this issue, and I know a lot of people have wanted this so I thought I'd share.

[vphasor~] acts just like [phasor~], except the phase resets with subsample accuracy at the moment the message is sent. I think it's about as accurate as Pd will allow, though I don't pretend to be an expert C programmer or know Pd's api that well. But it seems to be about as accurate as [vline~]. (Actually, I've found that [vline~] starts its ramp a sample early, which is some unexpected behavior.)

[vphasor2~] is [vphasor~] with an additional signal inlet. This inlet expects another positive-ramping phasor and is used for hard-syncing. When the phasor inlet gets a drop--as happens when a the phase cycle starts over--[vphasor2~] resets its phase to zero. It also does this with subsample accuracy by taking the last and first samples of the phase and estimating when it reset. That's why it needs a positive-ramping phasor as the input. If you try to hard-sync with a sine wave or something, it won't work.

As far as I can tell, everything is working, but let me know if you find a bug. I tried to document the code thoroughly as well.

The sources and helpfiles are included in the zip file. It uses the Makefile template, so just type "make" and it should compile.
vphasor.zip

@phil123456 It's hard to tell with the picture.... but it looks as though sending the number to all of the [pd phaser-bank] objects and letting them decide how to "use" that number would be easiest.
If you make an abstraction of [pd phaser-bank] as maybe [phaser-bank] and then place that many times in the patch with a number argument........
[phaser-bank 1]
[phaser-bank 2]
[phaser-bank 3]
etc.
Then in [phaser-bank] you could use
[r number_being_sent]
|
[t b f]
| |
[$1<]
|
[do it $1 times]
to let the abstraction decide it's action...........

Does that make sense? it was posted in a hurry....
David.

the reason this happens, is because you make a small logic error, in assuming that [t b b] will force the order of execution with the [phasor~] signal object. you are assuming that by using [t b b], that you're resetting the phase first, and then resetting the playback rate. However, signal objects work differently to control objects, and with [phasor~] any control message sent to the right inlet will only reset the phase when the current block is finished.

To ensure that the execution order works out the way you originally intended, the easiest way i can see is to force the [phasor~] reset when the [phasor~] speed is being set to zero. I checked this now, and it seems to work fine.

(by the way, i debugged your patch using [snapshot~] connected to a number box - that's a very useful tool for signal rate debugging)

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

[phasor~] outputs a ramp of values from 0 to 1 in a gives freq.
Let's say that I stop [phasor~]'s ramp just in the middle: 0.5
My problem is that if now I want to restart [phasor~], it starts from 0.5 and not from 0.
Is there a way to "reset" [phasor~] to have a new ramp?
Thx guys.

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

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.