call bpatcher from the patch

Feb 22, 2007 at 10:38am

call bpatcher from the patch

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

#30405
Feb 22, 2007 at 1:45pm

#97135
Feb 23, 2007 at 9:27pm

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.

#97136
Feb 24, 2007 at 12:42am

the [thispatcher] object ONLY works in inspectors!

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

-110

#97137
Feb 24, 2007 at 1:37am

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

#97138
Feb 24, 2007 at 2:45am

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

then enlighten me, i need it too.

#97139
Feb 24, 2007 at 8:36am

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

#97140
Feb 24, 2007 at 8:51am

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

#97141
Feb 24, 2007 at 8:59am

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

#97142
Feb 24, 2007 at 1:28pm

>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

#97143
Feb 24, 2007 at 1:32pm

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

#97144
Feb 24, 2007 at 2:48pm

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

#97145
Feb 24, 2007 at 3:12pm

>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

#97146
Feb 24, 2007 at 3:30pm

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

#97147
Feb 24, 2007 at 3:39pm
#97148
Feb 24, 2007 at 3:54pm

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.

#97149
Feb 24, 2007 at 4:14pm
#97150
Feb 24, 2007 at 7:43pm

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

#97151
Feb 25, 2007 at 1:42am

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.

#97152
Feb 25, 2007 at 6:25am

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

#97153
Feb 25, 2007 at 7:22am

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

#97154
Feb 25, 2007 at 8:04am

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

#97155
Feb 25, 2007 at 10:08am

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

#97156
Feb 25, 2007 at 10:11am

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;

#97157
Feb 25, 2007 at 10:31am

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

#97158
Feb 25, 2007 at 7:30pm

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

#97159
Feb 25, 2007 at 7:45pm

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

#97160
Feb 25, 2007 at 8:46pm

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

#97161
Feb 25, 2007 at 8:48pm

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

#97162
Feb 25, 2007 at 8:50pm

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

#97163
Feb 26, 2007 at 6:00am

#97164
Feb 26, 2007 at 11:36am

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

#97165
Feb 26, 2007 at 12:00pm

#97166
Feb 26, 2007 at 12:16pm

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

#97167
Feb 26, 2007 at 9:41pm

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)

#97168
Feb 26, 2007 at 9:49pm

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

#97169
Feb 26, 2007 at 9:53pm

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

#97170
Apr 2, 2007 at 3:26pm

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

#97171
Apr 2, 2007 at 9:06pm

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

#97172
Apr 2, 2007 at 11:55pm

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

#97173

You must be logged in to reply to this topic.