It could be tested to see whether its control rate message inlet will take (in msecs) small enough float values to make that happen.
here is a test patch vline-test.pd. vline~ accepts messages at any time with sub-sample accuracy. This is also documented in the help-file.
[metro 1 1 samp]
How could I have known that? The helpfile doesn't mention this. (Offtopic: actually the whole forum is full of pd-vocabular-questions)
It is documented in the metro-helpfile since pd-0.48 i guess. But i agree, there is not much redundant information in pd's helpfiles, to put it mildly
But you can „use“ the metro counts every 64 samples only, don't you?
yes, except you use it with vline~ (see test-patch)
When should I use [block~ 1 1 1] and when shouldn't I?
whenever you need delay~ times smaller than 64 samples.
on second thought, it doesn't make much sense to me.. I think you know, but, to increase the frequency resolution you just set a higher blocksize in the fft-subpatch, time resolution is your samplerate.
So, zero-padding to reduce latency? for a high-res spectrum display, or.. what do you want to do with your patch? I'm curious!
hi there, made an abstraction based on B.16.long-varispeed.pd. It should fit all your needs, variable speed and reverse playback, no artifacts with very long soundfiles as far as my humble ears can tell. and it comes with a nice little gui.. sfplayer.zip
also on github: https://github.com/solipd/AudioLab
you'll need pd-0.49 or higher to run it.
sorry i'm late to the party.. if someone is interested in a vanilla solution, try this abstraction: spat8.zip
you can adjust the speaker positions to fit your setup, in the GUI you'll have to switch to edit mode to drag them around. Two signals x and y determine the position of the sound source in a cartesian plane. This is called distance based amplitude panning (dbab), i guess..
The abstraction is part of my "AudioLab" library: https://github.com/solipd/AudioLab
edit: needs pd-0.49 or higher!
I guess I still see a downside in terms of needing to trigger the line~ envelopes using a (non-signal rate) bang, but is that not really an issue in practice?
Why? Usually you won't change any parameters while a single grain is playing. So instead of sampling a signal with [samphold~] you can just keep everything in the control domain and save some cpu.
If you want to trigger your grains with sample accuracy use [vline~] instead of [line~].
one benefit of using line~ instead of phasor~ is that it allows you to trigger the grains rhythmically or to have gaps between the grains. Also, with line~ you don't have to use a workaround like threshold~
"similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~"
not in this case. you'll get some distortion at the end of a longer table (more than 32k samples) It's documented in B15-tabread4~-onset.pd
You should not get clicks with [switch~] when you do the windowing of your grains right.
i had a quick look at your patch. I have a few suggestions:
why don't you use line~ instead of phasor~?
Using threshold~ to trigger new events will definitely cause a some problems, especially when the grains are played at a fast rate!
Use switch~ to turn dsp of when the grains are not played and save some cpu!
And use the right inlet of tabread4~ to onset into table instead of adding to the signal. (see help ->browser->Pure Data/Audio Examples/B15-tabread4~-onset)
I have a granular sampler "pp.grainer~" in my repo if you want to have a look at it. Shared the link a while ago here https://forum.pdpatchrepo.info/topic/11906/audiolab