5. Creating Asset Manager Projects

Asset Manager project is no different from a regular Max patch other than a few objects that are used to integrate into Asset Manager.

5.1 Setting up the environment

In order to use the objects for creating Asset Manager projects, Max search paths need to be configured correctly. As mentioned in 2.5. Run Asset Manager, Asset_Manager_PATHONLY.maxpat can be used to setup appropriate paths.

5.2 SampleProject Patch

One of the best ways to learn how to create Asset Manager project is to look at an example. SampleProject is, as the name implies, an sample project that shows the usage of Asset Manager objects. The project is found inside _common/Projects folder.

It may be helpful to look at SampleProject patcher while following through the rest of the section.

5.3 Project and Open Sound Control Address

Asset Manager uses Open Sound Control as the primary vehicle for network communication and integration. Therefore, each project requires a unique OSC address that identifies a project.

For example, am_config.txt shows that the base address for SampleProject is /SampleProject. Any messages sent to Asset Manager with the OSC address starting with /SampleProject is identified for SampleProject project. Below, you will see how to receive network messages into your project using the project.osc.recv object.

5.4 Required object

In order for Asset Manager to load/unload projects and open their patcher window, projects must include an inlet at the top level of the patch.

5.5 project.init and Project Configuration File

If a project requires access to the abstract signal paths, it must include a single instance of project.init object. The purpose of project.init is to

  1. set and notify (from the 1st outlet) the overall volume of the project,
  2. initialize the project I/O,
  3. create the panner abstraction layer, and
  4. allow local development of the project without having to load it through the main Asset Manager window or having to have the main window opened.

project.init takes three arguments:

  1. First argument is always #1. This is used to determine if the project was opened locally or loaded from Asset Manager.
  2. Second argument is the name of the patch.
  3. Third argument is the project configuration file for local development.

project.init has two inlets:

  1. float; volume (in amplitude) to set project's overall volume
  2. bang; re-read project configuration file. If the project is open on its own (e.g. during local development), it reloads the configuration file specified in the argument. If the project is opened via main Asset Manager window, it reloads the configuration file specified in am_config.txt.

project.init has two outlets:

  1. set float; volume of the project. If a OSC message is sent to set the project's volume, an amplitude value is sent to notify the patch. It is not necessary to set the volume yourself as it is taken care of internally. Additionally, the volume value is prepended by 'set' to avoid message overflow when a number box is connected between project.init's outlet and inlet.
  2. [0|1]; a number 0 or 1 is sent to identify if when the project's DSP is muted (1) or not (0). This is useful to do anything special in the patch when DSP is muted. Note that project.osc.recv will still receive messages regardless of the DSP state in the project.

5.6 Local Development and Runtime Modes

In the subsection above, we learned about project.inti and how it's useful for local development. We will expand on the concept of "local development" mode vs "runtime" mode in this subsection.

As mentioned earlier, "local development" is a way to work on a project in a natural way, without having to have the patch loaded from Asset Manager. "Runtime" mode is when the project is loaded from Asset Manager. It is runtime because the patcher cannot be directly edited when loaded this way, analogous to Max/MSP Runtime application.

In the early days of Asset Manager, if a project needed to be integrated, it had no way but to be loaded through Asset Manager to get any messages in or audio in and out. This imposed difficult workflow, where any changes had to be done "offline" and only be able to test it fully inside Asset Manager.

To improve the workflow, Asset Manager developed a method to work on projects without Asset Manager. In order to work with and without Asset Manager, it requires two extra objects (an inlet and project.inti) and Asset Manager's signal path objects (3.3. Signal Flow Overview) instead of the typical adc~ and dac~.

In order to have the flexibility to work in both, project configuration file is specified differently in each mode. In local development mode, project configuration file is specified in the argument of project.init. For runtime, it is specified in am_config.txt file as we saw in the previous section.

5.7 Getting Signal Out

Coming soon. Please look at SampleProject for examples.

5.8 Getting Signal In

Coming soon. Please look at SampleProject for examples.

5.9 Using a Panner

Coming soon. Please look at SampleProject for examples.