hi!

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 common solution...

cheers Martin

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@gmx.net mailto:crinimal@gmx.net> wrote:

hi!


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
    samplerate.

    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...
http://lists.puredata.info/pipermail/pd-list/2002-04/006123.html

Martin


_______________________________________________
Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

I'd like to update biquad coefficients at the block~ size as well, to obtain smoother transitions.

On Sat, Jun 20, 2009 at 11:01 AM, hard off hard.off@gmail.com wrote:

i wanted to send a bang on a zero-crossing

hard off wrote:

i wanted to send a bang on a zero-crossing

and then using it for...?

I made a (slow) zerocross detection as part of my current work, see attachment. It gives you zero crossings as 2-element lists with a leding "indicator" (don't know how to call it correctly) and the index of a table where crossings occur.

I later noticed those nice iem-tab externals which do kind of the same job but a lot faster than "until" but i was to busy - so it's still slow. There's also some unnecessary copying inside it because I used my "standard code template for table operations"

Also using >~ and <~ and z~ for the detection might be less cpu consuming.

cheers, Martin

hard off wrote:

i wanted to send a bang on a zero-crossing

usually not such a good idea: there is a reason that Pd schedules signals and messages at different times. sending bands within the signal-block will basically break this without giving you more accuracy: signals will be calculated in blocks. if you send a bang at sample #3 of your [foo~] object's perform-routine, this will be unrelated to sample#3 of [bla~]....

there are 2 possibilities:

• use signals if you want to act at signal-rate.
• use [delay]ed bangs to keep the exact structure of the timing (though

you get an offset, introducing a delay by at least on dsp-block)

mfgadr IOhannes