instantiate an abstraction with a message?

Jan 6, 2014 at 11:26am

instantiate an abstraction with a message?

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?

#277556
Jan 6, 2014 at 12:01pm

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

#277565
Jan 6, 2014 at 12:28pm

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.

#277569
Jan 6, 2014 at 3:46pm

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

#277588
Jan 6, 2014 at 8:37pm

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

#277600
Jan 7, 2014 at 2:38am

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

#277626
Jan 7, 2014 at 4:03am

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

#277631
Jan 7, 2014 at 7:25am

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.

#277652
Jan 7, 2014 at 6:23pm

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

#277693
Jan 8, 2014 at 2:39am

-

#277707
Jan 9, 2014 at 2:53am

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.

#277797
Jan 9, 2014 at 3:50am

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.

#277801

You must be logged in to reply to this topic.