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:
Example B:
Thanks,
Zach
Zach,
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.
-Ben
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?
Thanks,
Zach
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?)
mz
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.
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.
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.
I just remembered the object I was thinking of originally: Peter Elsea's lnth!