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?
----------begin_max5_patcher---------- 411.3ocyUkraCBCD8L7UX4yzHrABgdqeGUQUr3RbEXmBF0zFk+8BFS1ZRpgR P8BnY7ivaYFxVSCXDeCoDBdD7LvvXqoggrUSCCUsALObSbVXoDFLpRH3LnU6 QrpbJKiHjmgTMoIRj7n2dv4Hf7Jw4HWGJhWQYouTPhEsrv0YlsE.icatM2u6 JXo5QZ+UDetlzhGFExRgfkMmtyzr4h0cQJ3dKET.ZxzRMohHE5pkfKqErp6q blfElKYE7oBZXF75pD6X2HLDVFbdxBr8sTIkIfV6E6QuyR5WRLH7L66tG3Oh dvB7+EKf7Qs15XpfrQRP364DQAGftn2f+o2L+1y58xaTaAHO4Vf2he2bFcWQ vSSyH5NX30+EcrTU96Cdch+gslON4q6Hlusev9dDuRLvLJ67+gRxhl9m5Tk7 ph3t2hZLFbfHIjRAkEJn0ey+.F7IXVQSRHxisUcxoIq404khBWI0zkQtZvHm IkQdZvH29wHji+Lu5QBa4lfGdewDP04ChpAAsis1cE+Ql5qoohlrXNPSuanL ptXm42vutsUl -----------end_max5_patcher-----------
----------begin_max5_patcher---------- 448.3oc2UkjaCBCEcMbJr7ZZE1LltqmipnJFbItBrSAiZRixcuXCjolASDkJ 0MF4ueAdC+78FSCXLeEoBBdB7BvvXioggpjrfQ2dCXQzpj7nJELXbsPvYPq1 iX0ETVNQnNC0UjlpPxie+AmC.xqEmhbYjHYAkk8ZIIQzxBb3i1V.zLW4C+f9 Uv7teR6aQrdIoEOLNhkAAykmt0zTtX8qHE7fkBJX5zRCohIk5pE+yqEbW023 LAKpPwJ3ykznb3kUoumRjHr7gmsbEaeMQRYBn0Nsdvmrh9kBi7UcOV.4yFs0 yTAYkhfvTRdzZfi8Y8F7O8lfqmyCxa5Zlca8F+a6MiuoLn9Bj8H1XfQscF1g +S5LlMhcF8yFbb+yZMD7rrbhtsFdCe7myLopbP8ZSm3+9F9c978iBhnjCP5l utiY91Jd+1+4GNhwqBCLmxN8daEKj0O1op30kI8ekt1XvdhjRpDTVjf1bS3d L3ivrfllRTGa2Uofltj2jWcT3BoltLJPCF4LoLRNH7lTRZjnIiRdZvH2I0j7 0fQASpG4pYpM.OB4F9nWiFvpQznvfc6l.tFbeb0VcohSvtMGQ0lMaM+FcNWu O. -----------end_max5_patcher-----------
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.
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?
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?)
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!
Forums > MaxMSP