mxo object does not instantiates in a stored patch loaded unless w file/install

    Sep 07 2011 | 9:24 pm
    I built with success an mxo object and stored it in a max recognized path .
    When I use it in a new patch, the object is well recognized, but when I recall the stored patch, the object is not recognized any more ( it appears with another color and lost inlets and outlets). At that point, when I load my mxo with menu item File/Install, it works again ?!?
    Any reason for that ? Is there a way to avoid that ?
    Thanks for help and support
    sdk : 5.1.7 xcode : 3.2 or 4.0 both the same result !

    • Sep 08 2011 | 10:13 pm
      You did put the external in the search path, didn't you?
    • Sep 09 2011 | 5:33 pm
      Hi Emmanuel,
      I indeed put the external in the search path at the sdk 5.1.7 level including subforlders, (option / file preferences) where both the physical mxo and the patch are stored.
      What I deed for a week or two, is installing latest version of Max 5 1 9, but no idea if it is related I also have M4L installed and a lot of externals from the community. Everything under OSX10.6.
      As I said, when the mxo has been loaded once, either in design mode or with file install (menu item), the object is recognized. If I recall a stored patch, it is not recognized any more : the object shows all inlet and outlet connections but color is different like greyed, If I delete it in the existing patch + apple Z (undo) then the object looses all inlets and outlets connection. So with a new patch, it would work, but if recreated in the same patch not ?!? Strange..
      The same behaviour occurs with simple object like sdk's sample "simplemax"
      Thanks a lot for your support
    • Sep 09 2011 | 5:50 pm
      I forgot to mention that it only occurs with objects compiled by myself. If this is related to compiler or xcode settings, could you please help me, I am more from the dot net world... Any link to standard xcode settings for max externals ?
      Thanks for your help
    • Sep 11 2011 | 6:27 pm
      The answer is : patcher name should not be object name !