problem? pv resets value when initialized inside abstraction

Apr 1, 2007 at 11:42am

problem? pv resets value when initialized inside abstraction

Hi,

When I add a pv in a subpatcher, its value will become the same as a pv in its parent. But when the pv is added in an abstraction, the value of its parent is reset to 0.

See below:

— save as ‘pvInside’

#P newex 45 59 38 9109513 pv test;

— save as anything:

#P comment 289 56 150 9109513 2) re-init abstraction (type and delete a space in the object box);
#P window linecount 1;
#P newex 41 96 26 9109513 print;
#P newex 241 56 44 9109513 pvInside;
#P comment 79 56 65 9109513 1) set value;
#P button 82 74 15 0;
#P number 41 56 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 41 74 38 9109513 pv test;
#P window linecount 3;
#P comment 99 74 73 9109513 3) output value: it has been reset to 0;
#P connect 2 0 1 0;
#P connect 3 0 1 0;
#P connect 1 0 6 0;

Do I miss something? If not; this is a problem, right?

Best,
Mattijs

#31115
Apr 4, 2007 at 12:31pm

Mattijs Kneppers schrieb:
> Do I miss something? If not; this is a problem, right?

You miss that pv is supposed to be private. A [p somthing] is still in
the same domain as if you would de-encapsulate it…

I think this is not a problem, there is no such thing as a variable that
is only visible within a scope defined by the patcher including its
subpatchers. Either global or local, nothing inbetween.
I doubt that this is a problem, because if you really want that, you
just need to pass a #0_argument to your subpatchers. This would make
your patchers much more readable. The other idea you expected, which is
exposed by some programming languages, is something I would avoid like
spaghetti code…
Much worse than send/receive… ;-)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#100654
Apr 6, 2007 at 10:53am

Quote: Stefan Tiedje wrote on Wed, 04 April 2007 14:31
—————————————————-
> Mattijs Kneppers schrieb:
> > Do I miss something? If not; this is a problem, right?
>
> You miss that pv is supposed to be private. A [p somthing] is still in
> the same domain as if you would de-encapsulate it…

I think I am aware of how pv works. My point is that, apart from scope issues, pv shouldn’t ever reset a shared value when instantiated.

>
> I think this is not a problem, there is no such thing as a variable that
> is only visible within a scope defined by the patcher including its
> subpatchers. Either global or local, nothing inbetween.
> I doubt that this is a problem, because if you really want that, you
> just need to pass a #0_argument to your subpatchers. This would make
> your patchers much more readable.

I can safely assure you that I am capable of choosing how to design my patchers. In the mean time I need a variable with a scope, for numerous cases, and pv is the closest it gets in max.

> The other idea you expected, which is
> exposed by some programming languages,

*ahum* -all- programming languages.

> is something I would avoid like
> spaghetti code…

Hehe.. I’ll not reply to this. What I -will- do on the other hand is post a feature request with a protoype of what I need the scoped variable object to do. I’ll have to make this prototype in javascript and it could take me quite some time, but I want this discussion to be over once and for all.

> Much worse than send/receive… ;-)
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-

Sorry if I sound a little harsh, it all appears a little hard to explain.. Thanks of course for replying, Stefan.

Mattijs

#100655
Apr 10, 2007 at 8:59am

Mattijs Kneppers schrieb:
> I think I am aware of how pv works. My point is that, apart from
> scope issues, pv shouldn’t ever reset a shared value when
> instantiated.

Now I get it, I didn’t make the complete test. According to the bug
reporting guidelines the “expected results” which you mentioned above:
“pv shouldn’t ever reset a shared value when instantiated in another
patcher.” was clearer than in the original post.

This would clearly prevent you from scripting pv or patchers which rely
on pv.
I guess its intended, because in the help file it is stated in the
[patcher more]: “pv can take arguments to set its initial values…”
which implies (sort of) that without, its instantiated with 0…

I never used pv, especially since the advent of pattr I have no reason
to do so, as I am sure you can get what you want with the pattr family
of objects (or with javascript as you seem to be willing to do… ;-)

Stefan.


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#100656
Apr 10, 2007 at 9:36am

Quote: Stefan Tiedje wrote on Tue, 10 April 2007 10:59
—————————————————-
> Mattijs Kneppers schrieb:
> > I think I am aware of how pv works. My point is that, apart from
> > scope issues, pv shouldn’t ever reset a shared value when
> > instantiated.
>
> Now I get it, I didn’t make the complete test. According to the bug
> reporting guidelines the “expected results” which you mentioned above:
> “pv shouldn’t ever reset a shared value when instantiated in another
> patcher.” was clearer than in the original post.

I agree, could have been clearer.

>
> This would clearly prevent you from scripting pv or patchers which rely
> on pv.

exactly..

> I guess its intended, because in the help file it is stated in the
> [patcher more]: “pv can take arguments to set its initial values…”
> which implies (sort of) that without, its instantiated with 0…

Maybe, but this only happens when pv is instantiated inside an abstraction. So the behaviour is not consistent at least. I don’t think this is intended. Cycling?

>
> I never used pv, especially since the advent of pattr I have no reason
> to do so, as I am sure you can get what you want with the pattr family
> of objects

I can’t. Pattr can’t be accessed without knowing the exact path to the object. Pattrmarker won’t help bacause I can’t use globals.

> (or with javascript as you seem to be willing to do… ;-)

I am making a prototype right now with javascript and this will work in isolated situations, but I am going to use this object very very intensively. Javascript will slow down too much and, unfortunately, I also found javascript still too unreliable (crashes) for this intensive use. That’s why I’ll call it a prototype and pray for C74 to implement it in the core of max.

Mattijs

#100657
Apr 13, 2007 at 4:28pm

Mattijs Kneppers schrieb:
> I am making a prototype right now with javascript and this will work
> in isolated situations, but I am going to use this object very very
> intensively. Javascript will slow down too much and, unfortunately, I
> also found javascript still too unreliable (crashes) for this
> intensive use.

But if you use the javascript only for finding the path, and then just
take pattr for the “intensive” use it should be fine….

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#100658
Apr 13, 2007 at 4:34pm

Mattijs Kneppers schrieb:
> I am making a prototype right now with javascript and this will work
> in isolated situations, but I am going to use this object very very
> intensively. Javascript will slow down too much and, unfortunately, I
> also found javascript still too unreliable (crashes) for this
> intensive use.

But if you use the javascript only for finding the path, and then just
take pattr for the “intensive” use it should be fine….

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#100659
Apr 13, 2007 at 6:36pm

Quote: Stefan Tiedje wrote on Fri, 13 April 2007 18:34
—————————————————-
I understand your point. But I already tried that. I used this as an alternative to send/receive, which is how I want to use pv. My patch is HUGE, with say 500 to 1000 send/receives. On startup, I would have to execute 1000 javascripts. I hoped with all that I have that I’d be wrong but.. it started crashing, caused slow load times and unpredictable load sequences. :’( Javascript just isn’t there yet. Native objects are.

I can only hope that Cycling 74 will understand the necessity of the object that I’ll be posting a prototype of this weekend and make it a native max object..

Mattijs

Ps. actually this was off topic. The original question of why a pv resets its peers when loaded inside an abstraction still stands. I think it is a bug.

> But if you use the javascript only for finding the path, and then just
> take pattr for the “intensive” use it should be fine….
>
> Stefan
>
> —
> Stefan Tiedje————x——-
> –_____———–|————–
> –(_|_ —-|—–|—–()——-
> — _|_)—-|—–()————–
> ———-()——–www.ccmix.com
>
>
—————————————————-

#100660

You must be logged in to reply to this topic.