having lots of qmetro's all over the place vs one and lots of send/receive

    Memo Akten
    Dec 06 2015 | 9:37 pm
    I have lots of (about 10-15) different modules all over the place, and they all have qmetro 30 hz in them. The project is not sound related, it's just receiving input from multiple kinects on multiple computers, processing the data in various ways, sending to lights, drawing to screen (for debug, not performance output etc). Nothing of critical performance, or requiring minimal latency etc.
    I did it this way (lots of qmetro's, one in each module) because it was easier to develop for me and didn't require much planning (the project is evolving naturally as I work on it). But I'm wondering if this approach is dodgy. Specifically, I'm writing to jitter matrices in one module, and reading from the same matrix in another modules. And there's actually lots of matrices, with different modules reading and writing. I don't particularly care if modules read from the matrix *before* another matrix writes to the matrix, (i.e. one frame behind). But since I have lots of independent qmetro's, I'm wondering how this is all sequenced. Are qmetro's in their own thread? Could there be race conditions where one module is writing to a matrix while the other is reading?
    Would it be better to have: - one master qmetro timer which sends a bang into [t b b b b] and then into an inlet of each module. I guess this would be the cleanest, since I have full control of the order. But I don't want to send bangs into inlets because some of my modules are physically positioned quite deep and have other inlets already. I don't want to mess with the structure.
    - OR one master qmetro timer, which sends a bang on a single [send] node. And each module receives the bang. This might have the same problem as my current problem? Also still can't control the order that the modules run at (I don't really care about it too much, but if I'm changing stuff I might as well address it)
    - OR one master qmetro timer, which sends a bang into [t b b b b] and then each of those goes into a unique [send]. e.g. [s updateInput] [s updateCalibration] [s updateTracker] etc. The disadvantage of this is I need to keep track of lots of s/r variables which I'm not super keen on.
    What are people's strategies for this?
    • Floating Point
      Dec 06 2015 | 10:28 pm
      I'd do the third option-- that way you can control the order of update of matrices, and you can avoid redundant updates you may have with your current setup. You willstill have full control of the rendering order, even with send-receives, if you use the trigger object between your master metro and the sends.
    • Roman Thilenius
      Dec 07 2015 | 3:48 am
      for me it would be option 1
    • Jesse
      Dec 07 2015 | 5:06 am
      Probably #3 if you don't want to restructure the subpatches.
    • Scott Fitzgerald
      Dec 07 2015 | 6:52 am
      I'd split the difference between 1 & 3. make a [t b b b b b ....... b b] and tie off some sends. Outside each of your sub-patches, attach the appropriate receive and pass it in