search

Cycling74 / max-sdk

Software Development Kit for Max by Cycling '74
Other
262 stars 57 forks source link

STATIC_ATTR_LONG() static attribute function failures #9

Closed diablodale closed 8 years ago

diablodale commented 8 years ago

I am encountering the same failure as experienced by someone in a 2012 Max Forum post at https://cycling74.com/forums/topic/shared-staticglobal-attributes/

The STATIC_ATTR_LONG macros->functions don't work. No attribute appears in inspector or in other Max UI. My primary test case is using them on a Max MOP wrapper class.

No known workaround. It is possible to create a non-static attribute and do custom get/sets to emulate some of the functionality.

tap commented 8 years ago

Thanks @diablodale . This is a documentation problem -- these STATIC_ATTR macros are not for statics/globals but in fact for constants that can only be set once and then not changed.

For actual globals/statics there is a workaround in that thread that you linked to.

The documentation problem has been correct internally and will be pushed here in the near future.

diablodale commented 8 years ago

That doesn't match behavior nor desire. No change in doc other than "not implemented and doesn't work" will fit. The behavior is "doesn't work, nothing appears" Desire is attribute tied to a global static.

jeremybernstein commented 8 years ago

Just a remark: this style of aggressive/provocative/angry bug reporting makes me cringe, and in Tim's place I wouldn't even respond. I wonder aloud if it would be possible to tone it down a bit and recognize that there are people on the other end of your bug reports.

2015-11-18 11:07 GMT+01:00 Dale Phurrough notifications@github.com:

That doesn't match behavior nor desire. No change in doc other than "not implemented and doesn't work" will fit. The behavior is "doesn't work, nothing appears" Desire is attribute tied to a global static.

— Reply to this email directly or view it on GitHub https://github.com/Cycling74/max-sdk/issues/9#issuecomment-157664743.

diablodale commented 8 years ago

Thanks for the feedback. There is no anger behind the writing. That is all created in your reading of it; something you are bringing to the conversation independent of me. I suspect that you feel I am attacking you or Max. I encourage everyone to not bring such interpretation to the conversation as it then leads to hurt or negative feelings.

Instead, I am laying out a gap and what isn't fitting and pointing to that. I already did in the original report so I am trying to further focus and point out what's missing; what the resolution doesn't address.

Is there another way in which I can express that the core part of the bug report "no attribute appears" was not addressed by the resolution "for constants...documentation problem has been correct"? My first sentence points out the failure of the resolution. The next two sentences are bullet points relisting concisely behavior and desire (in bug report language...result and expected).

Personally, I've long since worked around the bug. My intention in even participating and reporting bugs here is to improve the SDK. Often, I can work around them privately. However, that doesn't help others or the product. As seen in the forum post, I am not the only person that encountered this bug. It is we that are the few that are expending the time and effort to report the issues even though we have a private workaround.

So please remember that we are coming from a positive place (want to help make it better); that we are not attacking your product or your staff; and that if we persist, it is to bring clarity and specificity in a C-level SDK which requires high levels of detail and boundary/specificity/clarity.

jeremybernstein commented 8 years ago

Dale, thank you for your response, and for your continued desire to improve our development materials.

The subject of my previous note was not that I take issue with pointing out problems or gaps in our SDK -- I and all of my colleagues wholeheartedly appreciate that. Rather, the fact that you often insist on having the last word, and doing so in an unnecessarily argumentative (interpreted: hostile) fashion. In this case, you've misunderstood (because we don't explain it properly) what a static class attr is for and how it should work (it is not intended to show up in the UI, for once thing). There is no "yes, but..." -- we need to improve the documentation and that's the end of it. A similar case was the t_atom float issue, where you argue for the existence of "floating-point value corruption" where there is none (a float t_atom is defined as 32-bits wide in 32-bit Max).

If you are requesting a feature for a user-facing attribute tied to a global static, that's cool, too, but that wasn't how your response was formulated ("not implemented and doesn't work").

Anyway, I don't want to drag out this discussion any further. Thanks for your help, and for keeping it positive. We'll do our best to improve the detail and clarity of our documentation going forward.