Brian H.

Is there a reason a pattrforward message isn't resolved when the receiving pattr object is in an abstraction? The path to it is correct, AFAIK. When I replace the abstraction with a subpatcher (in the exact same place in the hierarchy), it works fine.

Hi,
Is there a reason a pattrforward message isn't resolved when the receiving pattr object is in an abstraction?  The path to it is correct, AFAIK.  When I replace the abstraction with a subpatcher (in the exact same place in the hierarchy), it works fine.

pattrforward-in-abstraction

Sure...Wanted to be sure, because it's not as tidy as I would like for this. The main patch is called Sony DMX-R100. It is a folder of abstractions and images, relevant bits attached here (others not included or deleted). For example, I took the Polarity subpatch in the Input abstraction. As I read it, the toggle in the bpatcher should be talking to the pattr. But I get errors in the Max window. You (hopefully) see where, as a last-ditch effort, I tried making Input/polarity subpatchers and it worked.

I've read all I can find and checked my paths. I'm new the whole pattr thing and still figuring it out, so I'm sure that has something to do with it. Plus my first attempt with it is a rather complex (for me) patch.

Please let me know any tips or questions about it all...

Sure...Wanted to be sure, because it's not as tidy as I would like for this.  The main patch is called Sony DMX-R100.  It is a folder of abstractions and images, relevant bits attached here (others not included or deleted).  For example, I took the Polarity subpatch in the Input abstraction.  As I read it, the toggle in the bpatcher should be talking to the pattr.  But I get errors in the Max window.  You (hopefully) see where, as a last-ditch effort, I tried making Input/polarity subpatchers and it worked.

I've read all I can find and checked my paths.  I'm new the whole pattr thing and still figuring it out, so I'm sure that has something to do with it.  Plus my first attempt with it is a rather complex (for me) patch.

 is considered as a sublevel in the hierarchy of the patch so you probably need to use the parent keyword to go down from one level as demonstrated bellow.

A bpatcher is considered as a sublevel in the hierarchy of the patch so you probably need to use the parent keyword to go down from one level as demonstrated bellow.

Yes, I see your example works and I read about the parent:: in the path. I had tried it and it didn't work in my patch (just tried it again). Still Max window errors that the pattrforward can't be resolved. Would the path be specified differently for an abstraction vs. subpatcher? The thing I don't get is why the same path works as a subpatcher (for example, the polarity toggle in my bpatcher) and not as an abstraction (for example, the trim dial).

Many thanks for helping my become un-stuck!

Yes, I see your example works and I read about the parent:: in the path.  I had tried it and it didn't work in my patch (just tried it again).  Still Max window errors that the pattrforward can't be resolved.  Would the path be specified differently for an abstraction vs. subpatcher?  The thing I don't get is why the same path works as a subpatcher (for example, the polarity toggle in my bpatcher) and not as an abstraction (for example, the trim dial).

It works the same way for abstractions. See example attached.

That's what I would expect, and your example works for me. I was hoping someone would see some reason in my patch why this is not working for me?

That's what I would expect, and your example works for me.  I was hoping someone would see some reason in my patch why this is not working for me?

Clean your example a little bit. I don't have the time and the courage to figure that out. If you take the time to clean the example you will even find out by yourself.

I had cleaned it some, but this should be much more immediate-- Just didn't want to take too much away, for fear of changing something significant to my problem. But I cut it down and had the same issue. I did go back and re-test, hoping to find something, but didn't. I would think it's something simple that maybe I've looked past over 2 weeks of staring at this thing. I'm new to pattr and am still a little lost in it all, but I think I get pattrforward, it's not that complicated. And yet...

Hi,
I had cleaned it some, but this should be much more immediate-- Just didn't want to take too much away, for fear of changing something significant to my problem.  But I cut it down and had the same issue.  I did go back and re-test, hoping to find something, but didn't.  I would think it's something simple that maybe I've looked past over 2 weeks of staring at this thing.  I'm new to pattr and am still a little lost in it all, but I think I get pattrforward, it's not that complicated.  And yet...

Brian H. wrote on Thu, 26 February 2009 09:36

Thanks for the effort simplifying the patch. I attached a version which works fine. 

 attribute, not the name of the abstraction or subpatcher. That was your problem.

Brian H. wrote on Thu, 26 February 2009 09:36Hi,
I had cleaned it some, but this should be much more immediate-- Just didn't want to take too much away, for fear of changing something significant to my problem.  But I cut it down and had the same issue.  I did go back and re-test, hoping to find something, but didn't.  I would think it's something simple that maybe I've looked past over 2 weeks of staring at this thing.  I'm new to pattr and am still a little lost in it all, but I think I get pattrforward, it's not that complicated.  And yet...

Thanks for the effort simplifying the patch. I attached a version which works fine. pattrforward uses the varname attribute, not the name of the abstraction or subpatcher. That was your problem.

WOW. Thanks so much! I can't say I would have figured that out, and it would have been a deal-breaker for this project. It's irritating to have spent 2 weeks banging my head on it, but great to understand it finally!

But how is this crucial detail documented? I read the Help ref for pattrforward, and I didn't see anything about varname or scripting name being used and not object names-- In fact, to me implies the opposite. If you get a moment, let me know what you think.

Again, thank you for your altruistic time, effort, and patience!

WOW.  Thanks so much!  I can't say I would have figured that out, and it would have been a deal-breaker for this project.  It's irritating to have spent 2 weeks banging my head on it, but great to understand it finally!  

But how is this crucial detail documented?  I read the Help ref for pattrforward, and I didn't see anything about varname or scripting name being used and not object names-- In fact, to me implies the opposite.  If you get a moment, let me know what you think.

[pattrforward] in abstraction?