Forums > MaxMSP

call bpatcher from the patch

February 22, 2007 | 10:38 am

hi

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???

could be scripting, maybe…

any idea is welcome

many thanks

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart



jln
February 22, 2007 | 1:45 pm


February 23, 2007 | 9:27 pm

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.


February 24, 2007 | 12:42 am

the [thispatcher] object ONLY works in inspectors!

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

-110


February 24, 2007 | 1:37 am

.. 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. :)
>
> -110

v a d e //

http://www.vade.info
abstrakt.vade.info


February 24, 2007 | 2:45 am

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

then enlighten me, i need it too.


February 24, 2007 | 8:36 am

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 //

http://www.vade.info
abstrakt.vade.info


February 24, 2007 | 8:51 am

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

On Feb 24, 2007, at 3:36 AM, vade wrote:

> 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 //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info


February 24, 2007 | 8:59 am

ok you mean this?

dynamically re-assigns mybpatcher to bpatcher1 or bpatcher2 ?

or am I completely mis-interpreting this?

On Feb 24, 2007, at 3:36 AM, vade wrote:

> 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 //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info


February 24, 2007 | 1:28 pm

>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.
>

no, what i want is

_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.

thanks

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart


February 24, 2007 | 1:32 pm

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


February 24, 2007 | 2:48 pm

>
> 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 :)

save this one as jaune.pat:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 185 74 27 9109513 write;
#P newex 185 31 50 9109513 closebang;
#P newex 142 31 41 9109513 r close2;
#P message 142 74 40 9109513 dispose;
#N thispatcher;
#Q end;
#P newobj 142 104 54 9109513 thispatcher;
#P newex 51 103 29 9109513 s out;
#P flonum 51 69 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user panel -2 -5 264 139;
#X brgb 250 255 91;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 6 0 7 0;
#P connect 4 0 3 0;
#P connect 7 0 3 0;
#P connect 5 0 4 0;
#P connect 1 0 2 0;
#P window clipboard copycount 8;

save this one as vert.pat:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 185 74 27 9109513 write;
#P newex 185 31 50 9109513 closebang;
#P newex 142 31 41 9109513 r close1;
#P message 142 74 40 9109513 dispose;
#N thispatcher;
#Q end;
#P newobj 142 104 54 9109513 thispatcher;
#P newex 51 103 29 9109513 s out;
#P flonum 51 69 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P user panel -2 -5 264 139;
#X brgb 101 255 91;
#X frgb 0 0 0;
#X border 1;
#X rounded 0;
#X shadow 0;
#X done;
#P connect 6 0 7 0;
#P connect 7 0 3 0;
#P connect 4 0 3 0;
#P connect 5 0 4 0;
#P connect 1 0 2 0;
#P window clipboard copycount 8;

this is the main one:

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 448 87 43 9109513 s close1;
#P newex 383 87 43 9109513 s close2;
#P flonum 94 89 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 94 53 27 9109513 r out;
#P toggle 413 24 15 0;
#P newex 413 47 40 9109513 sel 1 0;
#P message 344 113 61 9109513 load vert.pat;
#P message 428 125 66 9109513 load jaune.pat;
#P newex 428 164 41 9109513 pcontrol;
#P connect 3 0 2 0;
#P connect 3 0 7 0;
#P connect 3 1 1 0;
#P connect 3 1 8 0;
#P connect 5 0 6 0;
#P connect 4 0 3 0;
#P connect 1 0 0 0;
#P connect 2 0 0 0;
#P window clipboard copycount 9;


February 24, 2007 | 3:12 pm

>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…..)

best

kasper


February 24, 2007 | 3:30 pm

>
> 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…..)
>

here (win xp) it does :)

cheers

_y.


February 24, 2007 | 3:39 pm

February 24, 2007 | 3:54 pm

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 !

_y.


February 24, 2007 | 4:14 pm

February 24, 2007 | 7:43 pm

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???
>
> 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
>

v a d e //

http://www.vade.info
abstrakt.vade.info


February 25, 2007 | 1:42 am

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.


February 25, 2007 | 6:25 am

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 //

http://www.vade.info
abstrakt.vade.info


February 25, 2007 | 7:22 am

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"
>>
>> Am I (not) right ?
>>
>> ;)
>>
>> _y.
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info



_j
February 25, 2007 | 8:04 am

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


February 25, 2007 | 10:08 am

hi

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)

many thanks to all

best

kasper

>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"
>>>


Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart


February 25, 2007 | 10:11 am

On Feb 24, 2007, at 8:43 PM, vade wrote:

> 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).

Example :

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 166 366 75 196617 see inspector;
#P comment 406 390 73 196617 use drop file :;
#P window linecount 2;
#P comment 598 388 90 196617 < - drag & drop patcher file here;
#P window linecount 1;
#P comment 490 336 110 196617 slot3 (scripting name);
#P newex 490 456 176 196617 prepend script sendbox slot3 replace;
#P comment 159 329 75 196617 add arguments;
#P comment 373 290 281 196617 load simple-compressor.pat from
examples folder into slot1;
#P message 124 347 182 196617 script sendbox slot1 args arg1 arg2…;
#P message 81 306 232 196617 script sendbox slot1 replace
reverb_example.pat;
#P bpatcher 374 68 420 206 0 0 0;
#P objectname slot2;
#P comment 374 52 110 196617 slot2 (scripting name);
#P bpatcher 73 68 260 205 0 0 0;
#P objectname slot1;
#P message 381 304 245 196617 script sendbox slot2 replace simple-
compressor.pat;
#N thispatcher;
#Q end;
#P newobj 177 474 61 196617 thispatcher;
#P comment 73 52 110 196617 slot1 (scripting name);
#P comment 82 290 268 196617 load reverb_example.pat from examples
folder into slot1;
#P user dropfile 490 352 590 452 1;
#P bpatcher 490 352 100 100 0 0 0;
#P objectname slot3;
#P connect 10 0 4 0;
#P connect 1 0 13 0;
#P connect 5 0 4 0;
#P connect 9 0 4 0;
#P connect 13 0 4 0;
#P window clipboard copycount 18;


February 25, 2007 | 10:31 am

>
>
>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.

exactly

>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.

how/where did you found (about) the "replace" thing???

anyhow that seems to work as well as deleting/recreating the whole
bpatcher and its contents (by scripting as well) – in both cases you
also have to recreate the connections…

>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).

exactly – this is why, i belive, you can not access the "thisobject"
object by any other way than by the inspector (which you can not
access in runtime)

thanks manuel

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

http://www.myspace.com/sleazeart


February 25, 2007 | 7:30 pm

> thisobject is for inspectors. thispatcher is used for scripting. see
> the helpfile of the tutorials for scripting the creation of bpatcher
> object dybamically.
>
> perhaops you meant to say that thisobject is useful only in inspectors?

no, i meant to say that scripting to thispatcher is not the
same as sending a message to the object.

scripting does not count.

plus it does not do what i want.


February 25, 2007 | 7:45 pm

Quote: vade wrote on Sat, 24 February 2007 23:25
—————————————————-
> But a bpatcher HAS to be within a parent patch by definition.

haha fun, now he is lost.

if you have a [cycle 0.] and you want to change it
to [cycle 5.] later in the app, do you name the object
and script-replace it?
no, you will send float "5." to its inlet.

anbd thats what we want to do with our bpatchers; change
the source file by sending it a message as if the path
would be just a regular argument.

see [fpic] … :)


February 25, 2007 | 8:46 pm

oh ffs.

you stated thispatcher doesnt work within anything other than an
inspector. Thats what I replied to. If you want added functionality
for bpatcher, fine by me – id be all for not using thispatcher hacks
(especially since the manual states that thispatcher scripting isnt
officially supported).

I gave a workable and usable solution, bite me :P *wink*

On Feb 25, 2007, at 2:45 PM, Roman Thilenius wrote:

>
> Quote: vade wrote on Sat, 24 February 2007 23:25
> —————————————————-
>> But a bpatcher HAS to be within a parent patch by definition.
>
>
> haha fun, now he is lost.
>
> if you have a [cycle 0.] and you want to change it
> to [cycle 5.] later in the app, do you name the object
> and script-replace it?
> no, you will send float "5." to its inlet.
>
> anbd thats what we want to do with our bpatchers; change
> the source file by sending it a message as if the path
> would be just a regular argument.
>
> see [fpic] … :)

v a d e //

http://www.vade.info
abstrakt.vade.info


February 25, 2007 | 8:48 pm

so … viable solutions that work, do not count, because you say so?
- gee thats pretty clever :D

hah! *sigh*

*boss : do x for me
*you I can only do x one way, BUT THAT WAY DOES NOT COUNT BECAUSE I
ARBITRARILY SAY SO, so we cant do x.
*boss : ……..

yeah :P

On Feb 25, 2007, at 2:30 PM, Roman Thilenius wrote:

>
> scripting does not count.
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info


February 25, 2007 | 8:50 pm

and btw, you can do that – you just have to roll your own. since
bpatcher is the same thing as a subpatch (just a ‘graph on parent’ in
PD parlance), you have to make your own inlets and use pcontrol or
thispatcher, the same as for subpatching.

im assuming youd want the same functionality for a regular
abstraction or subpatch then?

see where this is going?

On Feb 25, 2007, at 2:45 PM, Roman Thilenius wrote:

>
> Quote: vade wrote on Sat, 24 February 2007 23:25
> —————————————————-
>> But a bpatcher HAS to be within a parent patch by definition.
>
>
> haha fun, now he is lost.
>
> if you have a [cycle 0.] and you want to change it
> to [cycle 5.] later in the app, do you name the object
> and script-replace it?
> no, you will send float "5." to its inlet.
>
> anbd thats what we want to do with our bpatchers; change
> the source file by sending it a message as if the path
> would be just a regular argument.
>
> see [fpic] … :)

v a d e //

http://www.vade.info
abstrakt.vade.info


February 26, 2007 | 6:00 am


February 26, 2007 | 11:36 am

vade wrote:
> 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.

Tricky, the examples delete and reinstantiate the bpatcher, (could be
done also with a replace command). But, the message to reinsatiate is
sent from a bpatcher which is just deleted…

I think I tried things like that, eliminating the instatiating scripting
part from a patch, it ended up not too surprisingly with crashes.

But of course it still should be possible with some patching outside of
the bpatcher. You first have to store the scripting messages (a coll
seems appropriate) and then send a dump, maybe deferlowered to the coll
connected to thispatcher…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


February 26, 2007 | 12:00 pm


February 26, 2007 | 12:16 pm

Kasper T Toeplitz wrote:
> 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)

This sounds like Jamoma in its entire glory beauty…

Maybe you’re not the first…

http://www.jamoma.org/

Its worth to check out…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


February 26, 2007 | 9:41 pm

Quote: vade wrote on Sun, 25 February 2007 13:48
—————————————————-
> so … viable solutions that work, do not count, because you say so?
> – gee thats pretty clever :D

ja, teh 110 very clever is.

scritping interrupts DSP, requires named objects and so on …

it is bad (and does not count) like java is bad too (and does
not count too (because i say so))

i exspect the update i requested within 24 hours!

-110 (controlled autism mode)


February 26, 2007 | 9:49 pm

> bpatcher is the same thing as a subpatch (just a ‘graph on parent’ in
> PD parlance), you have to make your own inlets and use pcontrol or
> thispatcher, the same as for subpatching.

thats true – i am aware of this logical reason for why it
does not work the way i would like it to.
sending the bpatcher _object a message would not force it
to reinitialise. problem.

> im assuming youd want the same functionality for a regular
> abstraction or subpatch then?
>
> see where this is going?

yeah, exactly. otoh, kasper pointed out correctly that
you can change the path in an inspector to a bpacther object.
(… or to a patcher object hehehe … )

a solution would be a bpatcher object which allows to load
10 patches at once, and then switch between them.
(can you make me one?)


February 26, 2007 | 9:53 pm

and btw – third post – i used to script replace [patcher]
objects in some project.
it was done by putting them into poly~s for safely
performing "turn off", "replace it", "turn on again".

now, for bpatchers, we have reasons not to put them
into poly~s …

-110 :)


April 2, 2007 | 3:26 pm

Hello,

Very interesting thread !

Kasper,

Did you finally manage to get your slot system working ?

I’m also developping something with dynamic bpatcher so I can save my slots, and the settings inside my slots.
But so far, I’m facingan issue the recall using pattrstorage and autopattr (which usually works fine).

It’s recalling fine the proper bpatcher (stored from an ubmenu) in the main patch, but the settings inside the bpatchers are not (I can see them in my stored xml file though).
It seems like a timing issue for the pattrstorage system : first need to recall the bpatcher, then it’s settings. But at the time it attempt to recall the inner settings, the bpatcher is not yet finish to be loaded… I’ve tried priority and such, but no success so far.

Have you faced such issues ? Any ideas ?

Thanks,

Salvator


April 2, 2007 | 9:06 pm

Quote: vade wrote on Sun, 25 February 2007 13:50
—————————————————-
> and btw, you can do that – you just have to roll your own. since
> bpatcher is the same thing as a subpatch (just a ‘graph on parent’ in
> PD parlance), you have to make your own inlets and use pcontrol or
> thispatcher, the same as for subpatching.
>
> im assuming youd want the same functionality for a regular
> abstraction or subpatch then?
>
> see where this is going?

and HOW do we replace a patch sending stuff to thispatcher
in the patch which should be replaced??? i dont get it. :)


April 2, 2007 | 11:55 pm

put the thispatcher in the top most parent patch, send script replace
xxxx from whatever/wherever you want? , or send instantiate a
temporary patch which with sends and recieves tells a patch to close
itself, , and open up a new patch, and then close the temp patch?

….

On Apr 2, 2007, at 5:06 PM, Roman Thilenius wrote:

>
> Quote: vade wrote on Sun, 25 February 2007 13:50
> —————————————————-
>> and btw, you can do that – you just have to roll your own. since
>> bpatcher is the same thing as a subpatch (just a ‘graph on parent’ in
>> PD parlance), you have to make your own inlets and use pcontrol or
>> thispatcher, the same as for subpatching.
>>
>> im assuming youd want the same functionality for a regular
>> abstraction or subpatch then?
>>
>> see where this is going?
>
>
> and HOW do we replace a patch sending stuff to thispatcher
> in the patch which should be replaced??? i dont get it. :)
>
>
>
>
>
>

v a d e //

http://www.vade.info
abstrakt.vade.info


Viewing 40 posts - 1 through 40 (of 40 total)