danieleghisi

I must incorporate some third party externals in a Project. Some of them use aliases, as of course Max itself does. For instance, I must incorporate a [bach.==] object, which is an alias for [bach.eq].

When I consolidate the project, [bach.==] is not found, it appears that the alias information has not been put inside the project. Is there a way to solve this?

projects-issues-with-aliases-and-third-party-externals

hm it might sound stupid if you did it but, did you incorporate the bach-objectmappings.txt file in the project ? it should not get rid of that file, but as it should be placed in a "init" folder, i'm not sure you can do that inside a project... unless you can incorporate a package-like hierarchy local to a project...

Yes, I had already tried to put an "init" folder in the project.

But that doesn't work: the "init" folder is automatically deleted and its content is placed inside the "data" folder.

I still hope that there is a way to incorporate aliases in Projects...

Projects seem to be an extremely useful tool to share patches... but objects also have aliases! :)

Otherwise the mechanism is essentially unusable, at least for me...

Yes, I had already tried to put an "init" folder in the project.
But that doesn't work: the "init" folder is automatically deleted and its content is placed inside the "data" folder.

I still hope that there is a way to incorporate aliases in Projects...
Projects seem to be an extremely useful tool to share patches... but objects also have aliases! :)
Otherwise the mechanism is essentially unusable, at least for me...


but what about copying the content of the bach obejcts mapping file into the max objects mapping file? that should solve it forever.

@Roman, this is not the problem, the problem is portability here i think... ie, not having to reinstall everything when someone opens the project

that been said, it should be possible to programatically create a folder inside the package folder, but i foresee a lot of other problems ensuing, and it's an unclean solution... indeed, a local-to-project package-style-hierarchy would be ace ! 'cause you are struggling with aliases here, but i guess other problems might come soon...

@Roman, this is not the problem, the problem is portability here i think... ie, not having to reinstall everything when someone opens the project
that been said, it should be possible to programatically create a folder inside the package folder, but i foresee a lot of other problems ensuing, and it's an unclean solution... indeed, a local-to-project package-style-hierarchy would be ace ! 'cause you are struggling with aliases here, but i guess other problems might come soon...


There's a feature request for better support of packages in projects. Can't really tell if/when this will happen though.

@Roman: Indeed, making things work for me is not an issue. My problem is making things work easily for the generic person opening my project. Ideally, he should just double click on the project file, and that's all.

@vichug: Exactly. I think that aliases are just one of the problems. The generic goal is having package-like features in project, indeed.

@Emmanuel: I personally think that supporting package-like features in projects is a necessary step... Sharing patches is more and more important, and having clean ways of doing that is a real game changer! And projects can actually be this game changer, if they had this full support.

Just to throw another idea, off the top of my head: if (we) developers could have a way to tell if our externals require specific extensions, that would also be a game changer. Otherwise, one always has to put necessary extensions "by hand" in the project, which is both counterintuitive and error-prone.

So... please keep us up to date for any new about a better package-like project support!

Projects issues with aliases and third party externals