[PD] precision of vline~ and/or pd messaging

Jonathan Wilkes jancsika at yahoo.com
Tue Jan 24 23:59:48 CET 2012


I'm not sure if this is correct, so someone with a deeper knowledge of Pd can confirm/deny... :)

125ms at a samplerate of (I'm guessing) 44100 would mean you're sending a message to [line~] 

every 5512.5 samples.  Pd's default blocksize is 64, and when you convert from a control value to 

a signal value using the [line~] method then you are forced to start/end the ramp on block boundaries.  

Since 64 does not divide into 5512.5 evenly then there is no way you can perfectly recreate the 

sine tone using this method.  (I haven't looked at your example but I would imagine that [line~] 

forces the "remainder" to occur over the course of an entire blockthus stretching out that part of 

your sine wave to be longer than you want.)


You could recreate it using [vline~] however, because it will let you start/end a ramp in the middle of 

a block, thus giving you higher precision (presumably at a higher CPU cost).

-Jonathan




>________________________________
> From: João Pais <jmmmpais at googlemail.com>
>To: PD-List <pd-list at iem.at> 
>Sent: Tuesday, January 24, 2012 4:50 PM
>Subject: [PD] precision of vline~ and/or pd messaging
> 
>
>Hi,
>
>please look at the attached audio file. It's a recording of a sinus tone stored in an array, played back with consecutive segments of 125ms. If you look at each multiple of 125ms, you'll see there's a glitch in the waveform. That means, the pd patch isn't fully precise aliging the several fragments together. Or maybe the messaging isn't precisely aligned with the audio.
>For this patch I'm using E Lyon's samm~ and click2bang~ to send the messages, theoretically to have greater precision - and then some counters and table readers make several calculations to get the indexes of the segments. After these message-level calculations, the data goes to vline~ reading from a tabread4~.
>My question is then: is it possible to get messaging and audio in Pd ligned up, so that the resulting audio file is as precise as an original osc~? If so, which objects or parameters should be used instead?
>
>Thanks,
>
>Joao
>
>_______________________________________________
>Pd-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120124/bdfdad9e/attachment-0001.htm>


More information about the Pd-list mailing list