Neil Baldwin

Just finishing up a large-ish project that contains 25+ external (bpatcher) files and was wondering about a couple of things:

Is it prudent/good practice to try to make your external file names somehow unique e.g. prefixing with "MYCOOLPROJECT_" ?

What are the advantages/disadvantages of using the 'Embed in parent' option for bpatchers? Almost all of the externals referenced in the project are of use only to my project and often are only abstracted this way for convenience (instancing etc.)

How do people go about distributing updates or future versions of their projects? How do you update the device in Live? During development I've just been manually deleting it from my Live library and installing again but this doesn't seem end-user friendly.

Is it good practice to include a version numbering schema in the package filename e.g. MYCOOLPROJECT-1-0-0 ?

Is it prudent/good practice to try to make your external file names somehow unique e.g. prefixing with "MYCOOLPROJECT_"  ?

Just finishing up a large-ish project that contains 25+ external (bpatcher) files and was wondering about a couple of things:
Is it ... 

packagingdistribution-best-practices

Those are good questions. I'll try to give what insight I can. As far as bpatchers, I had a similar set of

 with a lot of bpatchers in them. I should of made a guide to bpatchers while it was fresh because they definitely caused me some confusion too. Looking at my project, I did not use the 'embed in parent' option. One thing I remember doing was under "Show Containing Project" on the bottom toolbar I used the '+' to make sure the subpatchers were listed as "Explicit" dependencies. This made freezing work consistently without issue because Max knew exactly where to find the files.

I made my file names unique as well. It seems likely a good idea in this instance.

I did not include a version number in the name of the .amxd file. If the update was big enough I may add V2 to the name, but otherwise I would find another place to indicate an incremental update version number. Some sites like maxforlive.com or Gumroad in my case help show version numbers too. I haven't had to do either kind update yet, but my general advice would be to test as much as you can to figure out the best strategy and then communicate to your users well about how to approach an update. I'll try to remember to follow-up on this thread as I get more info. Good luck with your release!

Those are good questions. I'll try to give what insight I can. As far as bpatchers, I had a similar set of projects with a lot of bpatchers in them. I should of made a guide to bpatchers while it was fresh because they definitely caused me some confusion too. Looking at my project, I did not use the 'embed in parent' option. One thing I remember doing was under "Show Containing Project" on the bottom toolbar I used the '+' to make sure the subpatchers were listed as "Explicit" dependencies. This made freezing work consistently without issue because Max knew exactly where to find the files.

unique names with nametags and/or project names are obligatory 1. locally during development 2. when you want to give the project to a friend for testing 3. when you want to use it on another computer and 4. when you want to combine two programs into a single one one day.

so even if it is not required when you target is a live device or standalone application, it still makes sense. and this applies to everything in a project, i.e. patches, media files, images, shader, preferences/coll.txt, you name it.

naming packages including version number? not the worst idea. i do it, too. i do it with everything else, too. for example with music projects or software collection. it is really nice mainly when you share files. we all know that: you download an update to your favorite free text editor and the file is called "installer.zip", just like the last version. the other da you dont know which is which. no, it should read "texteditor 3.0.1.zip" please.

the exception for /packages would be that you make a proper installer which updates the existing version. then you can put the version number info somewhere inside instead of renaming the package.

unique names with nametags and/or project names are obligatory 1. locally during development 2. when you want to give the project to a friend for testing 3. when you want to use it on another computer and 4. when you want to combine two programs into a single one one day.

so even if it is not required when you target is a live device or standalone application, it still makes sense. and this applies to everything in a project, i.e. patches, media files, images, shader, preferences/coll.txt, you name it.

the exception for /packages would be that you make a proper installer which updates the existing version. then you can put the version number info somewhere inside instead of renaming the package.


@trevorbeingtrevor I really appreciate your reply, thank you so much 🙏

Packaging/Distribution Best Practices?