bkshepard

I'm using poly~ to load a subpatch that only needs one instance. Is it possible to hide the instance number in the title bar so that when the user opens the window for the subpatch they only see the name of the subpatch "My Subpatcher" instead of "My Subpatcher (1)"? Thanks.

I'm using poly~ to load a subpatch that only needs one instance. Is it possible to hide the instance number in the title bar so that when the user opens the window for the subpatch they only see the name of the subpatch "My Subpatcher" instead of "My Subpatcher (1)"?  Thanks.


hide-poly-instance-number-in-title-bar

Why do you need to encapsulate in a poly~ just for one instance? If you need muting, there are other ways. I suppose maybe if you need to be able to release the DSP/CPU usage? Poly~'s parallelization doesn't function (far as I know) with only one instance, IIRC it spreads instances across threads evenly.

I'm more curious than anything, though, hope you don't take this as being snarky.

One option (which is how I tend to make my poly~ stuff work) is to make all controls external, and let the poly~ just handle heavy lifting DSP functions.

Why do you need to encapsulate in a poly~ just for one instance?  If you need muting, there are other ways.  I suppose maybe if you need to be able to release the DSP/CPU usage? Poly~'s parallelization doesn't function (far as I know) with only one instance, IIRC it spreads instances across threads evenly.

One option (which is how I tend to make my poly~ stuff work) is to make all controls external, and let the poly~ just handle heavy lifting DSP functions.


One great reason to use a single voice poly~ is for dynamic fx chains.

The main reason I'm doing it is so that the window will load faster when the user opens it. It was a suggestion I saw here on the forum to speed up the loading (especially the first time) of a complex window. The idea is to load it into a poly~ first. Then the window opens very quickly, even the first time it is called.

Ah right! I always forget that poly can swap out the patch it has loaded dynamically, now. I'll have to toy with that functionality one of these days...

As to the original question, then: Hide your controls in a subpatch within the poly~ object, and have users open that - not sure how your interface is designed, but subpatchers within poly~ instances do not inherit the instance number in the title. They also handle the Patcher Inspector 'title' variable correctly.

Load this in a poly and you'll see what I mean:

Ah right!  I always forget that poly can swap out the patch it has loaded dynamically, now.  I'll have to toy with that functionality one of these days...

As to the original question, then:  Hide your controls in a subpatch within the poly~ object, and have users open that - not sure how your interface is designed, but subpatchers within poly~ instances do not inherit the instance number in the title.  They also handle the Patcher Inspector 'title' variable correctly.

[loadbang] 
"patcher window name"
[thispatcher]

Hmmmmmm, perhaps my little hack above won't work, then. My main tool that I've made in Max has about 6 windows to load, and it takes a while before they become active and switch themselves to presentation mode. My current workaround is to have a picture file that says "Loading" - it only displays in patching mode, and the windows are sized to only display that object (it keeps to itself, in the upper left corner of all my subpatchers) until they've fully loaded, at which point they swap to presentation mode, and resize themselves (via thispatcher) to fit the interface.

Hmmmmmm, perhaps my little hack above won't work, then.  My main tool that I've made in Max has about 6 windows to load, and it takes a while before they become active and switch themselves to presentation mode.  My current workaround is to have a picture file  that says "Loading" - it only displays in patching mode, and the windows are sized to only display that object (it keeps to itself, in the upper left corner of all my subpatchers) until they've fully loaded, at which point they swap to presentation mode, and resize themselves (via thispatcher) to fit the interface.


Roman -- One of my quick tests a minute ago was with thispatcher loaded into a poly~ - doesn't seem to affect anything when used in a poly instance.

it should rename the window, just tried it in OS9 and 

OSX max4 and max5 - but right, the instance number of 

MuShoo wrote on Fri, 31 July 2009 03:37Roman -- One of my quick tests a minute ago was with thispatcher loaded into a poly~ - doesn't seem to affect anything when used in a poly instance.

it should rename the window, just tried it in OS9 and 
OSX max4 and max5 - but right, the instance number of 
course does not go, just the filename.

Yeah, I tried the patcher "this name" message to thispatcher and I still get the instance number. If I can't get rid of it, it's not a huge deal, but it would be nice...

bkshepard wrote on Thu, 30 July 2009 23:20

Well, you could give it a name that begins with "(1) ". It won't get rid of the instance number, but at least it will be symmetrical.

bkshepard wrote on Thu, 30 July 2009 23:20Yeah, I tried the patcher "this name" message to thispatcher and I still get the instance number. If I can't get rid of it, it's not a huge deal, but it would be nice...

Well, you could give it a name that begins with "(1) ". It won't get rid of the instance number, but at least it will be symmetrical.


in a situation where you have some modular effects in a big

program, you might want to layout them as [poly foo 32] even

though you dont plan to run more than one voice per poly~.

you could now use the "open 3" feature to get a nice window

name called "delay (3)" when this is the third instance of

a "delay" mopdule opened in your program.

in a situation where you have some modular effects in a big
program, you might want to layout them as [poly foo 32] even
though you dont plan to run more than one voice per poly~.

you could now use the "open 3" feature to get a nice window
name called "delay (3)" when this is the third instance of
a "delay" mopdule opened in your program.

Well, doggoneit, that hides the instance number alright, but unfortunately, I'm back to the original problem of a slow load time. If I just open an instance of the poly~, the window opens almost instantly, but if I open a subpatcher within the poly~ instance, it takes as long as it did to open the window when it was just a basic subpatcher. I think I'll live with the instance number. Thanks for all the tips, though!

Hide poly~ instance number in title bar