Question on handling Max's global namespaces (for tables in particular)…

Feb 21, 2012 at 10:19pm

Question on handling Max's global namespaces (for tables in particular)…

Hi All -

Still trucking along nicely in my Max eval (14 days remaining) and I’ve run into this question a few times, without finding any great solutions yet, so I thought I’d throw it out to get some opinions.

As I’ve learned, Max seems to use a “global” namespace for all named objects. For example, if you create two table objects, both named “table mytable”, they will reference the same shared data.

This aspect of tables can be very useful, particularly when combined w/ the “refer” command, however it seems I also have scenarios where it complicates matters.

The most direct and obvious problem is an abstraction which I would like to use multiple times within a patch (or even in a different patch loaded at the same time) – If I use a normally defined “table mytable”, then each instance of the abstraction will share the table data, while in this case I need each instance to have its own table data.

I’ve hit upon a few possible workarounds – I’ve looked at the commands to dynamically create tables and I’ve successfully done this using programmatically generated table names (so they can be made unique), but this adds complexity because I have to create table, patch table, etc.

I’ve also looked at just passing in the tables to each instance, so they can be uniquely defined in the meta project, or possibly passing in an ID that will be used to create a unique identified dynamically, but this clutters the parent patch with details that should be hidden in the abstraction.

None of these options seem particularly elegant – Is there any easier solutions I’m overlooking?

Why aren’t namespace clashes a bigger problem in Max (or are they)? Isn’t it correct that if I make an abstraction/patch and call my table “mytable”, and someone else does the same thing, our patches will not work together correctly? This seems like it could be a tricky problem to hunt down in complex setups… What’s the solution?

As a precaution I am now prefacing all my names w/ a unique extension, a poor man’s namespace, like mylib_myobj_myname, where only myname changes within each object. Are there better practices I should consider? Of course this doesn’t solve the table namespace issue, but I feel like one is less likely to run into namespace collision problems this way.

Thanks in Advance, and Best Regards -


Feb 22, 2012 at 6:17am

I think I’ve found a solution so I’ll follow-up in case someone else see’s this down the road…

It looks like for this I need to use the “#0″ argument. I did not realize this was a special automatic argument that resolves to a random id. I think this will solve the problem nicely, as I can use “table #0mytable” to generate unique table names as well as messages (refer #0mytable) to pass as table names reference.

A bit of work to redo all my table/send/receive etc names but worthwhile because it solves all the namespace issues for objects meant to be used multiple times.



You must be logged in to reply to this topic.