Mattijs

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.

http://www.oli.tudelft.nl/avdl1064/overridable%20pv.zip

    if (inlet == 1) patcherArgsDone = true;

    if (toLoad.done && patcherArgsDone && !initDone) 

    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);

    if (p != null) def = getDef(p, path, name);

    if(def != null) return "" + path + def + "::pv_value";

    else return searchUp(p.parentpatcher, "parent::" + path, name);

        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;

    if (inlet == 1) pattrReturn = messagename;

    if (toLoad.amount != null) toLoad.amount++;

        toLoad.sendnamed("defInitDone", "message");        

---- save as anything (has to be loaded to trigger loadbangs):

All files a zip:
http://www.oli.tudelft.nl/avdl1064/overridable%20pv.zip

var pvName = null;
var patcherArgsDone = false;
var initDone = false;
var pattrReturn = null;

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 getPattr(path)
{
	pattrReturn = null;
	outlet(1, "bindto", path);
	return pattrReturn;
}

function anything()
{
	if (inlet == 1) pattrReturn = messagename;
}

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--;
}

feature-request-with-prototype-overridable-pv

Am 15.04.2007 um 15:53 schrieb Mattijs Kneppers:

> These objects are 100% what I want them to be, except that they're 

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!

> 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.

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!

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 

> 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 

> 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 

> Stick with JS for now. If it works, it works!

Unfortunately this is not always the case..

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). 

>
> > 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. 

>
> Jeremy
>
>
>
----------------------------------------------------


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.

http://www.oli.tudelft.nl/avdl1064/overridable-pv-(jsnames-changed).zip

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.

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


feature request (with prototype): overridable pv