[PD] is bang~ limited to a 64 sample block?
crinimal at gmx.net
Sat Jun 20 16:34:15 CEST 2009
Actually I have no precise knowledge of dsp scheduling and such things,
I only had this 64-sampes "problem" once but found other solutions to
solve it. From my (current) point of view it's not a good method to
reduce scheduling times too much on a desktop cpu, because of overhead
becoming more and more significant - but maybe I'm totally wrong here
and there are scheduling mechanisms without those side effects.
When I had this issue I had an idea to work out a "virtual" sample
accurate timing mechanism on patch level which has additional 64 samples
delay but gives you possibility to describe your problem as "sample based".
for example a threshold~ with sample accurate output can be achieved by
using tabsend~ and tab_ge from iemtab. But that was not thought very far.
maybe I'll think about it when I have more time...
btw. what for did you need these high-accuracy timings? would be
interesting to gather some of those timing problems and look for a
brandon zeeb wrote:
> Any chance of having the ability to change that globally if need be?
> On Fri, Jun 19, 2009 at 8:30 PM, Martin Schied <crinimal at gmx.net
> <mailto:crinimal at gmx.net>> wrote:
> hard off wrote:
> I made a patch which times the duration between two bangs sent
> by [bang~]. If i set the blocksize to the default of 64,
> then each bang comes 1.4ms apart - as expected with 44.1khz
> However, making the blocksize smaller has no effect on the
> duration between the bangs.
> Does bang~ have a speedlimit of 64 samples? If not, what is
> the limiting factor stopping me getting bangs more often than
> every 1.4ms?
> it's a 64 samples limit as far as i read in archives some time ago...
> Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list