Kasper

i would like to be able to call a bpatcher directly from the patch, 

I looked at the inspector patch, and it seemed it that there is a 

"thisobject" object communicating with the bpatcher object... ( for 

calling a patch it receives the "replace mypatchname" message)

there is no pdf reference for "thisobject" (at least i did not found 

hummm;; how could I communicate, from the patch itself with the 

bpatcher??? maybe building a "fake" bpatcher with a.... with a what 

i would like to be able to call a bpatcher directly from the patch, 
not from the inspector of the bpatcher.

I looked at the inspector patch, and it seemed it that there is a 
"thisobject" object communicating with the bpatcher object... ( for 
calling a patch it receives the "replace mypatchname" message)

there is no pdf reference for "thisobject" (at least i did not found 
it in the max docs).

hummm;; how could I communicate, from the patch itself with the 
bpatcher???  maybe building a "fake" bpatcher with a.... with a what 
- just an input, something else???

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

call-bpatcher-from-the-patch

do you need to dynamically "create" new bpatchers that reference certain patch files? if so, you need to use scripting to create the bpatcher using the filename of the subpatch you want to use inside of it.

or, are you just trying to send messages to and from an existing bpatcher file? if so, a simple send/receive pair will do the job. if you have multiple bpatchers accessing the same patch file and you need to communicate with each one independently, then you'll either have to filter the send/receive messages (i.e. assign an instance number to each bpatcher by incrementing a [value] object during patch initialization) or dynamically name the bpatchers' send/receive objects using a similar technique.

if your bpatchers are permanent and not being dynamically created, then i believe bpatchers can have inlets and outlets, just like a subpatcher object. that's another option.

do you need to dynamically "create" new bpatchers that reference certain patch files?  if so, you need to use scripting to create the bpatcher using the filename of the subpatch you want to use inside of it.

or, are you just trying to send messages to and from an existing bpatcher file?  if so, a simple send/receive pair will do the job.  if you have multiple bpatchers accessing the same patch file and you need to communicate with each one independently, then you'll either have to filter the send/receive messages (i.e. assign an instance number to each bpatcher by incrementing a [value] object during patch initialization) or dynamically name the bpatchers' send/receive objects using a similar technique.

if your bpatchers are permanent and not being dynamically created, then i believe bpatchers can have inlets and outlets, just like a subpatcher object.  that's another option.


the [thispatcher] object ONLY works in inspectors!

its a shame that we cant exchange bpatchers via messages

its a shame that we cant exchange bpatchers via messages
if you ask me. :)

On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:

> the [thispatcher] object ONLY works in inspectors!

> its a shame that we cant exchange bpatchers via messages

>
>
> the [thispatcher] object ONLY works in inspectors!
>
>
> its a shame that we cant exchange bpatchers via messages
> if you ask me. :)
>
> -110

Quote: vade wrote on Fri, 23 February 2007 18:37

----------------------------------------------------

Quote: vade wrote on Fri, 23 February 2007 18:37
----------------------------------------------------
> .. what ?
>
> you... can.......

thisobject is for inspectors. thispatcher is used for scripting. see 

the helpfile of the tutorials for scripting the creation of bpatcher 

its friday ni8ght and ive had too many beers to come up with an 

perhaops you meant to say that thisobject is useful only in inspectors?

On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:

> Quote: vade wrote on Fri, 23 February 2007 18:37

> ----------------------------------------------------

thisobject is for inspectors. thispatcher is used for scripting. see  
the helpfile of the tutorials for scripting the creation of bpatcher  
object dybamically.

its friday ni8ght and ive had too many beers to come up with an  
actual solution.

>
> Quote: vade wrote on Fri, 23 February 2007 18:37
> ----------------------------------------------------
>> .. what ?
>>
>> you... can.......
>
>
> then enlighten me, i need it too.
> --
> http://vst-mac.info/

check out page 281/tutorial 47 in max4.6 tutorials perhaps if you 

want ot dynamically make bpatchers. Its pretty straightforward.

> thisobject is for inspectors. thispatcher is used for scripting. 

> see the helpfile of the tutorials for scripting the creation of 

> its friday ni8ght and ive had too many beers to come up with an 

> perhaops you meant to say that thisobject is useful only in 

> On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:

>> Quote: vade wrote on Fri, 23 February 2007 18:37

>> ----------------------------------------------------

check out page 281/tutorial 47 in max4.6 tutorials perhaps if you  
want ot dynamically make bpatchers. Its pretty straightforward.

> thisobject is for inspectors. thispatcher is used for scripting.  
> see the helpfile of the tutorials for scripting the creation of  
> bpatcher object dybamically.
>
> its friday ni8ght and ive had too many beers to come up with an  
> actual solution.
>
>
> perhaops you meant to say that thisobject is useful only in  
> inspectors?
>
>
> On Feb 23, 2007, at 9:45 PM, Roman Thilenius wrote:
>
>>
>> Quote: vade wrote on Fri, 23 February 2007 18:37
>> ----------------------------------------------------
>>> .. what ?
>>>
>>> you... can.......
>>
>>
>> then enlighten me, i need it too.
>> --
>> http://vst-mac.info/
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>

dynamically re-assigns mybpatcher to bpatcher1 or bpatcher2 ?

or am I completely mis-interpreting this?

ok you mean this?
￼
dynamically re-assigns mybpatcher to bpatcher1 or bpatcher2 ?

>do you need to dynamically "create" new bpatchers that reference 

>certain patch files? if so, you need to use scripting to create the 

>bpatcher using the filename of the subpatch you want to use inside 

_I have a patch, with a bpatcher in it (the bpatcher object) this 

bpatcher can be empty or can be used to "host" a patch, whatever

i want to send a message to this bpatcher (object, not the patch it 

contains) so that the bpatcher calls and hosts another patch. just 

like what happens when you call the bpatcher's inspector, but without 

calling the inspector, from the patch containing the bpatcher.

>do you need to dynamically "create" new bpatchers that reference 
>certain patch files?  if so, you need to use scripting to create the 
>bpatcher using the filename of the subpatch you want to use inside 
>of it.
>

_I have a patch, with a bpatcher in it (the bpatcher object) this 
bpatcher can be empty or can be used to "host" a patch, whatever

i want to send a message to this bpatcher (object, not the patch it 
contains) so that the bpatcher calls and hosts another patch. just 
like what happens when you call the bpatcher's inspector, but without 
calling the inspector, from the patch containing the bpatcher.

if you can, could you please tell me how???

>On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:

>>the [thispatcher] object ONLY works in inspectors!

>>its a shame that we cant exchange bpatchers via messages

>.. what ?
>
>you... can.......
>
>
>
>On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:
>
>>
>>
>>the [thispatcher] object ONLY works in inspectors!
>>
>>
>>its a shame that we cant exchange bpatchers via messages
>>if you ask me. :)
>>
>

-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

> i want to send a message to this bpatcher (object, not the patch it

> contains) so that the bpatcher calls and hosts another patch. just

> like what happens when you call the bpatcher's inspector, but without

> calling the inspector, from the patch containing the bpatcher.

and excuse me if I'm a bit off-topic here, but why do you absolutely want

I surely have less experience than you all with max but I always try to

I much prefer to load-close patches when needed.

I have here an exemple with pcontrol that you surely know but it can be

>
> i want to send a message to this bpatcher (object, not the patch it
> contains) so that the bpatcher calls and hosts another patch. just
> like what happens when you call the bpatcher's inspector, but without
> calling the inspector, from the patch containing the bpatcher.
>

and excuse me if I'm a bit off-topic here, but why do you absolutely want
that to happen with a bpatcher ?
I surely have less experience than you all with max but I always try to
avoid the use of bpatcher...
I much prefer to load-close patches when needed.

I have here an exemple with pcontrol that you surely know but it can be
usefull for others :)

>i want to send a message to this bpatcher (object, not the patch it

>contains) so that the bpatcher calls and hosts another patch. just

>like what happens when you call the bpatcher's inspector, but without

>calling the inspector, from the patch containing the bpatcher.

>and excuse me if I'm a bit off-topic here, but why do you absolutely 

>I surely have less experience than you all with max but I always try 

>I much prefer to load-close patches when needed.

>I have here an exemple with pcontrol that you surely know but it can 

a few connections seem to be missing in your main patch but i see the point

_ I use Bpatchers mostly when i write for other musicians (but also 

for myself) "modules" (think of modular synth) such as a filter, an 

effect, a generator - this way all the controls (and only the 

controls) are exposed to the player, building a personal set-up is 

quick (with those premade modules) and easy; and it works.

the idea is to have the "instrument" in one patch as opposed of 

opening closing (or even navigating) between patches

_____scripting seems actually to do what i want - i am working on a 

"frame" (such as a mudilar synth "frame", with "slots") in which i 

******* by the way - I am not yet there, but does anyone tried 

scripted messages in max runtime??? does it work??? (it should.....)

>i want to send a message to this bpatcher (object, not the patch it
>contains) so that the bpatcher calls and hosts another patch. just
>like what happens when you call the bpatcher's inspector, but without
>calling the inspector, from the patch containing the bpatcher.
>
>
>and excuse me if I'm a bit off-topic here, but why do you absolutely 
>want that to happen with a bpatcher ?
>I surely have less experience than you all with max but I always try 
>to avoid the use of bpatcher...
>I much prefer to load-close patches when needed.
>
>I have here an exemple with pcontrol that you surely know but it can 
>be usefull for others :)
>

a few connections seem to be missing in your main patch  but i see the point

_ I use Bpatchers mostly when i write for other musicians (but also 
for myself) "modules" (think of modular synth) such as a filter, an 
effect, a generator - this way all the controls (and only the 
controls) are exposed to the player, building a personal set-up is 
quick (with those premade modules) and easy; and it works.

the idea is to have the "instrument" in one patch as opposed of 
opening closing (or even navigating) between patches

_____scripting seems actually to do what i want - i am working on a 
"frame" (such as a mudilar synth "frame", with "slots") in which i 
include at will the needed modules....

*******  by the way - I am not yet there, but does anyone tried 
scripted messages in max runtime??? does it work??? (it should.....)

> a few connections seem to be missing in your main patch but i see the

******* by the way - I am not yet there, but does anyone tried scripted

> messages in max runtime??? does it work??? (it should.....)

>
> a few connections seem to be missing in your main patch  but i see the
> point
>

*******  by the way - I am not yet there, but does anyone tried scripted
> messages in max runtime??? does it work??? (it should.....)
>

I also love the fact that you can make bpatcher prototypes with these

> modules and insert them into the project within seconds - I definitely

> intend to keep building my library this way.

wow, I totally overlooked the fact that a bpatcher can also be "prototyped"

I also love the fact that you can make bpatcher prototypes with these
> modules and insert them into the project within seconds - I definitely
> intend to keep building my library this way.
>

wow, I totally overlooked the fact that a bpatcher can also be "prototyped"
!
This changes my point of view !

Im still confused after reading the thread why you cant use scripting 

with thispatcher to replace bpatchers and script the connections. Did 

On Feb 24, 2007, at 8:32 AM, Kasper T Toeplitz wrote:

> if you can, could you please tell me how???

>> On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:

>>> the [thispatcher] object ONLY works in inspectors!

>>> its a shame that we cant exchange bpatchers via messages

Im still confused after reading the thread why you cant use scripting  
with thispatcher to replace bpatchers and script the connections. Did  
you see the archive I sent?

> hi vade
>
> if you can, could you please tell me how???
>
> many thanks
>
> kasper
>
>> .. what ?
>>
>> you... can.......
>>
>>
>>
>> On Feb 23, 2007, at 7:42 PM, Roman Thilenius wrote:
>>
>>>
>>>
>>> the [thispatcher] object ONLY works in inspectors!
>>>
>>>
>>> its a shame that we cant exchange bpatchers via messages
>>> if you ask me. :)
>>>
>>
>
> -- 
>  Kasper T. Toeplitz
> noise, composition, bass, computer
> http://www.sleazeArt.com
>
> http://www.myspace.com/sleazeart
>

Der Unterschied ist... they want to load/replace patches from the bpatcher

object itself (and not scripting from the parent patch), and without dealing

"i want to send a message to this bpatcher (object, not the patch it

contains) so that the bpatcher calls and hosts another patch"

Der Unterschied ist... they want to load/replace patches from the bpatcher
object itself (and not scripting from the parent patch), and without dealing
with the inspector :

"i want to send a message to this bpatcher (object, not the patch it
contains) so that the bpatcher calls and hosts another patch"

But a bpatcher HAS to be within a parent patch by definition.

On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:

> Der Unterschied ist... they want to load/replace patches from the 

> bpatcher object itself (and not scripting from the parent patch), 

> and without dealing with the inspector :

> "i want to send a message to this bpatcher (object, not the patch it

> contains) so that the bpatcher calls and hosts another patch"

> Der Unterschied ist... they want to load/replace patches from the  
> bpatcher object itself (and not scripting from the parent patch),  
> and without dealing with the inspector :
>
> "i want to send a message to this bpatcher (object, not the patch it
> contains) so that the bpatcher calls and hosts another patch"
>
> Am I (not) right ?
>
> ;)
>
> _y.

Send the thispatcher script from within the bpatcher to out outlet 

and then to a thispatcher in the parent? ... I it should be pretty 

> But a bpatcher HAS to be within a parent patch by definition.

> On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:

>> Der Unterschied ist... they want to load/replace patches from the 

>> bpatcher object itself (and not scripting from the parent patch), 

>> and without dealing with the inspector :

>> "i want to send a message to this bpatcher (object, not the patch it

>> contains) so that the bpatcher calls and hosts another patch"

Send the thispatcher script from within the bpatcher to out outlet  
and then to a thispatcher in the parent? ... I it should be pretty  
straightforward.

> But a bpatcher HAS to be within a parent patch by definition.
>
> On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:
>
>> Der Unterschied ist... they want to load/replace patches from the  
>> bpatcher object itself (and not scripting from the parent patch),  
>> and without dealing with the inspector :
>>
>> "i want to send a message to this bpatcher (object, not the patch it
>> contains) so that the bpatcher calls and hosts another patch"
>>
>> Am I (not) right ?
>>
>> ;)
>>
>> _y.
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>

gotta script this one. My attempts have developed to somewhat stability, albeit, I get crashes sometimes.

yes, in the first place i wanted to have a message which calls (from 

the outside - from the top patch) the patch to be hosted in the 

since this does not sem to work, yes, i took the script route which 

is (thanks vade) to delete the bpatcher (and its contents) and 

recreate a new bpatcher complete with its content (patcher). Not the 

this works well, and for the user it makes no difference - he still 

has a list of possible bpatcher-content patches (my-filter, 

my-generator etc) which he chooses and calls with a Umenu

i also made a "blank" (no effect) patch to be called - similar to an 

empty space in a rack. (now i have to make an "intelligent" matrix 

>Send the thispatcher script from within the bpatcher to out outlet 

>and then to a thispatcher in the parent? ... I it should be pretty 

>On Feb 25, 2007, at 1:25 AM, vade wrote:

>>But a bpatcher HAS to be within a parent patch by definition.

>>On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:

>>>Der Unterschied ist... they want to load/replace patches from the 

>>>bpatcher object itself (and not scripting from the parent patch), 

>>>and without dealing with the inspector :

>>>"i want to send a message to this bpatcher (object, not the patch it

>>>contains) so that the bpatcher calls and hosts another patch"

yes, in the first place i wanted to have a message which calls (from 
the outside - from the top patch) the patch to be hosted in the 
bpatcher-object.

since this does not sem to work, yes, i took the script route which 
is (thanks vade) to delete the bpatcher (and its contents) and 
recreate a new bpatcher complete with its content (patcher). Not the 
same but same results.

this works well, and for the user it makes no difference - he still 
has a list of possible bpatcher-content patches (my-filter, 
my-generator etc) which he chooses and calls with a Umenu

i also made a "blank" (no effect) patch to be called - similar to an 
empty space in a  rack. (now i have to make an "intelligent" matrix 
for interconnections between them all)

>Send the thispatcher script from within the bpatcher to out outlet 
>and then to a thispatcher in the parent? ... I it should be pretty 
>straightforward.
>
>Bah anyway.
>
>
>On Feb 25, 2007, at 1:25 AM, vade wrote:
>
>>But a bpatcher HAS to be within a parent patch by definition.
>>
>>On Feb 24, 2007, at 8:42 PM, e.g.r. wrote:
>>
>>>Der Unterschied ist... they want to load/replace patches from the 
>>>bpatcher object itself (and not scripting from the parent patch), 
>>>and without dealing with the inspector :
>>>
>>>"i want to send a message to this bpatcher (object, not the patch it
>>>contains) so that the bpatcher calls and hosts another patch"
>>>

> Im still confused after reading the thread why you cant use 

> scripting with thispatcher to replace bpatchers and script the 

> connections. Did you see the archive I sent?

> On Feb 24, 2007, at 8:32 AM, Kasper T Toeplitz wrote:

>> if you can, could you please tell me how???

If I have understood correctly, Kasper wants to use bpatchers boxes 

as slots into which he'd load dynamically premade dsp modules, from 

which user can only see the control interface.

You could do this by sending the "replace" message to the bpatcher 

box via scripting (using the "sendbox" keyword), followed by the name 

of the target patch (or module) and dedicated arguments.

Don't know how reliable it is (you may need to refresh the window 

display, for example), but it's an interesting way of presenting a 

I'd be interested to know if you can send embed messages as well, in 

a runtime app as well (in other words, can one embed foreign patches 

> Im still confused after reading the thread why you cant use  
> scripting with thispatcher to replace bpatchers and script the  
> connections. Did you see the archive I sent?
>
> On Feb 24, 2007, at 8:32 AM, Kasper T Toeplitz wrote:
>> hi vade
>>
>> if you can, could you please tell me how???
>

If I have understood correctly, Kasper wants to use bpatchers boxes  
as slots into which he'd load dynamically premade dsp modules, from  
which user can only see the control interface.
You could do this by sending the "replace" message to the bpatcher  
box via scripting (using the "sendbox" keyword), followed by the name  
of the target patch (or module) and dedicated arguments.
Don't know how reliable it is (you may need to refresh the window  
display, for example), but it's an interesting way of presenting a  
clean mixing interface.
I'd be interested to know if you can send embed messages as well, in  
a runtime app as well (in other words, can one embed foreign patches  
into a standalone app).

>If I have understood correctly, Kasper wants to use bpatchers boxes 

>as slots into which he'd load dynamically premade dsp modules, from 

>which user can only see the control interface.

call bpatcher from the patch