benedikt.sailer

I'm taking my first steps with the min-devkit.

I've been looking through all examples and docs I could find, but I'm failing to find out, how the mechanics for the Max attrui object are working. Basically I want to be able to do the same thing in my external, that attrui does: 

1. Detect the object I'm hooked up to via cable

- I'm currently attaching my external to other objects by finding them with 

void* c74::max::object_findregistered (nameSpace, name); 

- This is working in so far, that my external now receives notifications from the object I'm attached to, once I manually change attributes on the object from within Max.

- I want to find the object I'm attaching to by connecting a patch-cord though, just like attrui does it .. How would I accomplish this? Is there an example anywhere? Is this even possible through min-devkit? (I really wish there was something like a "onPatchcordConnected" callback in the inlet/outlet classes...) 

2. Read out the objects attributes (names and values)

This is where I'm failing, working from the void* pointer i receive from the above mentioned 

 I was under the impression I could just cast the void* to a dictionary (be that c74::min or c74::max) and that also seems to work (at least the cast result is not NULL), but once I then call dictionary functions on my casted object, i get access violations, so I'm definitely doing something wrong. 

How do I read out all attributes (both keys and values) from an object, that is delivered as a void* via 

Or even better, how do i read out all attributes from an object, that I found because a cable connection was made?

Hi everyone,

I'm taking my first steps with the min-devkit.

I've been looking through all examples and docs I could find, but I'm failing to find out, how the mechanics for the Max attrui object are working. Basically I want to be able to do the same thing in my external, that attrui does: 

1. Detect the object I'm hooked up to via cable
- I'm currently attaching my external to other objects by finding them with  void* c74::max::object_findregistered (nameSpace, name); 
and then attach to them withc74::max::object_attach_byptr

- This is working in so far, that my external now receives notifications from the object I'm attached to, once I manually change attributes on the object from within Max. So far so good. 

- I want to find the object I'm attaching to by connecting a patch-cord though, just like attrui does it .. How would I accomplish this? Is there an example anywhere? Is this even possible through min-devkit? (I really wish there was something like a "onPatchcordConnected" callback in the inlet/outlet classes...) 

2. Read out the objects attributes (names and values)
This is where I'm failing, working from the void* pointer i receive from the above mentioned void* object_findregistered() call.
 I was under the impression I could just cast the void* to a dictionary (be that c74::min or c74::max) and that also seems to work (at least the cast result is not NULL), but once I then call dictionary functions on my casted object, i get access violations, so I'm definitely doing something wrong. 

How do I read out all attributes (both keys and values) from an object, that is delivered as a void* via  c74::max::object_findregistered

Or even better, how do i read out all attributes from an object, that I found because a cable connection was made?

Any takers :)?

Hi everyone,

I'm taking my first steps with the min-devkit.

I've been looking through all examples and docs I could find, but I'm failing ... 

recreating-attrui-functionality-with-min-devkit

the (undocumented) message name in min that allows for handling patchcord connections is called 

the only example of this that I know of is in the github source for the 

 from the jit.mo project. That source lists each of the arguments to this function, but usually you only care about source and destination objects, and whether it's a connect or disconnect.

in order to query the destination object's attribute state I believe you will have to jump down to C. you can get all the attribute names via 

 and iterate those. Untested code below (dest is a t_object * passed into patchlineupdate)

long j, symcount= 0;
t_symbol **symarray = NULL;

// get the name of the attributes of the destination object
object_attr_getnames(dest, &symcount, &symarray);
for (j = 0; j < symcount; j++) {
    long ac;
    t_atom *av = NULL;

    // get the attr
    void *attr = object_attr_get(dest, symarray[j]);

    // or get the value
    object_attr_getvalueof(x, symarray[j], &ac, &av);
}

the (undocumented) message name in min that allows for handling patchcord connections is called patchlineupdate.

the only example of this that I know of is in the github source for the jit.mo.join object from the jit.mo project. That source lists each of the arguments to this function, but usually you only care about source and destination objects, and whether it's a connect or disconnect.

in order to query the destination object's attribute state I believe you will have to jump down to C. you can get all the attribute names via object_attr_getnames and iterate those. Untested code below (dest is a t_object * passed into patchlineupdate)

long j, symcount= 0;
t_symbol **symarray = NULL;

// get the name of the attributes of the destination object
object_attr_getnames(dest, &symcount, &symarray);
for (j = 0; j < symcount; j++) {
	long ac;
	t_atom *av = NULL;

	// get the attr
	void *attr = object_attr_get(dest, symarray[j]);

	// or get the value
	object_attr_getvalueof(x, symarray[j], &ac, &av);
}

Just tried it and that actually solved all my issues for now! I wish there was a like button for that kind of comprehensive answer :) 

Just tried it and that actually solved all my issues for now! I wish there was a like button for that kind of comprehensive answer :) 

Cheers

So, that didn't take too long and I hit my next roadblock :) . 

I'm assuming it's due to my lack of understanding of C (I'm a 100% C++ guy and treat C as such, which is painful at best...)

The object I'm fetching the attributes from is [gen~]. I'm specifically interested in fetching [param]s. 

object_attr_getvalueof(x, symarray[j], &ac, &av);

method I can fetch the current values of any of the params, that's all great. 

But now I want to also get the attributes of each [param]. 

E.g. i have the following object in gen~: 

[param someName @min 0. @max 1. @default 0.5]

How would I accomplish that going from the attribute returned by

? I'm assuming those will be child-attributes of the attribute representing the entire [param]? But how do I access those?

So, that didn't take too long and I hit my next roadblock :) . 

I'm assuming it's due to my lack of understanding of C (I'm a 100% C++ guy and treat C as such, which is painful at best...)

The object I'm fetching the attributes from is [gen~]. I'm specifically interested in fetching [param]s. 

With the 
object_attr_getvalueof(x, symarray[j], &ac, &av);
method I can fetch the current values of any of the params, that's all great. 

But now I want to also get the attributes of each [param]. 

E.g. i have the following object in gen~: 
[param someName @min 0. @max 1. @default 0.5]
and I want to read out min/max/default

How would I accomplish that going from the attribute returned by
object_attr_get()
? I'm assuming those will be child-attributes of the attribute representing the entire [param]? But how do I access those?



I don't know if this works with params, since gen is somehow a world in itself, but if I'm not wrong attributes in Max are objects themselves (from a C++ perspective, they would be a derived class of t_object — actually, what the Max API does with structs inside structs is roughly what a C++ compiler does under the hood when you define a class derived from another class, except that C doesn't have an explicit syntax for dealing with this and you're responsible for all the casts). So I'd try with object_attr_getnames((t_object*) attr, blahblah).

Hi,

I don't know if this works with params, since gen is somehow a world in itself, but if I'm not wrong attributes in Max are objects themselves (from a C++ perspective, they would be a derived class of t_object — actually, what the Max API does with structs inside structs is roughly what a C++ compiler does under the hood when you define a class derived from another class, except that C doesn't have an explicit syntax for dealing with this and you're responsible for all the casts). So I'd try with object_attr_getnames((t_object*) attr, blahblah).

While that makes sense to me and the whole point of nested objects/attrs is consistent with the docs, it doesn't seem to work that way (on gen~ objects at least). 

/// get the attr for a [param] called "gen_param_name"

void *attr = object_attr_get ((t_object*)genObject, gensym("gen_param_name"));

/// get the names of the attributes of the param

object_attr_getnames ((t_object*) attr, &symcount, &symarray);

cout << "\tFound param attribute: " << symarray[j]->s_name << endl;

This consistently only finds one attribute name on each [param], which is "category". So unfortunately I don't think that was it, or am I misunderstanding what you're saying?

While that makes sense to me and the whole point of nested objects/attrs is consistent with the docs, it doesn't seem to work that way (on gen~ objects at least). 

 /// get the attr for a [param] called "gen_param_name"
 void *attr = object_attr_get ((t_object*)genObject, gensym("gen_param_name"));
 

  /// get the names of the attributes of the param long symcount= 0;
 t_symbol **symarray = NULL;
 object_attr_getnames ((t_object*) attr, &symcount, &symarray);

/// print attribute names
 for (long j = 0; j < symcount; j++) {
     cout << "\tFound param attribute: " << symarray[j]->s_name << endl;
 }
This consistently only finds one attribute name on each [param], which is "category".  So unfortunately I don't think that was it, or am I misunderstanding what you're saying?

You're not misunderstanding, that's exactly what I had in mind. It makes me think that so-called param attributes are not a part of the more general Max's attribute system, but this is only a conjecture of course. Maybe having a look at the generated code might provide some information? As I'm increasingly digging into gen I'm curious, too, so let me know if you find out something!

That's a very good idea! I'll do that and hope that in the meantime someone flies by, who knows what's going on :) (or maybe this warrants its own post, since we're fairly off-topic from the thread title now?)

After looking at a gen export, I have an idea but am not entirely sure how the exported code fits into the whole t_object think. It might be connected, it might not be... 

Everything is wrapped into a namespace "gen_exported". 

Inside that namespace the gen object is described as 

 struct State -> struct CommonState -> struct ParamInfo 

ParamInfo contains all fields, that I want to access and is the place where the State initializes the parameters from. So I guess with the code above I'm trying to do 

and leave out CommonState. I wonder, maybe that one attribute name I get back on every [param] is the begin of an array which represents the CommonState? (If anyone sees this, before I edit again, feel free to help me with that C syntax :-D )

That's a very good idea! I'll do that and hope that in the meantime someone flies by, who knows what's going on :) (or maybe this warrants its own post, since we're fairly off-topic from the thread title now?)

//Edit: 
After looking at a gen export, I have an idea but am not entirely sure how the exported code fits into the whole t_object think. It might be connected, it might not be... 

Everything is wrapped into a namespace "gen_exported". 

Inside that namespace the gen object is described as struct State

 In there we have a child structure:
 struct State -> struct CommonState -> struct ParamInfo 
ParamInfo contains all fields, that I want to access and is the place where the State initializes the parameters from. So I guess with the code above I'm trying to do 

struct State -> struct ParamInfo 

and leave out CommonState. I wonder, maybe that one attribute name I get back on every [param] is the begin of an array which represents the CommonState? (If anyone sees this, before I edit again, feel free to help me with that C syntax :-D )

min, max and scale are all attributes of an object called filterset. you can get the attr's fileterset object like this: 

void *filterset = object_method(attr, gensym("get_filterset"));

and then query the min, max and scale attributes on the returned filterset object (as well as usemin, usemax and usescale, which indicate if the attr uses those filters).

default is not exposed in any way that I can determine, but you should be able to grab this manually at initialization time I'm guessing. All of this is undocumented (though unlikely to change), use at your own risk.

min, max and scale are all attributes of an object called filterset. you can get the attr's fileterset object like this: 
void *filterset = object_method(attr, gensym("get_filterset"));

Thanks, tried it, but I'm not sure if I'm doing something wrong.

void *attr = object_attr_get ((t_object*)genObject, gensym("my-cool-param-name"));

void *filterset = object_method((t_object*)attr, gensym("get_filterset"));

When I do that filterset ends up as NULL, while genObject and attr are valid. genObject is the pointer I receive on 

Nevermind.... I just spent about 3 hours, trying to get the filterset of a non-[param] gen~ attribute.... if I try your object_method () call on an actual [param] it works of course :facepalm:

Thanks for your help everyone, I think this thread is sorted out ;-)

Thanks, tried it, but I'm not sure if I'm doing something wrong.
void *attr = object_attr_get ((t_object*)genObject, gensym("my-cool-param-name"));
void *filterset = object_method((t_object*)attr, gensym("get_filterset"));


When I do that filterset ends up as NULL, while genObject and attr are valid. genObject is the pointer I receive on patchlineupdate connect.

Nevermind.... I just spent about 3 hours, trying to get the filterset of a non-[param] gen~ attribute.... if I try your object_method () call on an actual [param] it works of course :facepalm:

Thanks for your help everyone, I think this thread is sorted out ;-)

Hi, sorry for reviving this old thread, but I figured it's best to continue on here, because this thread shows where I was coming from originally and what I solved here. 

I'm now trying to accomplish the same thing that I did with a gen~ object, but now I'm trying to get this done with an rnbo~ object. 

So namely, I want to get min, max and default values from rnbo~ params. 

On gen~ objects I was able to grab these from the filterset object, but how would I accomplish the same thing on an rnbo~ object, since the filterset object doesn't seem to exist here :)? 

On gen~ I was getting the min value like so:

void *attr = max::object_attr_get (genObj, max::gensym("paramName"));

void *filterset = max::object_method(attr, max::gensym("get_filterset"));

max::object_attr_getvalueof (filterset, max::gensym("min"), &ac1, &av1);

Hi,   sorry for reviving this old thread, but I figured it's best to continue on here, because this thread shows where I was coming from originally and what I solved here.  

I'm now  trying to accomplish the same thing that I did with a gen~ object, but now I'm trying to get this done with an rnbo~ object.   

So namely, I want to get min, max and default values from rnbo~ params. 

On gen~ objects I was able to grab these from the filterset object, but how would I accomplish the same thing on an rnbo~ object, since the filterset object doesn't seem to exist here :)?   

On gen~ I was getting the min value like so:
void *attr = max::object_attr_get (genObj, max::gensym("paramName"));
void *filterset = max::object_method(attr, max::gensym("get_filterset"));
long ac1;
max::t_atom *av1 = NULL;
max::object_attr_getvalueof (filterset, max::gensym("min"), &ac1, &av1);

This isn't supported in this way at this time, but we could add attr attrs for this that have all these relevant values (might be a little bit different than the gen solution you found). I've made a feature request ticket for programmatic access to parameter/attribute information including min/max/default/etc. However, in the meantime, you could parse the JSON description output in response to the export process, which contains all this information.

I've already considered parsing the info from the json, but for my particular workflow I'd then have to be able to trigger export programmatically through the max api. Is that something that's possible yet?

(On a side note, i already have an open FR for CLI export, which would also solve this... The CLI export is more important than max api export imo, since we need it for proper CI/CD integration of rnbo patchers into our plugin pipeline)

Hey Joshua,

Thanks for making the ticket! 

I've already considered parsing the info from the json, but for my particular workflow I'd then have to be able to trigger export programmatically through the max api. Is that something that's possible yet? 

Programmatic export is also not easily accomplished at the moment, but I've also made a feature request for that. It should actually be easier to export from Max programmatically than on the CLI at the moment, but over time it would be great to support both.

Recreating attrui functionality with min-devkit