Ah, and I see in addition to your message you wrote vline~ in the title! Oops.
I don't know what click2bang~ does-- is it aligning its bangs to block
boundaries? That's just a guess.
-Jonathan
>________________________________
> From: João Pais <[email protected]>
>To: PD-List <[email protected]>; Jonathan Wilkes <[email protected]>
>Sent: Tuesday, January 24, 2012 6:53 PM
>Subject: Re: [PD] precision of vline~ and/or pd messaging
>
>Hmm, I have to correct your message to get a more interesting answer from you
>:)
>
>the SR is 48K, and I'm using vline~ already. Theoretically with E Lyon's
>objects I should also get more messaging precision, or maybe not at all?
>
>João
>
>> 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 <[email protected]>
>>> To: PD-List <[email protected]>
>>> 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
>>>
>>> _______________________________________________
>>> [email protected] mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>
>
>--Friedenstr. 58
>10249 Berlin (Deutschland)
>Tel +49 30 42020091 | Mob +49 162 6843570
>Studio +49 30 69509190
>[email protected] | skype: jmmmpjmmmp
>
>
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
