[PD] timing
Dietrich Pank
dietrich.pank at googlemail.com
Wed Dec 22 01:37:41 CET 2010
Hi Mathieu,
There are three ways to get sample-accurate events :
>
> 1. carry the event as part of a signal at the same rate as the audio.
> between apps, this could mean, for example, that you'd use an extra
> channel in jack for those events.
>
> 2. carry the event as a message, then as the last step, convert it to a
> (sample-rate) signal for objects that can use that (for example, use
> a [vline~] plugged into [*~]'s right inlet)
>
> 3. with objects (or aspects of objects) that just don't support
> sample-rate changes, you can use [block~ 1] if you can't find any
> sample-rate equivalent.
>
1. and 2. I don't understand how to approach (I'm on Win btw. but would like
about functionality of Jack if it does something I can't do in Win).
3. I tried as I already mentioned but there must be an error in my structure
because the log window talks a lot of errors each time I try to change the
block~ size...
Could you show me working examples finding and processing sample accurate
timed events? How do you use sequencers? What about fast retriggering
percussives or delay like effects - isn't the jitter bothering you?
> I made abstractions [lop2~] and [hip2~] as signal-rate versions of [lop~]
> and [hip~].
Your abstractions doesn't seem to be part of 0.42.5-extended? I couldn't find
it<http://www.google.de/#sclient=psy&hl=de&q=%22lop2~%22%20(pd%20OR%20puredata)&aq=&aqi=&aql=&oq=&gs_rfai=&pbx=1&fp=9518358c6ae80f89&pf=p&pdl=3000>with
google search either... Where can I find it? And what method (1.,2. or
3.) did you use?
> - my patch only accepts 64 - why?
>>
>
> If you use FFT, your patch has to know the block size, as a [fft~]-[ifft~]
> pair is like [*~] by the block size.
no FFT yet
> - why does the $0-audioscope show extreme high amplitude when block~ size
>> is <64 ?
>>
>
> Does it double amplitude when you halve the block size, or does it double
> amplitude when you quadruple the block size, or some other pattern ?
> (which ?)
>
it shots out of screen limit, the scroll bar appears and is very small... so
the value must very high. Look at it I attached it (you need to touch some
controls of the audioscope in order to update correctly - I have a bug
there).
> Does it do the opposite thing when you use bigger block sizes ?
I correct myself: it is ok in block~size 64 only, at any other size also
higher sizes it shows the same giant burst.
> - makes it sense at all changing block~ size in order to get better
>> message timing? Or what is it for...
>>
>
> It's for several things :
>
> 1. decrease to get more resolution
> 2. increase to get more efficiency (of cpu)
> 3. change to control the [fft~] window size (which is not controllable
> by its own parameters, unlike [fiddle~]'s window size
> 4. when converting between different sampling rates, change
> proportionally to sample rate, to avoid having to split/merge blocks
> (this rarely matters at all)
>
i see. (well.. 4. I will understand one day I'm convinced ;)
thank you!
cheers
Dietrich
> _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101222/2fd870d0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ugly threshold results.zip
Type: application/zip
Size: 4574 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101222/2fd870d0/attachment.zip>
More information about the Pd-list
mailing list