instantiate an abstraction with a message?


    Jan 06 2014 | 7:26 pm
    Is there any way to instantiate an abstraction that is in the search path by sending a message to an existing object?
    I don't want to open a window (ala the load message to pcontrol) but rather load a new abstraction into an existing container. jit.gen and jit.pix do exactly what I want using the gen message. Is there a max equivalent?

    • Jan 06 2014 | 8:01 pm
      I believe the poly~ object is exactly what you are looking for.
    • Jan 06 2014 | 8:28 pm
      Ah this is great… thank you. I didn't even think of using poly~ outside the contest of msp. One more question though.. if I add an [out] and [in] for each of the [outlet] and [inlet] objects in my abstractions, could it negatively affect performance outside the context of poly~? Also, does poly~ handle scheduling or other low level actions differently than if I instantiated the abstraction directly? I will be loading jitter and max stuff into poly~, not audio/msp.. I just want to make sure that performance will be identical... I guess that's two more questions.
    • Jan 06 2014 | 11:46 pm
      I do this all the time, loading abstractions into a bpatcher using a script message.
      Let's me have a master patcher and then individual "sub" patchers for different songs
    • Jan 07 2014 | 4:37 am
      adding [in] and [out] to abstractions doesnt do any harm to them, but i wouldnt do it.
      loading a new file into [poly~] is not better than scripting a new abstraction, except when you have a dozen of connections from and to it.
      for what it is worth, exchanging the source of a bpatcher is of course a nice alternative to scriptdeletescriptnewscriptconnectscriptmyass.
      -110
    • Jan 07 2014 | 10:38 am
      agreed, but much faster than loading bpatchers, which I find to be quite slow
      i had a patch which loaded 64 bpatchers and it took close to 15s to load it all
      scripting it takes < 1s
    • Jan 07 2014 | 12:03 pm
      Are you (both?) saying that it is significantly faster to construct a patcher from scratch into a bpatcher than to run a replace script?
      If so, I'd love to try that because I load a lot of big patchers into bpatchers when I need to switch songs.
      Also, if this approach is significantly faster, is there a tool (available to users) that can read a patcher file and produce the scripting instructions to reproduce it? I'd hate to try and recreate my larger patches manually
    • Jan 07 2014 | 3:25 pm
      i think what lee sees happens when you already have an instance of it (bpatcher with the same content) open somewhere. the second instance will then not read from disk again.
    • Jan 08 2014 | 2:23 am
      Oh. Ok. That doesn't help me....I just need to load one at a time.
    • Jan 08 2014 | 10:39 am
      -
    • Jan 09 2014 | 10:53 am
      rt, im not sure it's the reading from disk that is the factor here - i think the max runtime has to do work (obviously) to get the patch integrated... if you're loading 1 bpatcher you probably won't notice - if you load 50, there will be a considerable display.
      The bpatcher in question contained about 10 UI fields and some logic to handle them. I changed this so that i scripted the creation of the fields each time rather than loading bpatcher and the speed increase was huge.
    • Jan 09 2014 | 11:50 am
      If it's not the disk factor, then why would scripting be faster? Stuff created from explicit scripting still has to be integrated.
      I'd certainly like to try it but it would be a daunting task to create the neccessary scripts for each patcher that I would need to pull into a bpatchet.
    • Jul 29 2014 | 7:52 pm
      I would really like someone from Cycling 74 to explain why are bpatchers' loading is so slow. And maybe fix it (-: