Arranging everything

Hi Reid,

The warning message comes because links between scripts in SoundFlow are either package-local (within the package) or global (refer to both the package and the script/macro inside of it).

You can see this in certain scripts like this:

A package-local reference to a script or macro looks like this:
package:123456789 where the numbers would refer to the script and "package" means: find it inside this same package.

A global reference to a script or macro looks like this:
user:abcdefgh:12345678 where the "user" refers to the user's global settings, the letters between the colons refer to the package id and the numbers to the script/macro inside that package. In other words this is a reference to something in another package.

(Note, that in reality both package ids and script ids have both letters and numbers, I just used them above to illustrate how to parse them).

When you move something out of a package, any references you would have between scripts and macros and decks in that package may break, because those references were package-local (package:12345678 format) and now that you're moving the script or macro out of your package, if for example you had a deck in that package referring to the script/macro, that reference would no longer be able to resolve.

---

Now that we've talked a bit about references and how they work, let me talk about how we recommend arranging things.

First of all, you should distinguish between what I call "public" and "private" packages.

Public packages in this situation are packages that you have published or that you intend to be able to publish at any point in the future. These packages should generally be limited to a single scope - for example you could have a collection of "Reid's AudioSuite Macros" or something like that. Generally, don't make a public package of everything but instead focus on limited areas. This is so that anybody who installs your package later will not get a lot of stuff they don't need.
The rule for references in public packages is: They have to be entirely self-contained. That is, they can only use package-local references (package:12345678 format). In other words: You can't have content (decks, macros, scripts, surfaces etc.) in a public package that refers to something outside of the package.
Think of a public package as almost like a physical, selfcontained box that you can ship to somebody. It should be properly wrapped and not leaky :)

Private packages. This could be just a single package or several packages, that's up to you. Private packages are the packages that you don't intend to share with somebody else.
A private package, since it won't be shared with anybody, can have any type of references that you want. It can refer to other macros/scripts in its own package through package-local references - or, it can refer to any installed package, or to any of your own public packages.
Once you start building things that should be shared, organizing a public package so that it makes sense to somebody who isn't you, you can slowly start copying/moving things over to those public packages. But you don't really need to separate these things before you start thinking about publishing anything.

Please note, that with the upcoming version of SoundFlow it'll be made possible to organize contents inside packages in subfolders. This will help maintain a structure within large packages so that you won't have to split things up in packages unless it's because you actually want to deploy them differently.

Another way to look at this is:

• Packages are deployment units. Anything that should be deployed/installed together should be in the same package.
• The exception is private packages. They can refer to any installed content you have. For example, I have a " Decks" private package (with a space prefix to put it at the top of my package list). This private package contains the decks I've built privately for myself that cannot be shared - or decks that are editable copies of decks installed from other users. This package refers heavily to content from other packages. However, each of the public packages I've shared/published exclusively refer to their own content internally.

I hope this helps clarify things a bit :)