On Mon, Dec 20, 2010 at 7:21 PM, Dietrich Pank dietrich.pank@googlemail.com wrote:
Hi list, This is my first post here asking you for help. I built for many years in NI Reaktor (and still do). For this reason I'm used to handle basically 2 signal types: Audio - always sample rate clocked Event - any(!) time, even between samples
Excuse my ignorance, I have never seen NI Reactor, but what does "between samples" mean? I imagine the Event rate is higher than the sample rate?
Now I need to get to know and used to the clock and trigger "secrets" in pd. I want to work efficiently of course but also to be sample accurate if needed.
Pd, by default, does not do any computations per sample, it computes blocks of samples.
Beside having fun with the great freedom and logic of puredata, my aim is to be able to build hi quality audio stuff sooner or later... While building an audio scope (for e.g. debugging) I got stuck in searching sample exact message trigger.
The only way, AFAIK, to get sample accurate triggers is to use [bang~] inside a subpatch that has its block size set to 1 [block~ 1 1 1]. You could probably get close to "between" samples by upsampling (i.e. [block~ 1 1 2]) but I never tried it and the triggers will eventually be re-aligned with the current block size...
I wanna ask you for suggestions tips about my approach. Have a look into attached pd I prepared with comments here and there describing my thoughts and problems. There may be different ways to make audio scopes (I know there is one build-in but it only displayed useless coarse vector lines) but some questions I want to get answered anyhow: my basic questions:
in pd-extended you should be able to use [cyclone/Scope~]. Perhaps it is less useless.
- is it possible to get/fire precise timed messages, e.g. Metro (at least)
Samplerate accurate?
[bang~] with [block~ 1 1 1]... except for the global block size?
- is it possible to get sample timed events/messages, e.g. threshold what is
far to coarse! (see attached pd)
[threshold~]'s resolution seems to be timed at millisecond intervals which is 44.1 samples. Perhaps a more accurate timing would be to use [env~] inside [block~ 1 1 1] but then you would need a sample accurate timer (I am not aware of any for Pd)
- regarding changing block~ size:
- my patch only accepts 64 - why?
did you use [block~] inside a subpatch? also, the subpatch using [block~] should not have any [inlet~] or [outlet~] objects because they reblock the signal (see the helpfile for [block~]. Alternatively, try to start pd with -blocksize 1 but I have no idea whether that will actually make everything sample-accurate and suit your needs.
- why does the $0-audioscope show extreme high amplitude when block~ size is
<64 ?
- makes it sense at all changing block~ size in order to get better message
timing? Or what is it for...
As far as I understand [block~], its purpose is to compute signals irrespective of current sampling rate/block size but anything you try to output back into the main patch will be reblocked in accordance with the current block size.
Perhaps someone else will have more insight into the issues you are facing, I have rarely had a need for sample (sub sample) precise timing. ChucK's rationale is sample precision, CSound can do kr=sr (control rate = sampling rate), SuperCollider can certainly do sample-wise computations but Pd's niche is elsewhere. Someone will probably prove me wrong but maybe you are not looking at the right tool for the job...
See audio.examples/G04.control.blocksize.pd. There was also an example of reading a sample into an an array without [soundfiler], a faster than reatime playbackusing [block~] but I cannot locate it ATM.
HTH
./MiS