Which takes less resources (Data access)

    Ploki
    Nov 20 2012 | 10:08 pm
    What I have no matter what: - 12*12 same object-sets(displays) (12 instances of the same bpatcher enclosing 12 object-sets) - pattrstorage for all the values inside the bpatcher - separate IDs for all sub-objects (generated, not manually named) - control module to control each of 144 displays
    displays are used to show what is getting sent to the poly~ object, nothing else, no hands on control, all control is being done via the "control module"
    does it take less resources to recall and send values via receive/send and cables directly from each instance of display, or is it easier for the control module to just access everything directly in pattrstorage, and edit it there? "the values" are stored in number objects (inline before GUI objects), will editing in pattrstorage reflect it in the numberbox? and will the numberbox change the gui after it, or will I need some additional banging?
    I already have tons of messages going on so this is really just optimizing the patch for the performance purposes.
    • Ploki
      Nov 20 2012 | 11:03 pm
      I think this one is a nobrainer, regarding programming and resource. Pattrstorage all the way.
    • KrisW
      Nov 21 2012 | 11:10 am
      but what do you mean with your last sentence ? its a conclusion ? ... im asking because i would like to be sure if pattrstorage operations require less resources than object data flow/update. i had a very very similar wondering's but it was hard to test as it required more effort to "rebulid" the I/O modules/structures to see any effect.
    • Ploki
      Nov 21 2012 | 12:15 pm
      Not really a conclusion, assumption. I'm going this way because of the easy access of the client window as opposed to direct access, and all the changes in the client window *do* directly reflect in the number boxes that are scripted, and consequently, the UI objects attached to them.
      I'll build a simpler patch to test how far it comes with the resources, but I'm afraid the complications involved when doing bigger patchers (dynamic send/receive objects, message routing) just makes it unfeasible.
    • KrisW
      Nov 21 2012 | 12:39 pm
      im building a huge sampler suite that require such considerations . Im testing Javascript I/O operations for updating UI and storing/retrieving data with use of a Dict (inside JS) . im not sure about resources at the moment . untill now one thing ive noticed : that the patch takes less memory to do the tasks than patching all that logic with max objects . im still working . If you will discover any improvement ,please let me know Ploki !
    • Ploki
      Nov 21 2012 | 2:28 pm
      I never thought of JS... I'm not very good at it.
      Memory sure, how bout CPU? Especially in OD mode?
    • KrisW
      Nov 21 2012 | 2:46 pm
      i dont know about the CPU yet ,as the UI input is a one event of task ,update is another in series . I will crashtest dynamic I/O (and overdrive) after the work i have to do on my present UI logic. Anyway if you know JS basics you can really get yourself over it easily ,just check the tutorials to get comfortable. I can even provide some help if you will need
    • Ploki
      Nov 27 2012 | 12:06 am
      Okay this is incredible. Two sprintf objects, a few combine objects, it dynamically changes the route objects so you are able to build your patch and add subsets of the same objects without having to rewire anything.
      It also dynamically changes the "prepend" objects so you are able to save everything back into the client window of pattr. I am able to access all data from subpatchers within bpatchers, and also write directly back into them.
      CPU usage is negligible so far, because the object count remains constant regardless of how many objects you are willing to control this certainly is one of the nifty ways to control multiple objects with one interface.
      The only thing that's posing as a problem is that each time I recall certain subset's settings there is some overhead: because I write directly into pattrstorage client window, each time I recall a subset of settings they automatically also get written back to it. that means 2x I/O each time you load a subset. I'm currently catching these with "change" objects, at least same values don't get send twice.
      Perhaps I could just do it with a very short gate (1ms)