feature request (with prototype): overridable pv


    Apr 15 2007 | 7:53 pm
    Hi,
    As promised, here's the prototype of the overridable pv object that I've been talking about lately on this list. It introduces a separate definition object that determines the scope of a variable, thus allowing for overriding.
    These objects are 100% what I want them to be, except that they're in javascript.
    So, dear Cycling '74, if there is any chance for you to make this a native max object, that would create a lot of possibilities.
    Thanks, Mattijs
    Alternatively: ---- save as MK.pv.pat
    ---- save as MK.pvdef.pat
    ---- save as MK.pv.js
    autowatch = 1; inlets = 2; outlets = 2;
    toLoad = new Global("toLoad");
    var pvName = null; var patcherArgsDone = false; var initDone = false; var pattrReturn = null;
    function setName(v) { pvName = v; }
    function bang() { if (inlet == 1) patcherArgsDone = true; if (toLoad.done && patcherArgsDone && !initDone) { getLink(pvName); initDone = true; } }
    function getLink(name) { var path = searchUp(this.patcher, "", name); if (path != null) outlet(0, "bindto", path); else pst("error: Definition of " + name + " not found"); }
    function searchUp(p, path, name) { //pst("searchUp: p " + p + ", path " + path + ", name " + name); var def = null; if (p != null) def = getDef(p, path, name); else return null;
    if(def != null) return "" + path + def + "::pv_value"; else return searchUp(p.parentpatcher, "parent::" + path, name); }
    function getDef(p, path, name) { var checkName = null; var child = p.firstobject; while (child != null) { if (child.maxclass == "patcher") { if (child.subpatcher().name == "MK.pvdef.pat") { //pst("opvdef.pat found. checking path " + path + child.varname + "::opv_name"); checkName = getPattr(path + child.varname + "::pv_name"); if (checkName == name) return child.varname; } } child = child.nextobject; } return null; }
    function getPattr(path) { pattrReturn = null; outlet(1, "bindto", path); return pattrReturn; }
    function anything() { if (inlet == 1) pattrReturn = messagename; }
    function pst(v) { post(v + "n"); }
    ---- save as MK.pvdef.js
    autowatch = 1;
    toLoad = new Global("toLoad"); toLoad.amount = null; toLoad.done = false;
    function loadbang() { if (toLoad.amount != null) toLoad.amount++; else toLoad.amount = 0; }
    function bang() { if (toLoad.amount == 0) { toLoad.done = true; toLoad.message = "bang"; toLoad.sendnamed("defInitDone", "message"); } else toLoad.amount--; }
    ---- save as anything (has to be loaded to trigger loadbangs):

    • Apr 16 2007 | 6:26 pm
      Am 15.04.2007 um 15:53 schrieb Mattijs Kneppers:
      > These objects are 100% what I want them to be, except that they're > in javascript.
      Why is this a disadvantage? They are cross-platform and customizable.
      > So, dear Cycling '74, if there is any chance for you to make this a > native max object, that would create a lot of possibilities.
      I would simply note that we do offer a C SDK to facilitate the creation of custom objects by users. To be fair, some of the features of Max which you are exploiting (I'm principally referring to pattr) are neither fully documented nor available to 3rd party developers (that is, writing an object which behaves like a pattr object is not currently possible). I'm hoping to open that up to developers down the road, but we've got other, more pressing concerns at the moment.
      I guess that the short answer is, no time soon will this be written by us. Stick with JS for now. If it works, it works!
      Jeremy
    • Apr 17 2007 | 8:47 am
      Quote: Jeremy Bernstein wrote on Mon, 16 April 2007 20:26 ---------------------------------------------------- > > Am 15.04.2007 um 15:53 schrieb Mattijs Kneppers: > > > These objects are 100% what I want them to be, except that they're > > in javascript. > > Why is this a disadvantage? They are cross-platform and customizable.
      I understand your comment. Unfortunately, javascript still has a few issues when used heavily. I need this object essentially as a replacement for send/receive in a patch with currently around 700 send/receive pairs (I counted them with textwrangler :p).
      I tried replacing all send/receives with these abstractions. But overall loading slowed down significantly, there were issues with load order and I got several crashes in js calls (I can send you the crash reports if you want).
      So I am afraid that I can't use these objects in practice..
      > > > So, dear Cycling '74, if there is any chance for you to make this a > > native max object, that would create a lot of possibilities. >
      .. which I guess explains my request a little better.
      > I would simply note that we do offer a C SDK to facilitate the > creation of custom objects by users. To be fair, some of the features > of Max which you are exploiting (I'm principally referring to pattr) > are neither fully documented nor available to 3rd party developers > (that is, writing an object which behaves like a pattr object is not > currently possible). > I'm hoping to open that up to developers down > the road, but we've got other, more pressing concerns at the moment.
      Yeah, some load order and pattr hacks were necessary to make this work. I would be doing this in C if it was possible..
      > > I guess that the short answer is, no time soon will this be written > by us.
      Ok, I understand, that's a pity.
      > Stick with JS for now. If it works, it works!
      Unfortunately this is not always the case..
      Appreciate your reply, of course.
      Thanks, Mattijs
      > > Jeremy > > > ----------------------------------------------------
    • Apr 17 2007 | 9:04 am
      Hi, I hear that there can be a problem if js names are the same as abstraction names. Here is a version where js names are different from the abstraction names.
      Furthermore I recommend using this link to download instead of copy-pasting from your browser. It appears that when you paste the js objects without having the javascript files in your search path, the js objects init with only 1 in-/oulet instead of making a bogus object that retains in/outlet connections. This corrupts one of the abstractions.
      I'd say this is another feature request: js object should retain connections if a js object is pasted or opened but the file is not found. Cheers, Mattijs