/ Topics / Workflows

Asset-Based

The idea of an asset-based workflow is commonplace but deserves some focused discussion.

Nerd Alert:

A soundscape is constructed by combining a number of separate assets of different types. At the root of it all a master javascript describes relationships between other assets and can thus represent the process to produce a final result. Javascripts can reference other javascripts, clap plugins, audio files, song.hz files, etc all of which combine to produce your final mix.

Let's now elaborate these themes in the context of Hz.

The Workspace

The workspace is the folder where assets reside. A Hz session operates relative to a single active workspace and you can change this at any time (but not mid-performance). The default workspace is ~/Documents/Hz and it's possible that you'll never need to change it. This is because you can create any number of sub-projects within your workspace and then easily share assets across sub-projects. In larger-scale productions you may find value in segregating assets by project and now you'll switch workspaces as you move between projects.

A workspace is comprised of a primary folder but also supports ancillary folders. You can add or remove ancillary folders to your workspace as another source of assets. If you have a collection of samples, or beats or really anything, ancillary folders are a way to integrate these with your Hz project without having to copy files around.

The Workspace Panel displays files and subfolders of your current workspace and can assist with tasks of file creation, deletion, renaming and organization. You can drag files atop other panels within Hz to drop an asset reference onto a parameter or into your Code.

In order to maximize the portability of your projects across machines, it's best to refer to assets in a workspace-relative form. Again, the Workspace Panel and the Hz Runtime's Loader class come to your aid in producing and resolving relative asset references.

The Assets

Asset files come in a variety of types and represent the core of your project. The usual suspects for music production include:

• samples (.wav, .aiff)
• loops
• envelopes (.knt, .vitallfo)
• sound recordings for your tracks
• output / rendered productions
• MIDI files for note events (.mid)

Hz extends this set to include

• soundscape scripts (.js, .lua)
• songs.hz files for note and control events (.hz)
• extension metadata (.yaml)

Taking the asset-based idea to its extreme, each significant asset resides within its own file. For example, rather than burn several note sequences into a larger driver file (whether .js, .lua, etc.) storing these notes into its own separate file (.hz, .abc, .mid) will allow for more flexible mashups down the line. Moreover, assuming you organize your assets by subproject you'll be able to understand the constituents of your project simply by inspecting the workspace contents.

The Product

A product can be a lot of things:

• The final mix of your latest composition
• A performable .js file that combines input from the performer, OSC Events, Midi Events, HID Events, etc.
• A single stem for consumption by another DAW
• A Hz extension that you wish to ultimately share

In the context of Hz, the idea is to have a reproducible recipe that can be used to recreate a final product. Ideally the recipe is compact and concise. This allows you to tweak a final production recipe in small ways to achieve a predictable outcome with minimal cognitive overhead.

In Hz we accomplish this either by the .js or .lua driver file. These files have a number of references to external assets and represent the gluing agent that brings it all together.

Non Linear

Hz's workflows are decidedly non-linear in the sense that there is no single view that captures a serialization of all the events in your project. The composition paradigm of a linear-timeline is both easy-to-learn and very powerful but it has difficulty representing randomness and procedural / programmatic / performative composition elements. Since the pitch for Hz is programmability we've not made timelines central to the authoring experience.

But all is not bliss in the world of pure proceduralism. Somehow the composer must bend stochastic madness to their will and onto a composition. There are a number of tools and methods for doing so in Hz and these are explored elsewhere.

But before we leave this topic of non-linearity consider:

• You have have "any number" of .js, .lua, and .hz files open in a Hz session. Parameters can be changed, programs can be altered, fibers can be cleared and restarted.
  This opens a panorama of non-linear, nay, non-Euclidean possibilities.
• You can author re-useable scripts for single production tasks like recording voice or guitar or ensemble. Now, by simply changing the current visible tab you can switch activities.
• Similarly, by activating a recording script, you can render-to-audio the results of your current session thereby preserving it for posterity or inclusion into another context.

… Q.E.D …