Charly Beck

my third question here and maybe someone can answer in contrast ;)

I saw a post where somebody talked about creating and deleting bpatchers automatically. I wonder how this works and wether this works for any type of object.

Can somebody tell me the class name used to create objects dynamicaly?

i'm working with vst~ object and it seems there is no way to unload a plugin but i wouldn't need this if i can create a vst~ object dynamically.... maybe even as much vst~ objects as i give as a parameter? that would be really great.

Hi,
my third question here and maybe someone can answer in contrast ;)
I saw a post where somebody talked about creating and deleting bpatch

dynamically-creating-an-deleting-max-objects

You can also use Javascript if you're familiar with it.

Have a look at thispatcher's help file.
You can also use Javascript if you're familiar with it.

since max version 4.5 it works with any object ("script newdefault"), before it only worked with GUI objects.

[list script new SCRIPTINGNAME bpatcher 40 40 100 100 0 0 FILENAME 0]


since max version 4.5 it works with any object ("script newdefault"), before it only worked with GUI objects.

[list script new SCRIPTINGNAME bpatcher 40 40 100 100 0 0 FILENAME 0]


Ok... i need to check this. but good to know it's possible.

coming back to this one i had a look at the newdefault sample script in the thispatcher help....

But i would also need to create patch chords and connect the objects i create dynamcially.... Is this possible too with java? It would be like a codegenerator for max devices...

I guess it is not possible - so it seems it isn't with the max sdk neither. Hum...

But i would also need to create patch chords and connect the objects i create dynamcially.... Is this possible too with java? It would be like a codegenerator for max devices...

I guess it is not possible - so it seems it isn't with the max sdk neither.  Hum... 

no idea if it is documented anywhere, but you can also make connections with thispatcher scripting (or is javascript obligatory for your patch?)

to make it work, the non-dynamic objects where you want to connect from and to also need scripting names.

[list script connect OBJECT_1NAME 0 BPATCHERNAME 0]

[list script connect BPATCHERNAME 0 OBJECT_2NAME 0]

[list script connectcolor BPATCHERNAME 0 OBJECT_3NAME 0 13]

using "disconnect" should not be required when you delete an object.


no idea if it is documented anywhere, but you can also make connections with thispatcher scripting (or is javascript obligatory for your patch?)

to make it work, the non-dynamic objects where you want to connect from and to also need scripting names.

[list script connect OBJECT_1NAME 0 BPATCHERNAME 0]
[list script connect  BPATCHERNAME 0 OBJECT_2NAME 0]
[list script connectcolor BPATCHERNAME 0 OBJECT_3NAME 0 13]

using "disconnect" should not be required when you delete an object.


Is this also possible from the c sdk? Or do i have to write it in javascript and then somehow pass parameters to the javascript from the max external`?

i have no clue what the sdk or javascript would have to do with that.

using thispatcher is just like talking to the max runtime, which does the rest. :)

it can, first of all, help to automate building patches, but it even works in standalones when you really need it.

#P newex 477 202 209 9109513 if $i1==1 then connect else disconnect;

#P newex 381 236 491 9109513 pak script xxx OBJECT_1NAME 0 OBJECT_2NAME 0;

#P newex 218 489 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_3NAME 0;

#P comment 215 213 100 9109513 OBJECT_3NAME;

#P comment 68 213 100 9109513 OBJECT_2NAME;

#P newex 217 444 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_3NAME 0 10;

#P newex 218 399 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_2NAME 0;

#P newex 218 353 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_2NAME 0;

#P number 235 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

#P number 100 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

#P number 172 100 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

#P newobj 218 541 88 9109513 thispatcher;

#P comment 148 69 100 9109513 OBJECT_1NAME;

#P window clipboard copycount 18;#P toggle 477 136 36 0;


i have no clue what the sdk or javascript would have to do with that.

using thispatcher is just like talking to the max runtime, which does the rest. :)

it can, first of all, help to automate building patches, but it even works in standalones when you really need it.

#P toggle 477 136 36 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 477 202 209 9109513 if $i1==1 then connect else disconnect;
#P newex 381 236 491 9109513 pak script xxx OBJECT_1NAME 0 OBJECT_2NAME 0;
#P button 136 453 35 0;
#P newex 218 489 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_3NAME 0;
#P comment 215 213 100 9109513 OBJECT_3NAME;
#P comment 68 213 100 9109513 OBJECT_2NAME;
#P button 136 408 35 0;
#P button 136 363 35 0;
#P button 136 317 35 0;
#P newex 217 444 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_3NAME 0 10;
#P newex 218 399 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_2NAME 0;
#P newex 218 353 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_2NAME 0;
#P number 235 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_3NAME;
#P number 100 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_2NAME;
#P number 172 100 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_1NAME;
#N thispatcher;
#Q end;
#P newobj 218 541 88 9109513 thispatcher;
#P comment 148 69 100 9109513 OBJECT_1NAME;
#P connect 10 0 7 0;
#P connect 8 0 5 0;
#P connect 9 0 6 0;
#P connect 14 0 13 0;
#P connect 15 0 1 0;
#P connect 7 0 1 0;
#P connect 13 0 1 0;
#P connect 6 0 1 0;
#P connect 5 0 1 0;
#P connect 17 0 16 0;
#P connect 16 0 15 1;
#P window clipboard copycount 18;#P toggle 477 136 36 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 477 202 209 9109513 if $i1==1 then connect else disconnect;
#P newex 381 236 491 9109513 pak script xxx OBJECT_1NAME 0 OBJECT_2NAME 0;
#P button 136 453 35 0;
#P newex 218 489 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_3NAME 0;
#P comment 215 213 100 9109513 OBJECT_3NAME;
#P comment 68 213 100 9109513 OBJECT_2NAME;
#P button 136 408 35 0;
#P button 136 363 35 0;
#P button 136 317 35 0;
#P newex 217 444 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_3NAME 0 10;
#P newex 218 399 491 9109513 list script disconnect OBJECT_1NAME 0 OBJECT_2NAME 0;
#P newex 218 353 491 9109513 list script connect OBJECT_1NAME 0 OBJECT_2NAME 0;
#P number 235 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_3NAME;
#P number 100 185 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_2NAME;
#P number 172 100 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname OBJECT_1NAME;
#N thispatcher;
#Q end;
#P newobj 218 541 88 9109513 thispatcher;
#P comment 148 69 100 9109513 OBJECT_1NAME;
#P connect 10 0 7 0;
#P connect 8 0 5 0;
#P connect 9 0 6 0;
#P connect 14 0 13 0;
#P connect 15 0 1 0;
#P connect 7 0 1 0;
#P connect 13 0 1 0;
#P connect 6 0 1 0;
#P connect 5 0 1 0;
#P connect 17 0 16 0;
#P connect 16 0 15 1;
#P window clipboard copycount 18;


btw, doing that for vst~ might lead to trails in RAM or even crash your patch if you have bad luck. best practice is to turn the plug-in off ("enable 0") before deleting the object.

but it can still be very clever, because this way you could for example also change the number of input and outputs and things like that, which are never possible by sending messages to objects but 


btw, doing that for vst~ might lead to trails in RAM or even crash your patch if you have bad luck. best practice is to turn the plug-in off ("enable 0") before deleting the object.

but it can still be very clever, because this way you could for example also change the number of input and outputs and things like that, which are never possible by sending messages to objects but only by recreating them using scripting.


well, i want to create the objects dynamically using javascript or better c code to control the creation of the objects. something like javascript:

// pseudo code: Add 10 matrix~ objects and connect them.

m = thispatcher.addObject("jit.matrix~");

what kind if syntax is this above? seems to be not a patcher nor java script (?) where to paste it?

yes. i also managed the vst~ object is unstable, especially unloading often crashes. i will try to "enable 0". with trails you mean memory leaks?

ps: here is a brief description of what i' doing:

http://karlchenscoderdasein.blogspot.com/2020/05/a-dynamic-signal-flow-graph.html

// pseudo code: Add 10 matrix~ objects and connect them.
function createPatch(x) {
  for (i=0 ; i <10; ++i) {
     m = thispatcher.addObject("jit.matrix~");
     m.inlets[0].connect(x);
  }
}

what kind if syntax is this above? seems to be not a patcher nor java script (?)  where to paste it?

yes. i also managed the vst~ object is unstable, especially unloading often crashes. i will try to "enable 0".  with trails you mean memory leaks?

ps: here is a brief description of what i' doing:
http://karlchenscoderdasein.blogspot.com/2020/05/a-dynamic-signal-flow-graph.html

ok i made some tests... that looks good. just one more question: Is there somewhere a complete reference of all javascript functions and objects? I mean the method "defaultnew" is not defined in "thispatcher" object. How can i know this function exists?

thanks a lot for your help, @roman thilenius,

if you are good in javascript it will probably be more flexible for mass production compared thispatcher. otoh it will perform about 50 times slower.

there is a vignette which mentions both. the thispatcher section only goes to the reference.

https://docs.cycling74.com/max8/vignettes/scripting_topic

https://docs.cycling74.com/max8/refpages/thispatcher

it is more or less limited to create/delete, show/hide, mouse/nomouse, move/offset, connect/disonnect and sending messages to objects.


if you are good in javascript it will probably be more flexible for mass production compared thispatcher. otoh it will perform about 50 times slower.

there is a vignette which mentions both. the thispatcher section only goes to the reference.
 
https://docs.cycling74.com/max8/vignettes/scripting_topic

https://docs.cycling74.com/max8/refpages/thispatcher

it is more or less limited to create/delete, show/hide, mouse/nomouse, move/offset, connect/disonnect and sending messages to objects.


in the big list you gave above you have defined class names and the parameters belonging to the creation args.

Question1: From where did you get the info that for example param #6 for comment is the object name?

 #P number 172 100 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

Question2: Why does the number class not provide an object name? Is it not possible to set the object name for number?! (!!)

Question3 objectname is the scripting name, right?

and yes, it will be a mass production. because i wanna reflect all objects together with their creation arguments in c# types. but for this i would need the meta data about which class provides which parameters in which order. and - important - the data type of the parameter. otherwise it'll be not so compfortable as i want it to be.

the best way would be if the cycling guys would make the object registry api public but they didn't.... will be hard to achieve...

 #P comment 215 213 100 9109513 OBJECT_3NAME; 

Question1: From where did you get the info that for example param #6 for comment is the object name?

regarding 
 #P number 172 100 44 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0; 

I posted somethin like this in April on a related topic, maybe you find it useful.

thx that helped.... i didn't put the "script" prefix before the message.

when i need to know how to re-create something, i usually export a max patch as text from max version 4.x - because the old max text format is what thispatcher-scripting is based on.

but it is easy, it follows a simple scheme.

script new SCRIPTINGNAME bpatcher 40 40 100 100 0 0 FILENAME 0 

scripting name, name of the object, left top bottom right, and in this case two flags (0 or 1, i think for "border" and visibility), and them further info the bpatcher object requires: name of the patcher to load (not sure about the 0 now.) after that and optional are the up to 9 arguments to the object in question.

however, the code in Q1 is not what you think, and in Q2, well that [number] has no scripting name simply because it is not a scripted object.

i thought by now you figured that you have to copy and paste that code into a patcher window!

yes, that is a formal variable i was using to make the text readable. 

you can use what you want, but it must be a unique name. if you always use the same, you can continue creating stuff, but you can no longer delete or disconnect, because the name of the last obejct will go boom if you use it for another object.

there is a compromise, and that is the automatic scriptingname-numbering shown in the [thispatcher] 

 website. (but i dont like it. it is better to do that on your own.)


Q1: 

right, that is the one thing which is not full documented anywhere.

when i need to know how to re-create something, i usually export a max patch as text from max version 4.x - because the old max text format is what thispatcher-scripting is based on.

but it is easy, it follows a simple scheme.

see my first post: 

script new SCRIPTINGNAME bpatcher 40 40 100 100 0 0 FILENAME 0 

scripting name, name of  the object, left top bottom right, and in this case two flags (0 or 1, i think for "border" and visibility), and them further info the bpatcher object requires: name of the patcher to load (not sure about the 0 now.) after that and optional are the up to 9 arguments to the object in question.

for most objects it is just scripting name, objectname, position.

Q2:

however, the code in Q1 is not what you think, and in Q2, well that  [number] has no scripting name simply because it is not a scripted object.

i thought by now you figured that you have to copy and paste that code into a patcher window! :P

then you will understand.

Q3:

yes, that is a formal variable i was using to make the text readable. 

you can use what you want, but it must be a unique name. if you always use the same, you can continue creating stuff, but you can no longer delete or disconnect, because the name of the last obejct will go boom if you use it for another object.

there is a compromise, and that is the automatic scriptingname-numbering shown in the [thispatcher] reference website. (but i dont like it. it is better to do that on your own.)


Question: is it also possible to delete a object?

ok i found the chapter "Scripting the patcher" in the max api documentation. i gonna use this... :)

I am hoping to clarify a few misconceptions:

2) You can dynamically create/destroy any object in Max both from scripting and from C code.

3) You can programmatically connect any two objects in a patch both from scripting and C code. It is also possible to target specific inlets/outlets.

Patching is never gonna be stable/flexible/efficient enough for your project.

I am hoping to clarify a few misconceptions:
1) The object registry API is public.
2) You can dynamically create/destroy any object in Max both from scripting and from C code.
3) You can programmatically connect any two objects in a patch both from scripting and C code. It is also possible to target specific inlets/outlets.
4) You should really be coding in C/C++.
Patching is never gonna be stable/flexible/efficient enough for your project.

Yeah, what Luigi said! I wish I had gotten on to the C coding earlier, it makes Max make so much more sense.

Charly, this may or may not be useful to you, but if you're looking for ways to build parts of the app in something more high level than C, you could always do what I'm doing in my Scheme For Max project and embed the S7 scheme interpreter in a C external to allow a mix of dynamic high level programming and low level C. It works really well, and the foreign function interface for S7 is dead easy, so making C functions that you can call from Scheme, and calling Scheme from C are both simple. S7 is similar to Guile, but has a more permissive license and is designed around the needs of computer music. Common Music is built with S7 embedded in a Juce C++ app for example, as is the Snd sound editor. And both S7 and Scheme for Max are open source and BSD licensed, so you can use anything in there that is helpful to you.

S7's page is here: https://ccrma.stanford.edu/software/snd/snd/s7.html

Scheme for Max is here: https://github.com/iainctduncan/scheme-for-max

Charly, this may or may not be useful to you, but if you're looking for ways to build parts of the app in something more high level than C, you could always do what I'm doing in my Scheme For Max project and embed the S7 scheme interpreter in a C external to allow a mix of dynamic high level programming and low level C.  It works really well, and the foreign function interface for S7 is dead easy, so making C functions that you can call from Scheme, and calling Scheme from C are both simple. S7 is similar to Guile, but has a more permissive license and is designed around the needs of computer music. Common Music is built with S7 embedded in a Juce C++ app for example, as is the Snd sound editor.  And both S7 and Scheme for Max are open source and BSD licensed, so you can use anything in there that is helpful to you. 

S7's page is here: https://ccrma.stanford.edu/software/snd/snd/s7.html
Scheme for Max is here: https://github.com/iainctduncan/scheme-for-max

"4) You should really be coding in C/C++. Patching is never gonna be stable/flexible/efficient enough for your project."

wouldnt you end up recreating [thispatcher] when you create and delete objects from a C++ external - and how is that the 


"4) You should really be coding in C/C++. Patching is never gonna be stable/flexible/efficient enough for your project."

wouldnt you end up recreating [thispatcher] when you create and delete objects from a C++ external - and how is that the opposite of "scripting"?


Well, I think Luigi has a good point that managing thispatcher stuff is a lot nicer in code (at least to my tastes!) Given what I think I've read of Charly's project, he's already doing C, so I would agree that that is going to be nicer to handle in an external. But YMMV as they say!

Well, I think Luigi has a good point that managing thispatcher stuff is a lot nicer in code (at least to my tastes!)  Given what I think I've read of Charly's project, he's already doing C, so I would agree that that is going to be nicer to handle in an external.  But YMMV as they say!

There are good examples of thispatcher scripting in the SDK example code too.

if I never had Max 4.x... is there any way to retrieve this?

I was asking myself the same thing. I must have not quite understood what Luigi meant with:

Speaking of efficiency, Roman at some point said:

Why exactly is that, and how does the other C and C++ approaches then compare to thispatcher?

wouldnt you end up recreating [thispatcher] when you create and delete objects from a C++ external - and how is that the opposite of "scripting"?

4) You should really be coding in C/C++.
Patching is never gonna be stable/flexible/efficient enough for your project.

Why exactly is that, and how does the other C and C++ approaches then compare to thispatcher?

Thank you for this thread.

eventually you can also make it up from looking at the json. 

old type text is only better because you can (almost) copy and paste. ;)

scripting an objectbox does not differ sooo much from the gui object example in the thispatcher helpfile. 

i´ve never tried this, but even "thing @attributes" or "poly~ foo up args 1 2 3" should be just typed in after the object name. 

arguments to bpatcher (see above) is a special case.

1. 
eventually you can also make it up from looking at the json. 
old type text is only better because you can (almost) copy and paste. ;)
scripting an objectbox does not differ sooo much from the gui object example in the thispatcher helpfile. 
i´ve never tried this, but even "thing @attributes" or "poly~ foo up args 1 2 3" should be just typed in after the object name. 
arguments to bpatcher (see above) is a special case.

number and flonum are a bit weird. but in many cases the order of all these wonderful encoded numbers is represented in the objects inspector (top to bottom)

#P flonum 40 94 35 9 0 0 0 139 0 0 0 255 227 23 222 222 222 0 0 0;

#P flonum 40 55 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;

grafik.png


number and flonum are a bit weird. but in many cases the order of all these wonderful encoded numbers is represented in the objects inspector (top to bottom)

#P toggle 40 237 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P newex 40 174 569 9109513 cycle 50;
#P newex 40 135 50 9109513 cycle;
#P flonum 40 94 35 9 0 0 0 139 0 0 0 255 227 23 222 222 222 0 0 0;
#P objectname flonum-name;
#P flonum 40 55 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P window clipboard copycount 5;

well, okay, actually everything is a bit weird. for externals there are also data contained in the patcher file which are not required/possible to contain in the script, because the runtime handles that stuff exclusively.

but in theory you can make yourself an automatic script generator which creates the script you need to recreate an existing object.

in max 4 you would have to select the object in question 

 in order to be be able to copy and paste a "partial" patcher file containing the object.

then you have its name and its current position in the window (and possibly arguments, colors and so on.)

in max 7 there are far more things an object can have (styles), so it will require a bit another approach. however, "max 4 scripting" will of course also work in v7/v8. 


well, okay, actually everything is a bit weird. for externals there are also data contained in the patcher file which are not required/possible to contain in the script, because the runtime handles that stuff exclusively.

but in theory you can make yourself an automatic script generator which creates the script you need to recreate an existing object.

in max 4 you would have to select the object in question and one more object in order to be be able to copy and paste a "partial" patcher file containing the object.

then you have its name and its current position in the window (and possibly arguments, colors and so on.)

in max 7 there are far more things an object can have (styles), so it will require a bit another approach. however, "max 4 scripting" will of course also work in v7/v8. 
only the position is mandatory. :)



"script newdefault NAME 200 100 50 cycle 5"

#P hidden newex 200 100 50 9109513 cycle 5;

"script newdefault NAME 200 100 50 cycle 5, script hide NAME, script ignoreclick NAME"

"script hidden newdefault NAME 200 100 50 cycle 5, script ignoreclick NAME"

not sure about color, it was different in max 4 and stopped working.

#P newex 200 100 50 9109513 cycle 5;

"script newdefault NAME 200 100 50 cycle 5"


#P hidden newex 200 100 50 9109513 cycle 5;
#P noclick;

"script newdefault NAME 200 100 50 cycle 5, script hide NAME,  script ignoreclick NAME"
 or
"script hidden newdefault NAME 200 100 50 cycle 5,  script ignoreclick NAME"

not sure about color, it was different in max 4 and stopped working.


two points: Luigi, thanks for your clariiciation i see that all now. Just one note about the objectregistry: when i said object registry i actually meant the class registry. This means i would need to request the meta info about which classes exist and with which attributes and methods the classes have. This info i would need because i thought of writting a code generator which creates wrappers for all the objects. Is this info also accessable?

This brings me to my second point about the high level language iain was talking about: I created a c# wrapper for max this means, most of my code is written in c# using a slim adapter layer written in c. That is very compfortable to code and the .net api is quite big too.

i'm currently about to extend the wrapper for the "object scripting api" creating and connecting an object works like:

var aMainIn = this.ParentPatcher.GetObject("MainIn");

var aMcAddSig = this.ParentPather.AddObject("mc.+~", "obj1");

aMainIn.Outlets[0].ConnectTo(aMcAddSig.Inlets[0]);

Like this i can delete the old objects and create new when the graph definition of my tool changes.

Currently there is only a "Patcher" class and a "PatcherObject" class but i would like to generate also a class for mc.+~ and all the others having a specific number of attributes like color etc. So that it's not necessarry to do it like

aObj.SetAttribute("bgcolor", new double[]{1,0,0,1});

with a code generator it could look like:

var aMainIn = this.ParentPatcher.GetObject("MainIn");
var aMcAddSig = this.ParentPather.AddObject("mc.+~", "obj1");
aMainIn.Outlets[0].ConnectTo(aMcAddSig.Inlets[0]);
//...
aMcAddSig.Delete();

Like this i can delete the old objects and create new when the graph definition of my tool changes. 

with a code generator it could look like:

aObj.Bgcolor = Color.FromArgb(1, 1,0,0);

First of all, let me say how much I am enjoying this thread and exchanging ideas with all of you. Lots of experienced and knowledgeable people here. Thanks for your contribution.

yes, this information is accessible. Both object registry and class registry are entirely accessible.

However there are some more considerations you need to think about.

For example you need to choose whether you want to know which classes exist relative to the patcher or to the whole Max environment...

...or if you are interested in classes that are used internally by Max or only in those classes that can be instantiated in a patcher (what we refer to 

In any case functions that may be useful for what you are trying to achieve are:

For methods is a little more involved, but when you get there, feel free to email me off-list (luigi.p.castelli [at] gmail [dot] com) and I will be happy to share some code with you.

two points: Luigi, thanks for your clarificiation i see that all now. Just one note about the objectregistry: when i said object registry i actually meant the class registry. This means i would need to request the meta info about which classes exist and with which attributes and methods the classes have. This info i would need because i thought of writting a code generator which creates wrappers for all the objects. Is this info also accessable?

yes, this information is accessible. Both object registry and class registry are entirely accessible.
However there are some more considerations you need to think about.
For example you need to choose whether you want to know which classes exist relative to the patcher or to the whole Max environment...
...or if you are interested in classes that are used internally by Max or only in those classes that can be instantiated in a patcher (what we refer to Max externals), and more...

In any case functions that may be useful for what you are trying to achieve are:
class_namespace_getclassnames()
object_register_getnames()
object_attr_getnames()

For methods is a little more involved, but when you get there, feel free to email me off-list (luigi.p.castelli [at] gmail [dot] com) and I will be happy to share some code with you. 

No, when you create/delete objects in the patcher the environment is already set up for you. There is so much more going on under the hood than just calling a destructor. In the patcher lots of choices have been already made. For example you can witness some of this when you open a patcher as text and see attributes such as "id", "maxclass", "outlettype", etc... You are in a graphical environment where you can create and delete objects in any order at any time. Objects might be communicating with each other and if you decide to suddenly delete an object in the chain, the whole ecosystem keeps working. The overall threading model has already been established for you. This is just to say that the patcher is a pretty high level environment already and if you decide to work in the patcher you are bound to follow certain rules that you can just ignore if you were coding in C/C++.

When you are coding in C/C++ pretty much everything is open. This makes it a lot more complex, because almost everything needs to be managed, however in exchange it gives the user more freedom to make it optimal for the kind of goal he/she wants to achieve.

I don't think patching can be defined as the "opposite" of scripting.

Probably under the hood patching and scripting use the same code.

"4) You should really be coding in C/C++. Patching is never gonna be stable/flexible/efficient enough for your project."  
wouldnt you end up recreating [thispatcher] when you create and delete objects from a C++ external

and how is that the opposite of "scripting"?

I don't think patching can be defined as the "opposite" of scripting.
Probably under the hood patching and scripting use the same code.

i think you can understand "patching" as using the max gui and connecting manually by hand.

"scripting" can be understood as using a script language to automatically create and connect max object.

commonly the difference between a script language and a compiler langauge is that script languages are linked at runtime where in compiled languages at least a portion of the symbols is linked at compile-time. (c# can do both using the "dynamic" keyword to enable the runtime-linking.)

a script language but in the documentation there is a chapter "scripting the patcher" which actually means "using the c api to manipulate patcher content". also java script can be used to do this.

i guess this is enough term-chaos to produce some misunderstandings when talking about scripting. ;-)

@luigi: it is great that the class registry is public accessable. i will check this at some point. when i will generate wrappers i will generate for all classes. the generated classes will be included to my "ClrAdapter.dll" which has no dependency to the specific ClrMaxExternal. It can be done to generate the code on demanand and using dynamic-keywoard but this is not my intention: I wanna have all the attributes and messages compiled into a class so that the user can take advantage of intellisense and the stuff is compile-time linked.

I just finished creating the hardwired graph. I just need to change the channels-patcher to use this generated patcher then i will see how much performance it still takes (we had another discussion about optimizing in this thread:)

https://cycling74.com/forums/max-device-terribly-slow-inside-live/replies/1#reply-5ec99da667eff66332eee053

i think you can understand "patching" as using the max gui and connecting manually by hand.
"scripting" can be understood as using a script language to automatically create and connect max object.

commonly the difference between a script language and a compiler langauge is that script languages are linked at runtime where in compiled languages at least a portion of the symbols is linked at compile-time. (c# can do both using the "dynamic" keyword to enable the runtime-linking.) 

var obj = new MyClass();
obj.mymethd(); // compiletime linked
dynamic dyn = obj;
dyn.mymethod(); // runtime linked

 so c is not a script language but in the documentation there is a chapter "scripting the patcher" which actually means "using the c api to manipulate patcher content". also java script can be used to do this.

I just finished creating the hardwired graph. I just need to change the channels-patcher to use this generated patcher then i will see how much performance it still takes (we had another discussion about optimizing in this thread:)
https://cycling74.com/forums/max-device-terribly-slow-inside-live/replies/1#reply-5ec99da667eff66332eee053

so this is the method to generate the hardwired routing: (just in case someone's interested in reading some code)

private void UpdateMixerMatrixPatcher()
{
  var aParentPatcher = this.ParentPatcher;
  var aMixerMatrixPatcher = aParentPatcher
    .GetSubPatcher("MixerMatrixPatcher");
  var aObjPrefix = "MixerMatrixObj";
  var aGetDynObjName = new Func<string, int, string>
    (delegate (string aPrefix, int aNamedObjIdx)
  {
    return aPrefix + "[" + aNamedObjIdx + "]";
  });
  var aGetStaticObjName = new Func<string, int, string>
    (delegate (string aPrefix, int aNamedObjIdx)
  {
    return aGetDynObjName(aPrefix, aNamedObjIdx);
  });
  { // DeleteOldObjects
    var aDone = false;
    for (var aObjIdx = 0; !aDone;++aObjIdx)
    {
        var aName = aGetDynObjName(aObjPrefix, aObjIdx);
        if (aMixerMatrixPatcher.GetContainsObject(aName))
        {
          var aObj = aMixerMatrixPatcher.GetBox(aName);
          aObj.Delete();
        }
        else
        {
          aDone = true;
        }
    }
  }

  { // AddNewObjects
    var aObjIdx = 0;
    var aGenObjectName = new Func<string>(() =>
    {
        var aName = aGetDynObjName(aObjPrefix, aObjIdx);
        ++aObjIdx;
        return aName;
    });
    var aCsState = this.CsState;
    var aFlowMatrix = aCsState.FlowMatrix;
    var aChannels = aFlowMatrix.Channels;
    var aIoCount = this.IoCount;
    var aMainIn = aMixerMatrixPatcher.GetBox("MainIn");
    var aMainOut = aMixerMatrixPatcher.GetBox("MainOut");
    var aOutputs = new CPatBox[aIoCount];
    for(var aOuputIdx = 0; aOuputIdx < aIoCount; ++aOuputIdx)
    {
        var aVstOutName = aGetStaticObjName("VstOut", aOuputIdx);
        var aVstOutObj = aMixerMatrixPatcher.GetBox(aVstOutName);
        aOutputs[aOuputIdx] = aVstOutObj;
    }
    var aInputs = new CPatBox[aIoCount];
    for (var aInputIdx = 0; aInputIdx < aIoCount; ++aInputIdx)
    {
        var aVstInName = aGetStaticObjName("VstIn", aInputIdx);
        var aVstInObj = aMixerMatrixPatcher.GetBox(aVstInName);
        aInputs[aInputIdx] = aVstInObj;
    }
    var aAddDelay = new Func<int, int, CPatBox>(delegate
      (int aDelayChannelIdx, int aDelayTime)
    {
        var aInput = aInputs[aDelayChannelIdx]; 
        var aSkipDelayIsAllowed = false; // can not delete cable 0->0 atm...
        if (aDelayTime == 0
        && aSkipDelayIsAllowed)
        {                  
          return aInput;
        }
        else
        {
          var aArgs = "" + aDelayTime + " " + aDelayTime;
          var aObjectName = aGenObjectName();
          var aBoxText = "mc.delay~ " + aDelayTime + " " + aDelayTime;
          var aDelay = aMixerMatrixPatcher.Add(aBoxText, aObjectName);
          aDelay.Outlets[0].ConnectTo(aInput.Inlets[0]);
          return aDelay;
        }
    });

    for(var aChannelIdx = 0; aChannelIdx < aIoCount; ++aChannelIdx)
    {
        var aChannel = aChannels.Channels[aChannelIdx];
        var aInputObj = aChannelIdx == 0
                      ? aMainIn
                      : aOutputs[aChannelIdx];
        foreach (var aOutputChannel in aChannel.OutputsWithoutMainOut)
        {
          var aInputChannelIdx = aOutputChannel.Inputs.IndexOf(aChannel);
          var aLatencyCompensation = aOutputChannel
            .LatencyCompensations[aInputChannelIdx];
          var aTargetInput = aAddDelay
            (aOutputChannel.IoIdx, aLatencyCompensation);
          aInputObj.Outlets[0].ConnectTo(aTargetInput.Inlets[0]);
        }
    }
  }
}

"When you are coding in C/C++ pretty much everything is open."

when you coding an external in C++ you have exactly the same possibilties as the developer of the vanilla externals, and when you run that external in max, then this custom external has the same possibilties than every other external, isnt it? 

for example you can not output a stream of 2/3 of the runtimes´ audio signal rate or make its object box appear in pink color by default.

the only difference is that you could build an external which is different from the vanilla ones say like a router object which can be connected to other instances without patch cords and combines the functions of gate and s/r.


"When you are coding in C/C++ pretty much everything is open."

i still dont get it.

when you coding an external in C++ you have exactly the same possibilties as the developer of the vanilla externals, and when you run that external in max, then  this custom external has the same possibilties than every other external, isnt it? 

for example you can not output a stream of 2/3 of the runtimes´ audio signal rate or make its object box appear in pink color by default.

the only difference is that you could build an external which is different from the vanilla ones say like a router object which can be connected to other instances without patch cords and combines the functions of gate and s/r.


Roman, I might have not explained myself as clearly as I intended.

Every time you want to interface with the patcher you are required to follow certain rules, you have to create inlets and outlets, format your data in a certain way, etc... In C/C++ you get to decide how you communicate among instances of your classes, and how you format your data. So INTERNALLY you are able to engineer the architecture of your software at a much more detailed level. Maybe the keyword I was missing is INTERNALLY. Every time you communicate with the patcher, you gotta go back to following the same rules again. However coding in C/C++ makes it possible to do the heavy lifting INTERNALLY without having to deal with the idiosyncrasies of the patcher itself.

If you think about it, that summarizes the architecture of Jitter for example. In Jitter you always need to write a Max wrapper for whatever functionality the underlining Jitter object implements. Every Jitter object is patcher agnostic. The Max wrapper makes it communicate with the patcher in the way that Max requires.

Roman, I might have not explained myself as clearly as I intended.
Every time you want to interface with the patcher you are required to follow certain rules, you have to create inlets and outlets, format your data in a certain way, etc... In C/C++ you get to decide how you communicate among instances of your classes, and how you format your data. So INTERNALLY you are able to engineer the architecture of your software at a much more detailed level. Maybe the keyword I was missing is INTERNALLY. Every time you communicate with the patcher, you gotta go back to following the same rules again. However coding in C/C++ makes it possible to do the heavy lifting INTERNALLY without having to deal with the idiosyncrasies of the patcher itself.
If you think about it, that summarizes the architecture of Jitter for example. In Jitter you always need to write a Max wrapper for whatever functionality the underlining Jitter object implements. Every Jitter object is patcher agnostic. The Max wrapper makes it communicate with the patcher in the way that  Max requires.

i'm not sure if i get your point nor i know your experience level on procedural languages. you are talking about vanilla pd? i think it is a platform completely different from max isn't it?

we're discussing whats the advantage of writing a max external compared to max patchers? or the difference between vanilla externals compared to max externals? is vanilla compatible with max?

you need the way into "normal" procedural code because procedural problems are a pure hell solving them in a systems like max patcher. (though it's possible)

when luigi says, everything is open he means literally everything. using scripting languages or other shells often has limitations. for example there is no way direct way to call java methods from a java script. once you are at c or c++ (machine level) you can literally adapt anything that exists in the computer world in the fastest possible runtime speed. (you might even write assembler/machine code there)

that is when you need "externals" or a just a (c) api like a lot of applcations/frameworks provide (acutally max is a framework). if a component reaches a certain level of complexity you really have easier life when you go to the procedural level.

with these few lines of code: they do quite the same just that the patcher is still buggy after >20 hours of work where the procedure works fine after <1h of coding. und runs many times faster ;) That is because the semantics of max patcher is just not suitable for such kind of problem.

dynamically creating an deleting max objects