metamax

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?

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?


instantiate-an-abstraction-with-a-message

I believe the poly~ object is exactly what you are looking for.

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.

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.


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

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


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.

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

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


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

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


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.

Oh. Ok. That doesn't help me....I just need to load one at a time.

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.

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.

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.


I would really like someone from Cycling 74 to explain why are bpatchers' loading is so slow. And maybe fix it (-:

instantiate an abstraction with a message?