pattrmarker/pattrforward oddness 5.0.3
Hello there,
I wonder if anyone else is experiencing an issue I have right now, since updating to 5.0.3.
Firstly i might say, that I am unable to reproduce this problem with a demonstration patch made in version 5.0.3, and the patch where the problem is occurring (originally made in version 5.0.2) is very large, with many 3rd party objects,many in/out routings etc therefore I haven't posted it.
The problem concerns pattrforward 'send' messages. Using the pattrmarker syntax;
::pattrmarkedsubpatch::object
I am getting errors all the time -
'could not resolve requested object (::pattrmarkedsubpatch::object )'.
A workaround I found was to recreate the pattrmarker objects, but this would prove a lengthy procedure, and on testing found I needed to do this each time I opened my patch (I had saved changes previously of course)..
Otherwise, reverting to the pattrmarker.mxo in version 5.0.2 cures the issue.
Can anyone shed any light on this?
Puzzled,
Leigh
I can confirm the problem in 5.0.3, if that's any consolation. (Mac
10.5.3, MBP 2.16 Ghz)
M
On Jul 1, 2008, at 18:56, Leigh Hunt wrote:
>
> Hello there,
> I wonder if anyone else is experiencing an issue I have right now,
> since updating to 5.0.3.
> Firstly i might say, that I am unable to reproduce this problem with
> a demonstration patch made in version 5.0.3, and the patch where the
> problem is occurring (originally made in version 5.0.2) is very
> large, with many 3rd party objects,many in/out routings etc
> therefore I haven't posted it.
> The problem concerns pattrforward 'send' messages. Using the
> pattrmarker syntax;
> ::pattrmarkedsubpatch::object
> I am getting errors all the time -
> 'could not resolve requested object (::pattrmarkedsubpatch::object )'.
> A workaround I found was to recreate the pattrmarker objects, but
> this would prove a lengthy procedure, and on testing found I needed
> to do this each time I opened my patch (I had saved changes
> previously of course)..
> Otherwise, reverting to the pattrmarker.mxo in version 5.0.2 cures
> the issue.
> Can anyone shed any light on this?
> Puzzled,
> Leigh
Could either of you send a patch which demonstrates the problem, please?
Jeremy
hi.
also stumbled over this, or a similar behaviour.
also in a bigger architecture we link several pattr to one central one, which is part of a pattrstorage. the pattr-architecture is layed out in a patch, with several pattrmarkers.
i figured out, that the links were broken after updating to 5.0.3...
after recreating the pattrmarkers the links worked again, if the pattrmarker was on the same level of the pattrs, but not, if the pattrs where then inside a subpatch.
so this did not work: [pattr data ::pattrmarker::subpatch::pattrname]
i tried to reproduce this, but this bug seems to be hard to catch, sometimes it worked... (?)
the solution for me was to create a pattrmarker on every hierarchy-level (which makes sense, anyway)
so the pattrs look like this now:
[pattr data ::pattrmarker::pattrname]
io
Quote: Jeremy Bernstein wrote on Wed, 02 July 2008 17:29
----------------------------------------------------
> Could either of you send a patch which demonstrates the problem, please?
>
> Jeremy
----------------------------------------------------
Hi Jeremy,
I just tried cutting and pasting a few subpatches out of my big patch but that seems to cure any issues..
I'm afraid I can't really post a patch, it is very large, with many abstractions and 3rd party stuff. If you want me to email you the whole project let me know, if you think it might help source the cause.
regards
Leigh
Quote: Jeremy Bernstein wrote on Wed, 02 July 2008 17:29
----------------------------------------------------
> Could either of you send a patch which demonstrates the problem, please?
>
> Jeremy
----------------------------------------------------
Hi again..
I think this demonstates the problem. Try sending toggle/int thru the pattrforward in subpatch 'c42encoder17' to the pattr object in subpatch 'c42row3', it doesn't work here, until the pattrmarker in subpatch 'c42row3' is renamed/typed.
This is on MBP 2.33, max5.0.3 and os10.5.3.
Hope this helps,
Regards
Leigh
It does, thanks.
Jeremy