[PD] [wrap~] issues

[Alexandre Torres Porres]

yeah, I was gonna say something similar

the problem is more likely with phasor~ whose period won't fit
harmonically, this means there'll always be an offset in the next period,
hence, all periods will be different and have some offset. Like cyrille
pointed, you need to have a frequency that matches a number of samples so
it gets repeated always the same.

What you actually need is not phasor~ but a ramp generator that repeats
itself at a fixed number of samples, which corresponds to the frequency you
want. Or a ramp generator that gets reset with sample accuracy.

See [else/accum~] and [else/ramp~]

you could try a hacky way to do something like that with [fexpr~] in vanilla

anyway, I'm not sure I actually follow much of your email, but I'm with
cyrille here, cause wrap~ will just give you the modulo and it's not likely
that it is giving you the offsets

cheers

2018-04-26 17:00 GMT-03:00 cyrille henry <ch at chnry.net>:

> hello,
> I don't think your probem is with wrap~.
>
> if you create a phasor at 25x120 = 3000Hz, using a 44100KHz samplerate,
> you will notice that all ramp have different amplitude.
> This is because a ramp have 4100/3000 sample = 14.7 point for each ramp.
> if you switch to 48KHz, you will have 16 sample per ramp, and all ramp
> will have the same amplitude.
> This also create phase isue.
>
> So, I gueess you should use a fps that is compatible with your samplerate.
>
> cheers
> c
>
>
>
>
>
> Le 26/04/2018 à 21:23, Derek Holzer a écrit :
>
>> Dear Pd friends,
>>
>> can you help me to understand [wrap~] better? My purpose is to create a
>> "video raster" (using audio signals at a high sample rate) of X and Y
>> values to read luma information from [pix_data].
>>
>> To do this, I have one [phasor~] creating the vertical ramp, at 25 Hz (=
>> 25 frames per second).
>>
>> Then I require another series of ramps from 0 to 1 for the horizontal
>> lines. If I want 120 lines per frame, I do it like this:
>>
>> [phasor~ 25]
>> |
>> [*~ 120]
>> |
>> [wrap~]
>>
>> This gives me 120 ramps for every one cycle of [phasor~]. So far so good.
>>
>> However, the ramps I get are not equal in amplitude, there are tiny
>> variations which cause distortions in the raster, and which I can see when
>> I plot the ramps to a array with [tabwrite~], and which I can see as a
>> jagged edge if I plot my raster out on an XY oscilloscope or similar.
>>
>> Also, the ramps have some phase issues. 25 frames with 120 lines per
>> frame works just fine, but as I adjust the frame rate or the number of
>> lines per frame, the image data which I get from [pix_data] seems to
>> "rotate" out of the frame and wrap around to the other side. Only multiples
>> of 25/120 give me image date which is centered in the frame of the video or
>> image being analyzed by [pix_data].
>>
>> I would be happy to make a video of this if you like, but I wonder if
>> someone with better DSP knowledge than me might have some suggestions.
>>
>> You can see the patch in question here:
>>
>> https://github.com/macumbista/vectorsynthesis/blob/master/V-
>> scanprocessor-help.pd
>>
>> (Requires checking out entire Vector Synthesis library. Also requires PD
>> >= 0.47 and Gem if you want all of it to work. Open the [V-scanprocessor]
>> object to see the [phasor~] and [wrap~] configuration.)
>>
>> Andy Farnell suggested that the amplitude differences in the ramps may be
>> a cumulative 32 bit precision error, but that would not explain the phase
>> issue. I also tried using sample-rate [metro] and [line~] objects to create
>> the horizontal lines but this was even less precise.
>>
>> Thank you for your kind attention!
>> Derek
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
> stinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180426/dd35740b/attachment.html>