Michael Norris

Hi there — I’m working on a Max/MSP external that processes a buffer of sound. I have a crash in buffer_locksamples that only occurs if the user changes the filename argument of the buffer that is being referenced while the external is running.

For instance, my [buffer~] object is set to ‘buffer~ myBuffer jongly.aif’. If I go in and change it to ‘buffer~ myBuffer duduk.aif’, while my external is running, I get the crash in this second line

t_buffer_obj *buffer = buffer_ref_getobject(x->bufferRef);
bufferPtr = buffer_locksamples( buffer );

My external never receives a buffer_changed notification — it just crashes with a EXC_BAD_ACCESS error.

Hi there — I’m working on a Max/MSP external that processes a buffer of sound. 

crash-in-bufferlocksamples-when-changing-the-filename-argument-of-the-buffer

SOLVED
For anyone else who has had this problem, here’s the solution:

The issue is a bit weird, but is due to an undocumented notification that is sent to the external. I had assumed that if the buffer’s filename was changed, then I should receive a “buffer_modified” notification. I was ignoring every other notification — i.e. I was returning 0 at the end of my notify routine.

However, it turns out that when the buffer filename is changed, there are in fact some notifications sent, but they are not ‘buffer_modified’. So what you *actually* need to do, to stop the crash — and the correct way to deal with this is shown in the sample projects, but I hadn’t quite appreciated the importance of it — is that you need to forward *all* notifications to the buffer_ref_notify routine — i.e. you should never return 0 at the end, always: return buffer_ref_notify(x->bufferRef, s, msg, sender, data);

Crash in buffer_locksamples when changing the filename argument of the buffer

cesc

I am working with the jsextensions c-api, the only example I know of is in the 

as parameter in javascript gets interpreted as two parameters (

) but in javascript I am passing obviously only one parameter.

grafik.png

's value in c is two, is this intended or am I missing something?

When I uncomment the line after BOOM, it crashes because I am not correctly getting the pointer to the patcher, any ideas on how to achieve that?

I am working with the jsextensions c-api, the only example I know of is in the max-sdk (simplejs)

Passing this patcher as parameter in javascript gets interpreted as two parameters (jsobject and an integer) but in javascript I am passing obviously only one parameter.

- m.doEvilThingsWith(1) has one parameter and ac's value in c is one
- m.doEvilThingsWith(this.patcher) has one parameter but ac's value in c is two, is this intended or am I missing something?

Here you have the whole example

When I uncomment the line after BOOM, it crashes because I am not correctly getting the pointer to the patcher, any ideas on how to achieve that?

See below the relevant c code part.


I am working with the jsextensions c-api, the only example I know of is in the max-sdk (simplejs)

Passing this patcher as parameter in ... 

jsextensions-c-api-max-object-used-as-a-javascript-class-passing-thispatcher-as-parameter

[jsextensions c-api] Max object used as a JavaScript class: passing this.patcher as parameter

Joe Kaplan

Greetings! I'm trying to create a custom textfield object that will mask the user's input. Like when you type a password into an online form, and the input appears as "****".

I thought I would begin by trying to modify the 

example that comes with the Max SDK. I'm fairly proficient with MIN Devkit. But making the leap into the deep end of Max SDK is proving a bit difficult.

I found the following method in the code:

This appears to be the method that takes the key input, appends it to the string, and redraws the box with the new string. If I want to append a * instead of the character the user typed, this would seem to be the method to modify.

I tried messing around here, just adding some print statements, etc. But it looks like this method doesn't actually fire when a key is pressed. My print statements don't appear, any breakpoints in here don't trigger, and any changes I make don't seem to have any effect.

Can anyone help me understand what this method is doing? Or what other methods I should look to modify to achieve my goal?

I also, I notice throughout this code, the function object_method() is being called with descriptive gensyms like "insertboxtext" and "selectbox," etc. These seem to calling additional, seemingly undocumented, functions that are available to the object.

Where are these functions defined? And how can I learn more about what they are doing? 

Greetings!  I'm trying to create a custom textfield object that will mask the user's input. Like when you type a password into an online form, and the input appears as "****".

I thought I would begin by trying to modify the uitextfield example that comes with the Max SDK.  I'm fairly proficient with MIN Devkit.  But making the leap into the deep end of Max SDK is proving a bit difficult.

I found the following method in the code:


long uitextfield_key(t_uitextfield *x, t_object *patcherview, long keycode, long modifiers, long textcharacter)
{
	char buff[256];
	buff[0] = textcharacter;  // we know this is just a simple char
	buff[1] = 0;
	object_method(patcherview, gensym("insertboxtext"), x, buff);
	jbox_redraw((t_jbox *)x);return 1;
} 

This appears to be the method that takes the key input, appends it to the string, and redraws the box with the new string.  If I want to append a * instead of the character the user typed, this would seem to be the method to modify.

I tried messing around here, just adding some print statements, etc.  But it looks like this method doesn't actually fire when a key is pressed.  My print statements don't appear, any breakpoints in here don't trigger, and any changes I make don't seem to have any effect.

Can anyone help me understand what this method is doing?  Or what other methods I should look to modify to achieve my goal?


I also, I notice throughout this code, the function object_method() is being called with descriptive gensyms like "insertboxtext" and "selectbox," etc.  These seem to calling additional, seemingly undocumented, functions that are available to the object.

Where are these functions defined?  And how can I learn more about what they are doing?  

Thanks for any insights!

Greetings!  I'm trying to create a custom textfield object that will mask the user's input. 

how-does-jboxtextfield-work

This example is probably outdated, but you can utilize the keyfilter method for your needs, though I'm not really interessted to help with something that ends up as copy protection or something

Thanks 11OLSEN.  I was starting to notice something was up when I commented out the "key" method entirely and nothing changed.  Using "keyfilter" makes sense.  Since "keyfilter" triggers on keypress, I can use that to call "set" and make sure the textfield is displaying stars, meanwhile I can store the actual string in a private variable.


I had started thinking down that route, and stopped because it didn't feel like the intended usage.  But now that this approach has some sort of endorsement, I will pursue it.

This is not for copy protecting for anything in Max.  The package will be accessing cloud services, which requires user auth.  Creating and distributing Max patches that ask users to enter passwords into a stock [textedit] box and then passing sensitive data through patch chords seems like a bad thing to do.

I think you need to use the textcharacter that is also passed instead of the keycode (keycode may generate a different character in other countries keyb layouts ?)

Thanks for the tip!  I'm making good progress here at last.   

One other question:  What is the best way to convert the textcharacter long into a char so I can build my string and manage it?

From some brief investigation, it looks like there's nothing to do here, I can just append the textcharacter numbers directly to char array.   But this is assuming textcharacter is typical ASCII, which apparently keycode is not?



Yes, use these numbers as chars should work. Sorry can't help with min devkit. Never got into that and will not. That's just a layer on the C-Api which doesn't give the same deep level of access.  

And btw, seems like you need 2 textfields, name and password? Maybe don't use the textfield instead build a normal ui object and render 2 fields with paint method. User can click one of the fields to enter keys. 

Thanks!  I was thinking about going that route.  It would increase the complexity a bit for me.  But figuring out how to use the paint method might be a good exercise anyway.

But I'm arguing with myself about how much to invest, because whatever I do the solution will be suboptimal.  My package depends on a C++ library.  So all of my objects so far are built with MIN Devkit.  But MIN seems to have limited support for UI objects.    So I'm stuck with this jank where the UI Object (built with Max SDK) will always need to be deployed alongside a separate object that handles the business logic (built with Min).  (there are plenty of ways for the objects to share data without patch cords)  

If I could consolidate this to one Min Object I'd be more inclined to invest in a full-on UI object instead of the simpler solution of providing two textfields and building the rest of the UI in Max itself.


I know it's possible to call Max SDK functions in Min by putting the c74::max namespace in front of them.  In fact I can probably just call functions from jgraphics.h directly in the paint method of the Min Object.  (haven't tested this yet, but it seems possible in theory)

The place where I'm stuck is on how to enable the other necessary boxflags, especially JBOX_HILITE.  The example Min object (min.textslider),   only has a handful of flags enabled.  And these flags are enabled by the ui_operator class that all ui objects in MIN must inherit from.  Since the boxflags seem to be baked into the boilerplate for UI objects in Min, I don't know how I can add my own.

I'm totally open to ideas.  I would LOVE to build a fully featured UI object in Min.

this commit from 2020 seems to indicate that keyboard focus is possible in min without setting any boxflags manually. at the bottom you see the hilite flag is set behind the scenes.
if (m_instance->is_focusable()) {
flags |= c74::max::JBOX_HILITE; }


Fascinating.  Wow!  It looks like a number of the box flags can be set according to the return value of different member functions of m_instance.  This is really encouraging.  Thank you!

I'm having a hard time parsing c_min_operator_ui.h, though.  I don't understand what it's expecting me to do in my Min file.  Am I supposed to call m_instance->is_focusable()?  How I do get that function to return true?  And what is m_instance anyway? 

That is something that's initialized in the constructor for the ui_operator class that my object inherits from.  I'm not seeing how I would interact with it. 

So this looks like it should be possible, but I'm not quite seeing how to do it.

By following up on the definition of is_focusable() i eventually found this block in c74_min_object.h.   The mention of there being a max message "focusgained" gave me the idea to try it.  I created a max message "focusgained" and when the box is clicked on, that message is definitely triggered.   So I guess JBOX_HILITE is set by default on MIN ui objects.  So I think now I can play with jgraphics.h and/or MIN's c74_min_graphics.h to do what I need to do.  

Lots of work ahead of me, but the path seems clear.  Thanks a ton 11OLSEN!!

// SFINAE implementation used internally to determine if the Min class has a member named focusgained.
    // NOTE: This relies on the C++ member name being "focusgained" -- not just the Max message name being "focusgained".
    //
    // To test this in isolation, for a class named slide, use the following code:
    // static_assert(has_focusgained<slide>::value, "error");

template<typename min_class_type>
    struct has_focusgained {
        template<class, class>
        class checker;

template<typename C>
        static std::true_type test(checker<C, decltype(&C::focusgained)>*);

template<typename C>
        static std::false_type test(...);

typedef decltype(test<min_class_type>(nullptr)) type;
        static const bool value = is_same<std::true_type, decltype(test<min_class_type>(nullptr))>::value;
    };

So I guess JBOX_HILITE is set by default on MIN ui objects

Not by default, rather by checking if you have defined a focusgained (member?) in your code.
remember you also need "focuslost" and "key" and you're good to go. BTW c++ doesn't mean you can't use the classic C-Api approach to write the external. Anyways, I'm happy that you see a path now :) 


defined a focusgained (member?) in your code.

I'm not sure what you mean by this.  I created a "focuslost", "focusedgained" and "key" message in the MIN Object.  The focuslost and focusgained message worked beautifully.  The "key" message seemed to work too.  But it throws a "vector subscript out of range" error, upon returning.   :(

there's only 4 args not 5 ? ptr,long,long,long

I don't think that's it.  If I inspect the args vector at a breakpoint it shows there are 5 args.

also, I get the same error, if I do absolutely nothing in the MIN_FUNCTION and just return right away..

  I also get a different error in c74_min_atom.h with a "keyup" message.

This happens after I lift the key, but before a breakpoint on the MIN_FUNCTION is hit.


To your previous point, it looks like I can just save a Max SDK file with a .cpp extension, and call my C++ functions and it will compile fine.  I believe a recent version of the SDK makes this possible.  But it still feels a bit risky.  I'm happy to go that route if I have to.  But my experience with MIN as a novice coder has been quite wonderful so far, and it would be excellent to figure out this tragically underdocumented area of Min Devkit.

I tried compiling the c object as a .cpp file.  That seemed to go fine.  But the next step is adding  the functions from the third party C++ library I'm trying to integrate with Max.  Declaring objects defined by the library seem to go fine, but as soon as I try to call a function that is defined inside the .dll of my library, the object fails to load.  It compiles.  But when I create an instance of it in Max, i get a "Error 126 loading external MaxSDKUITest"

These same functions work just fine, from an external written in Min.  So it seems that changing the extension to .cpp does not suddenly give Max SDK support for Modern C++.  I'm not taking this as a surprise.

MIN Devkit is just a wrapper about Max SDK.  And Min Devkit creates the c74::max namespace.  So how about we write a Max SDK UI object in Min.

#include "c74_min.h"
using namespace c74::max;

and then proceed to write a Max SDK Object.

In this case I just copied and pasted the contents of the uitextfield object from the max sdk examples.  The linter was fine with this.  So far so good.  Min is amazing!

It says "Unresolved external on jpatcher_syms_init() referenced in function ext_main"

So.... something about the way Min wraps Max SDK causes a linkage failure for the function required to initialize UI objects.

I almost threw up my hands in fury.  It seemed like all paths were blocked.  Then I decided to check some of the other UI examples in Max Sdk.  It turns out uitextfield is actually  the only one that calls jpatch_syms_init().

The other UI examples, including 11OLSEN's excellent 11UILayer, do not require this function to initialize.

I tried copy-pasting a different example from max sdk into the Min object that is using namespace c74::max.  It compiled just fine and behaved itself in Max.  I quickly added some  functions from my third party library.  These performed as expected as well.

So it looks like if I want to paint my own rectangles, manage selection and deselection of each box, capture the keyboard input, draw characters in the right place, draw the cursor, move the cursor, make the cursor blink, I might be able to achieve that.  And it will probably be a good exercise for someone who's never dabbled in computer graphics before.

It turns out the only thing I can't do is the simple solution I had originally planned, which was to use Max's existing textedit functionality to gather keyboard input from the user.

This has been a really strange journey, but I'm glad the next step is to start writing my own code.

For jpatcher_syms_init() to work, you need to include /common/jpatcher_syms.c. You see this line in the cmake of uitextfield sourcefolder: ${MAX_SDK_INCLUDES}/common/jpatcher_syms.c
But you can also add this line in your source file: #include "common/jpatcher_syms.c"


The same applies when you use other libraries. You probably have a .lib file for the dll which needs to be linked when building.

btw: jpatcher_syms.c and commonsyms.c are only pre-defining symbol ptrs. So you can reduce the use of gensym() which does a table lookup everytime.  e.g. instead of executing gensym("patcher") you can just write _sym_patcher. You can also prepare your own symbols like you see in the UILayer eg in global scope: "static t_symbol* _sym_keyup;" and in the main method: _sym_keyup = gensym("keyup"); This is simply an efficiency measure to make the code running faster in the end..

I tried the key message in min-devkit. I think you need to return 1 or 0 which lets Max know if the key was cosumed I assume. This works for me:

message<> key{ this, "key",
        MIN_FUNCTION {
 
            char text[256];
            text[0] = int(args[4]);
            text[1] = '\0';
 
            cout << "number: " << args[4] << " textchar: " << text << endl;
 
            return {1};
        }
    };

Thanks again 11OLSEN for all your help with this!  I am learning a lot and feel like progress is coming.  This seems like it may be doable now, and that's thanks to your help!

I tried loading it alongside the Min API

Probably because some of these objects are in Max namespace, which is causing syntax confusion.

Probably because some of these objects are NOT in the Max namespace.  And the blanket application of that namespace is causing syntax confusion.

This may be solvable by modifying jpatcher_syms.c, or being more clever with how I use the namespace.  I'm not sure.


But at the moment I'm still stuck on building UI_textfield in C++.  Though It looks like I finally found a list of all the secret messages max objects can receive.  That's exciting!


Regarding linking the .lib file for my third party dll:

I'm pretty sure this is not the problem.  I'm very familiar with the linkage requirements of the third party library.  I double checked all my properties, it seems correct.  The same properties work correctly with a Min object.  It looks to me like the Max SDK Headers do not want to play well with Modern C++ libs... or at least they don't want to play with mine.


RE: use write_sym_patcher instead of gensym

RE: The "Key" message in Min needs to return 1.  
This worked!!  That's huge actually.  It means I can probably go ahead and build my object as a Min object.  And use c74_min_graphics.h and possibly call functions from jgraphics.h with a c74::max prefix when necessary.  
I still get an exception on "keyup", even if that returns 1.  Not critical for my usecase, but there's still some ambiguity around what works and what doesn't work in Min.

Current status:
* It's still pretty unclear how we are expected to handle advanced UI objects in Min.  Some things seem to work and some things don't. There's a lot of stumbling in the dark.

* Just using the Max SDK headers does not seem to play well with external c++ libraries.

* Using c74_min.h and then "using namespace c74::max" and writing a Max SDK object seems to work for everything except textfields.

This is probably enough for me to proceed with my project (i've said that before and been wrong).  Textfields would be nice.  And actually understanding Min would also be nice.

I don't see your pics, but all I described about jpatcher_syms and commonsyms is how I handle it in Max-Api. Don't know how much this applies to Min-Api as well..

regarding keyup in min-devkit:
that is not implemented but simply add in c74_min_object_wrapper.h


 regarding "error loading external 126":
I had that in the past, the additional dll can't be found. In some cases the dlls have to be in the same folder as Max.exe. 

Error 126 on the Max SDK file is resolved.  It was indeed a problem with my project configuration.  And I can call my third party functions successfully.  So if I get sick of trying to mix MIN and Max SDK, the option is available to build it strictly as a Max SDK external.

I now also recognize some advantages of min-devkit. In any case, the code is much leaner, requiring less writing. And if we really have unrestricted access to the c-level API at the same time, we could combine the best of both APIs. I will test this further

For sure.  I think Min is pretty slick.  I taught myself to code by working with Min. 

I'm finally making good progress here.   Min's c74_min_graphics.h wraps some, but not all, of jgraphics.h.  What it does implement is very easy to use.  Although the "image" class it defines seems like it might be unfinished?  Or at least I can't figure out how it's supposed to work.  But I can confirm jgraphics.h is fully accessible inside a a Min "paint" message.  So creating image surfaces is still perfectly viable.

I'm happy I'll be able to do this in a Min object, so can I copy/paste my existing code instead of having to rewrite sections of it for Max SDK.  Also, attributes will be much easier to handle.

I think the only thing that's still not clear is how to set the box flags.  I discovered that it would be nice to use the JBOX_GROWY flag.  But again, these flags seem to be hardcoded into the constructor of the class a Min UI object must inherit from.

If I modify c74_min_operator_ui.h I get the expected results.  So it works... I just need to figure out how to set it from within my code. 

Not without editing header file or adding your own header file with an alternative ui_operator class.. 
Do you know how to set the c74::max namespace for a block of code?  Would like to avoid the prefix in every line;


This will apply the namespace from where you declare it to the end of the file, or to the end of the block if you do it inside a block, which is probably recommended.  If you found a different solution, do let me know.

Regarding setting the flags... 
I decided to create my own header with an alternative class.  So instead of having the Min Class inherit from ui_operator it inherits from a class called custom_ui_operator which is defined in my own header.  custom_ui_operator is a copy/paste of ui_operator, except it takes a third template argument.   

In addition to default height, and default width of the object, I provide a third argument for flags.  I then modified the constructor to refer to that argument when setting the flags.

Now, in my object file, before instantiating my object class, I define a const long variable that contains my preferred flags.  (defining it as const is important).  Then pass that variable as an argument to the custom_ui_operator class template, and off we go.

To create the header I copy pasted c74_min_operator_ui.h.  Removed lines 117-140  regarding wrap_as_max_external_ui.  Then I replaced all instances of "ui_operator" with "custom_ui_operator" and "ui_operator_base" with "custom_ui_operator_base"

UPDATE:  This didn't actually work.  I was able to get the object to build, but when I create an instance of it in Max i get a fatal exception error in the constructor.  It looks like Min is expecting the ui class to be named "ui_operator."  Changing the name causes things to fail

This means we're stuck modifying c74s headers.  This is a bit sad because I'd like to include Min as a submodule in my repo.   

For me it works with a separate header file,  just do not replace ui_operator_base class 

Works for me now.  I thought I tried that.  I must have messed something up along the way.  Thanks!

How does JBOX_TEXTFIELD work?

I'd like to create some UI Objects that integrate with a C++ library. Min Devkit seems to be the tool for the job, but it's support for UI Objects seems limited. After doing some digging into how UI Objects are handled in Max SDK, I have a few questions:

 say the UI object has to inherit from the ui_operator class. Digging into this class template, I can see how it is handling most of the 

required to set up a UI Object in Max SDK.

However, when it comes to setting the JBOX flags, a handful of flags are active and the rest, like JBOX_TEXTFIELD or JBOX_HILITE, for example, are commented out. Is there any way to override this and set my own flags? I tried modifying the ui_operator class definition in c74_min_operator_ui.h and was able to generate a whole bunch of errors, but nothing that would compile and work.

Similarly, how does the paint method work in Min? I looks like c74_min_graphics.h wraps many of the functions in the original jgraphics.h, but is this a complete replacement?

I understand that it's possible to call c74::max functions from within Min, but it gets a little confusing when Min is wrapping some of the relevant functions, but not all of them. Especially when it comes to the object setup. As a novice/intermediate programmer, I still get a bit confused by all of MINs macros and templates, and I'm not sure how/where to override them.

 gives a list of messages ui_operator can respond to. This appears to be only a subset of the messages that are actually available in Max. Is this intended to be partial list? If so, how to find information on rest of them? Or is UI functionality only partially implemented in Min?

If I have to, I can build my UI object with Max SDK, and then pass values to and from a different object made in Min to access my C++ library. But it would be better if this could all be one object.

I'd like to create some UI Objects that integrate with a C++ library.  Min Devkit seems to be the tool for the job, but it's support for UI Objects seems limited.  After doing some digging into how UI Objects are handled in Max SDK, I have a few questions:

The Min Devkit docs say the UI object has to inherit from the ui_operator class.  Digging into this class template, I can see how it is handling most of the initialization required to set up a UI Object in Max SDK.

However, when it comes to setting the JBOX flags, a handful of flags are active and the rest, like JBOX_TEXTFIELD or JBOX_HILITE, for example, are  commented out.  Is there any way to override this and set my own flags?  I tried modifying the ui_operator class definition in c74_min_operator_ui.h and was able to generate a whole bunch of errors, but nothing that would compile and work.

Similarly, how does the paint method work in Min?  I looks like c74_min_graphics.h wraps many of the functions in the original jgraphics.h, but is this a complete replacement?

I understand that it's possible to call c74::max functions from within Min, but it gets a little confusing when Min is wrapping some of the relevant functions, but not all of them.  Especially when it comes to the object setup.  As a novice/intermediate programmer, I still get a bit confused by all of MINs macros and templates, and I'm not sure how/where to override them.


The Min documentation gives a list of messages  ui_operator can respond to.  This appears to be only a subset of the messages that are actually available in Max.  Is this intended to be partial list?  If so, how to find information on rest of them?   Or is UI functionality only partially implemented in Min?

If I have to, I can build my UI object with Max SDK, and then pass values to and from a different object made in Min to access my C++ library.  But it would be better if this could all be one object.

Hi All,
I'd like to create some UI Objects that integrate with a C++ library. 

mindevkit-ui-objects-setting-jbox-flags-and-accessing-paint-methods

I don't have an arduino so i might have misunderstood what you're asking for, but hopefully this reply also helps bump this thread to the attention of others who might know better/further how to help there specifically on https://testmyspeed.onl/.

MinDevkit UI Objects:  Setting JBOX flags and accessing paint methods?

petrus04

i don't understand how to correctly store and recall a dict as the attribute magic value in the min Devkit?

Hi all, 
i don't understand how to correctly store and recall a dict as the attribute magic value in the min Devkit? 

attribute<dict> ... ... 
doesn't work.
attribute<atoms> ... ...
??

Hi all, 
i don't understand how to correctly store and recall a dict as the attribute magic value in the min Devkit? 
attribute<dict> ... 

min-devkit-how-to-correctly-store-a-dict-as-the-magic-value-attribute

Min Devkit : How to correctly store a dict as the "magic" value attribute

Greetings, I would like to use Max SDK to create a family of objects with the naming convention MyFamily.MyName.

Similar to the zl family, or the dict family, etc.

This convention appears to be the default for Min Devkit. But for these objects I need to do some UI things that I don't believe are currently possible with MIN (as far as I can tell). I believe it is possible to use this naming convention with Max SDK as well because I have seen it in some of the packages availabel in the package manager.

However, I can't seem to figure out how to do it. The object gets it's name from the filename of the .c file, but within the c file we have to define a struct, msg handlers, etc., that all require the name of the object as well. But these cannot have periods in them.

Can anyone provide any guidance on how this naming convention can be achieved?

image.png

This convention appears to be the default for Min Devkit.  But for these objects I need to do some UI things that I don't believe are currently possible with MIN (as far as I can tell).   I believe it is possible to use this naming convention with Max SDK as well because I have seen it in some of the packages availabel in the package manager.

However, I can't seem to figure out how to do it.  The object gets it's name from the filename of the .c file, but within the c file we have to define a struct, msg handlers, etc., that all require the name of the object as well.  But these cannot have periods in them.

Greetings, I would like to use Max SDK to create a family of objects with the naming convention MyFamily.MyName.
Similar to the zl family, ... 

max-sdk-create-objects-with-dots-in-name

Okay, i found some examples of this in the gl folder of the MaxSDK examples.  It looks like they are using underscores in place of periods in the .c file.  I tried doing a find replace to do that throughout my file, and it's still not working.   Curious if anybody is aware of any gotchas that I might be missing here.

It turns out when you're declaring the new class you use a string that has to match the filename.  Everywhere else, you can use any value you want as long as it's consistent.  Progress.  Yay!



You should be good if folder/filename and the actual class name in class_new() in your main method are matching. Your function names and so on do not have to match exactly.

Oh man I was pulling out my hair on this with bloody XCode for so long... lol

Max SDK: Create objects with dots in name?

Shakeeb Alireza

 requires that I wrap a useful subset of the Max c-api in cython for use by python scripts running in the external.

This process has brought me into immediate contact with the max c-api interface for a number of objects and data structures in the rich Max ecosystem: atoms, atom arrays, dictionaries, buffers, binbufs, atombufs, patchers, etc..

Sometimes this ends up being very useful, like the outcome of recent work which implemented the python buffer protocol for the Buffer wrapper class allowing python scripts to read and write python builtin arrays and numpy arrays to `buffer~` objects...

Other times, I feel a bit like an archeologist, as when methods for curious objects still exist in the Max headers but where the documentation is sparse or abbreviated or includes obscure hints of prior historical use.

Of these, I found binbufs, and to a much lesser extent, atombufs, to be the most curious, as it was not immediately clear what should be done with them. The 8.2 Max C-API is particularly cryptic about binbufs "..

you won’t need to know about the internal structure of a Binbuf, so you can use the void 

and searching for code which uses the 'binbuf' object only revealed that it is still used today in puredata as the textual format for its `.pd` filetype.

Atombufs are also curious as they have an even more limited set of methods and seem to be just a struct container for atoms with an 'argc' and 't_atom *argv' field. I've implemented a wrapper for the methods but I can't figure out where to use them or what methods actually received atombuf objects.

Further research on the web uncovered a copy of the fascinating "Writing External Objects for Max 4.0 and MSP 2.0" by David Zicarelli which was most informative in its description of how binfbufs were used in Max as

I was wondering if this functionality still exists in whole or in part in Max 8.x and I took the minimal example used in the book below and copied into the clipboard and then from Max > File > New from Template and I was quite pleased to find that it created a patcher window with the relevant connected objects!

I tried to replicate this, with some limited success with the current binbuf methods in the Max c-api, and found that by evaluating something like this "#N buffer~ buf jongly.aif" in a binbuf I could create a hidden buffer object called `buf` in the patcher, but when I tried to send "#P" messages to the patcher as per the current "(script <msg>" format to [thepatcher]", I got stuck with errors and crashes of Max proper, and I could not map from the historical way (binbufs) to the new "scripting" way in Max 8.x..

It would be greatly appreciated if someone in the know, could help uncover the mysteries of binbufs and answer the question of whether the functionality of scripting in the above economical message-oriented format is still fully available at the Max c-api level.

, a python library for offline generation the .maxpat json format, I'm particularly aware of how useful and entertaining this can be.

My slow-burn project,  python3 externals for Max project requires that I wrap a useful subset of the Max c-api in cython for use by python scripts running in the external. 

This process has brought me into immediate contact with the max c-api interface for a number of objects and data structures in the rich Max ecosystem: atoms, atom arrays, dictionaries, buffers, binbufs, atombufs, patchers, etc..

Sometimes this ends up being very useful,  like the outcome of recent work which implemented  the  python buffer protocol for the Buffer wrapper class  allowing python scripts to read and write python builtin arrays and numpy arrays to `buffer~` objects...

Of these,  I found binbufs, and to a much lesser extent, atombufs, to be the most curious, as it was not immediately clear what should be done with them. The 8.2 Max C-API is particularly cryptic about binbufs "..you won’t need to know about the internal structure of a Binbuf, so you can use the void ∗ type to refer to one" and searching for code which uses the 'binbuf' object only revealed that it is still used today in puredata as the textual format for its `.pd`  filetype.

 "... the mechanism Max uses to save messages, called Binbufs (short for binary buffer)." Binbufs are an “Atomized” counterpart of the Max text file. When you copy or duplicate part of a patch, it’s turned into a Binbuf. The Binbuf can then be “evaluated” because it consists of Max messages."

max v2;
#N vpatcher 50 38 450 338;
#P number 138 67 35 0;
#P number 98 67 35 0;
#P number 98 168 35 0;
#P newex 98 127 50 0 +;
#P connect 0 0 1 0;
#P connect 3 0 0 1;
#P connect 2 0 0 0;
#P pop;

I tried to replicate this, with some limited success with the current binbuf methods in the Max c-api, and found that by evaluating something like this "#N buffer~ buf jongly.aif" in a binbuf  I could create a hidden buffer object called `buf` in the patcher, but when I tried to send "#P" messages to the patcher as per the current "(script <msg>" format to [thepatcher]", I got stuck with errors and crashes of Max proper, and I could not map from the historical way (binbufs) to the new "scripting" way in Max 8.x..

It would be greatly appreciated if someone in the know, could help uncover the mysteries of binbufs and answer the question of whether the functionality of scripting in the above economical message-oriented format is still fully available at the Max c-api level. 

As the author of py2max, a python library for offline generation the .maxpat json format,  I'm particularly aware of how useful and entertaining  this can be.

My slow-burn project,  python3 externals for Max project requires that I wrap a useful subset of the Max c-api in cython for use by python ... 

on-the-current-utility-of-binbufs-and-atombufs

Hey Shakeeb, I *think* I remember being told by someone who knew more about them that they are an older system still in the code for backwards compatibility and can be ignored for green field work. But I can't remember much beyond that. There might be a conversation with me about them somewhere in search archives?

Yup, I've come around to the same conclusion: that in current versions of Max, the t_binbuf object is perhaps there mainly for compatibility and may be even be reduced in power. 

max v2;
#N vpatcher 50 38 450 338;
#P number 138 67 35 0;
#P number 98 67 35 0;
#P number 98 168 35 0;
#P newex 98 127 30 12 + 100;
#P connect 0 0 1 0;
#P connect 3 0 0 1;
#P connect 2 0 0 0;
#P pop;

Copy the above and do a File > "New from clipboard" and it'll work: basically create a new patcher window with connected objects.

But if you create a t_binbuf via binbuf_new() and then do a binbuf_text(), followed by binbuf_eval() with the above, it'll  won't throw an error (indicating that it's parsed correctly), but it will do nothing..

i'm not sure about binbuf_eval but you could do the "new from clipboard"-way in the code:

char* srctext = "max v2;\
		#N vpatcher 50 38 450 338;\
		#P number 138 67 35 0;\
		#P number 98 67 35 0;\
		#P number 98 168 35 0;\
		#P newex 98 127 50 0 + ;\
		#P connect 0 0 1 0;\
		#P connect 3 0 0 1;\
		#P connect 2 0 0 0;\
		#P pop;";

t_binbuf* myBB = binbuf_new();
binbuf_text(myBB, &srctext, strlen(srctext));

t_object* myClipboard = object_new(_sym_nobox, _sym_clipboard);

object_method(myClipboard, gensym("frombinbuf"), myBB);

object_method(_sym_max->s_thing, gensym("newfromclipboard"));

object_free(myClipboard);
freeobject(myBB);


But why you wan't to use this deprecated stuff? You know that you can use the script interface of [thispatcher] in code as well? 

That's really cool, I didn't know you could do that... Actually, to your point I have been focusing on `scripting in the patcher`. Here's my current implementation of the patcher object as a cython extension:

I converted your nifty code into a method of the binbuf object:

def new_from_clipboard(self, str text):
        """Evaluate the text in the binbuf by sending it the Max clipboard
        
        Thanks to 11OLSEN for the nifty solution
        https://cycling74.com/forums/on-the-current-utility-of-binbufs-and-atombufs
        """ 
        cdef MaxApp app = MaxApp()
        cdef mx.t_object* clipboard = <mx.t_object*>mx.object_new(
            mx.gensym("nobox"), mx.gensym("clipboard"))
        self.add_text(text)
        mx.object_method(clipboard, mx.gensym("frombinbuf"), self.ptr)
        mx.object_method(app.ptr, mx.gensym("newfromclipboard"))
        mx.object_free(clipboard)

I couldn't access `_sym_max->s_thing` for some reason, but the above is equivalent. (-:


Cycling '74 Forums

SOLVED For anyone else who has had this problem, here’s the solution: The issue is a bit weird, but is due to an undocumented notification ...

I am working with the jsextensions c-api, the only example I know of is in the max-sdk (simplejs) Passing this patcher as parameter in ...

Works for me now. I thought I tried that. I must have messed something up along the way. Thanks!

I don't have an arduino so i might have misunderstood what you're asking for, but hopefully this reply also helps bump this thread to the ...

Hi all, i don't understand how to correctly store and recall a dict as the attribute magic value in the min Devkit? attribute<dict> ...

Oh man I was pulling out my hair on this with bloody XCode for so long... lol

Ok, glad it helps.

I'm getting back around to working on this initiative again so I thought I'd bump this to see if anyone has any comments. This related ...

Hi, i would like to store the content of a dict in a pattr, using the special Value attribute defined as explained in the mindev kit ...

The old url is not working, but I found a new one just recently after some ...