AudioMatt

Is there a way I can make a method or a scope "static" or "global?" I've been looking around for such a thng but instead I've been dealing with lots of scoping errors. I'm in a poly inside another poly so the parent game is getting pretty nuts.

Is there a way I can make a method or a scope "static" or "global?" I've been looking around for such a thng but instead I've been dealing with lots of scoping errors.  I'm in a poly inside another poly so the parent game is getting pretty nuts.


oo-objects-question

There's no way to do that yet in the oo objects. The problem is that everything is explicitly instantiated at runtime in Max, rather than defined and compiled. Not totally off the radar though.

If you can describe what you're trying to do, we may be able to suggest ways to handle it.

It's also possible you are running into an oo objects vs poly~ bug. Does this seem familiar?

https://cycling74.com/forums/topic.php?id=14524#post-77730

It's not the poly bug. I wrote some abstractions to help me. here they are.

The thing I realized is that there is no such thing as static in max because "methods" get instantiated over and over unlike other languages. (not that this is your fault. Jesus Christ these things are a godsend)

Typically, in java, I was doing a lot of calling to static methods to do big stuff like "turn the whole thing off!" It would be nice to somehow, one day, separate the data, the audio and the methods like a "real" object oriented language.

It's not the poly bug.  I wrote some abstractions to help me. here they are.  

The thing I realized is that there is no such thing as static in max because "methods" get instantiated over and over unlike other languages.    (not that this is your fault.  Jesus Christ these things are a godsend)  

Typically, in java, I was doing a lot of calling to static methods to do big stuff like "turn the whole thing off!"    It would be nice to somehow, one day, separate the data, the audio and the methods like a "real" object oriented language.  

Thanks. Obviously, we aren't actively developing at this point (due to work committments), but the oo objects are not a dead project. It's good to know that they're in use and appreciated.

I'd given this some thought a while back, and the "static" keyword might make some sense in the context of a subpatcher in an abstraction, which is the closest thing to a class definition we have.

The way I think this *could* be handled is that you'd add [p @oo foo static] to the abstraction, then when the abstraction is instantiated the static patcher would be instantiated *once*, invisibly, and either removed from the instantiated abstraction or presented as a dummy object (possibly double-clickable, not sure about inputs/outputs). Any oo.calls into the static patcher would go to the invisible singleton.

This would also work for the proposed oo.alias in an abstraction, but not for a raw oo.method, since the method body is separate to the oo.method object - so you'd need to encapsulate as a static subpatcher and use an entry method to get a static method.

As far as static *access* goes, I'd expect static objects in an abstraction to only be accessible from within the abstraction (ie file scope). You'd need to define a separate public accessor method if you wanted to use them from outside an instantiation of the abstraction.

Defining something as static inside an ordinary patcher would be possible but pretty much equivalent to defining it private, since you'll never have another instantiation of that specific patcher (only a copy). But as soon as you save it as an abstraction and instantiate you'd get static behaviour, which may be useful in development. Mattijs, are you watching this thread?

So much for theory. In practice, I bet it's a whole nasty can of worms to implement...

I'd given this some thought a while back, and the "static" keyword might make some sense in the context of a subpatcher in an abstraction, which is the closest thing to a class definition we have. 

So much for theory. In practice, I bet it's a whole nasty can of worms to implement...


I need a few more decades to think about this. John, you must have thought you were a glass of orange juice by the time you were done writing these.

A double clickable singleton object that loads a patcher one once and deletes it when the last [singleton myClass] object is removed would be useful. I can do that in java if need be. It can be a separate deal.

Maybe it's because I'm javacentric but I don't understand why the static methods need to be private. The reason I made the post is because oo.call paths are all relative. You can't jump around in the hierarchy with static calls. so [oo.call myClass.lightSwitch.getOnOff] isn't possible. If I understand the objects, in a sense, unless you want to go traversing up the hierarchy, you're stuck private no matter what.

The solution as I see it, would be to add file names to the list of things oo.method could look up.

This way you could have [oo.call MainPatcher.circle.getArea] and you could call that from anywhere unless you explicitly set it to private.

and yes. They are incredibly used by me. THANK YOU

I need a few more decades to think about this.  John, you must have thought you were a glass of orange juice by the time you were done writing these.

A double clickable singleton object that loads a patcher one once and deletes it when the last [singleton myClass] object is removed would be useful.  I can do that in java if need be.  It can be a separate deal.

Maybe it's because I'm javacentric but I don't understand why the static methods need to be private.  The reason I made the post is because oo.call paths are all relative. You can't jump around in the hierarchy with static calls.  so [oo.call myClass.lightSwitch.getOnOff] isn't possible.  If I understand the objects, in a sense, unless you want to go traversing up the hierarchy, you're stuck private no matter what.

The solution as I see it, would be to add file names to the list of things oo.method could look up.  

This way you could have [oo.call MainPatcher.circle.getArea]  and you could call that from anywhere unless you explicitly set it to private.

... I think.
... I have no clue
... this makes my head hurt.

and yes.  They are incredibly used by me.  THANK YOU


Here's a singleton object. It's controlled by MXJ but calling the method should be just as fast as send and receive.

I'll include it in the release of mat.abstractions

Here's a singleton object.  It's controlled by MXJ but calling the method should be just as fast as send and receive.  

I'll include it in the release of mat.abstractions


Mattijs and I had a few discussions about whether we should adopt Java's access model. In the end we decided that Max has enough ways to make things public and/or global already, and the oo objects should enforce a private by default policy.

My interpretation of "static" access would be the same as C/C++ - file scope. A static member would be accessible from anywhere in the same file (ie class, ie any instantiation of the same abstraction), and shared among all instances of the file/class/abstraction.

With that in place, it *might* be possible for the oo objects to call class (file) methods directly, without visibly instantiating the class (though an instance would have to be loaded behind the scenes to do so). Conceptually, this might be stretching the "Max way" a bit too far.

And we don't do global. If you want a globally accessible method in the top patcher, what's wrong with the Max send/receive objects?

If you want to do that with oo objects, you either

A: traverse the hierarchy upwards to discover the method then store a reference to it, or

B: pass a reference to the method down through the heirarchy via oo patcher constructor args at startup. [oo.alias] will help with the latter when it is available - though I also had some thoughts about constructor args being automatically assigned to private member variables, which would allow their use in oo subpatcher args without any additional objects, ie [p oo_1 @oo mypatcher], where oo_1 would be the first argument passed into the parent oo patcher.

If you want to do that with oo objects, you either 

A: traverse the hierarchy upwards to discover the method then store a reference to it, or 

B: pass a reference to the method down through the heirarchy via oo patcher constructor args at startup. [oo.alias] will help with the latter when it is available - though I also had some thoughts about constructor args being automatically assigned to private member variables, which would allow their use in oo subpatcher args without any additional objects, ie [p oo_1 @oo mypatcher], where oo_1 would be the first argument passed into the parent oo patcher.


OK *this* makes a ton of sense to me... the easy way to do this would be to do [loadmess this]->[deferlow]-->[oo.call right inlet]-->[value reference id]

John thanks for indulging me, I learned a ton.

OK *this* makes a ton of sense to me...   the easy way to do this would be to do [loadmess this]->[deferlow]-->[oo.call right inlet]-->[value reference id]

John thanks for indulging me, I learned a ton.


oo.objects Question