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 <jmmmpais@googlemail.com>
To: PD-List <pd-list@iem.at>; Jonathan Wilkes <jancsika@yahoo.com>
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 <jmmmpais@googlemail.com>
>> To: PD-List <pd-list@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@iem.at 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
jmmmpais@googlemail.com | skype: jmmmpjmmmp