efficiency question: qmetro and delay

Dec 31, 2009 at 10:28pm

efficiency question: qmetro and delay

This seems like a bit of a stupid question, but I’ve been unable to figure it out for long enough that it’s starting to bug me.

I have two patches, A and B. A uses two qmetros, while B uses one qmetro with two delays. The first questions is: am I correct in thinking that example B is more efficient. The second is: why doesn’t example B behave the same as example A?

Example A:

– Pasted Max Patch, click to expand. –

Example B:

– Pasted Max Patch, click to expand. –


Dec 31, 2009 at 11:27pm


I’m not sure what exactly you are trying to do here, but example b works as expected. You will not get a bang output from delay if you are sending it delays quicker then it is delaying them, that is until you stop sending it bangs. Maybe you want to use pipe?

As far as the efficiency issue, it depends on what exactly you are up to.


Jan 1, 2010 at 6:47pm

I heard that it’s usually better to run everything off of one metro, so the two process aren’t competing for priority. I’m not sure how much this holds true in all cases.

However, it seems neither delay nor pipe are the way to do this, since I need to filter out bangs rather than delaying them. What I didn’t get at first is that by sending bangs to delay faster than its delaying them, I’m essentially putting the bangs in a traffic jam where none can get through until I turn the metro off.

I think what I need is an object that takes an integer argument x and passes on one bang for every x it receives. I’m pretty sure this would be more efficient than using two metros. Any ideas?


Jan 1, 2010 at 7:10pm

speedlim. or onebang.

One metro is good for the soul. However, qmetro is about creating low priority events. If you put that into delay, or speedlim, they are elevated to a higher priority. Are you having efficiency issues? Managing threads is a tricky business that is fairly contextual. (Using jitter? timing accuracy important? Using controllers?)


Jan 1, 2010 at 7:40pm

Thanks, mzed. It seems using speedlim and jit.qball does the trick. I need these to be low priority since I’m using them to bang frames from two movies into one jitter matrix at varying rates.

I’m actually not having efficiency issues (yet). More like a New Years resolution to write cleaner code.

Jan 4, 2010 at 11:56am

also, the “every nth bang” can be solved easily with counter –> % 4 –> sel 0. this bangs every 4th count of the counter (every number coming out that is divisible by 4). the modulo is very handy in other spots as well.

Jan 5, 2010 at 12:07am

Didn’t even think of doing it that way. Very elegant.

Any idea of efficiency vs. using speedlim? It seems like this way would be more efficient.

The reason I’m such a stickler for efficiency here is that my patch basically performs frame by frame video mixing at different ratios faster than 30 fps to create flickery effects. I have to keep the jit.window pretty small to get it to run that fast, but I’m more concerned that all the bangs are getting through. Dropped frames are okay as long as the overall ratio of video to video is preserved.

This is just a first foray for me into applying granular synthesis techniques to video. I think there are a lot of possibilities out there that will become evident once high fps cameras are more widely available.

Jan 6, 2010 at 1:23am

I just remembered the object I was thinking of originally: Peter Elsea’s lnth!


You must be logged in to reply to this topic.