/ Topics / Workflows

Asset-Based

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

Nerd Alert:

A product is constructed by combining a number of separate assets of different types. The job of one asset class is to characterize relationships between other assets and can thus represent the process to produce a final result.

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

The Workspace

The workspace is the folder where assets reside. A Fiddle session operates relative to a single active workspace and you can change this at any time. The default workspace is ~/Documents/Fiddle 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 Fiddle 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 Fiddle 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 Fiddle Runtime's Workspace Class come to your aid in producing and resolving relative asset references.

The Assets

Assets 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
• sound recordings for your tracks
• output / rendered productions
• midi files for note events (.mid)

Fiddle extends this set to include

• Fiddle's ChucK-node-graph files (.chg)
• Fiddle's Note-Grid and Session-Grid files (.fgrd)
• ABC files for note and control events (.abc)
• ChucK programs (.ck)
• 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 .chg, .als, .logic, etc.) storing these notes into its own separate file (.fgrd, .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 .chg file that combines input from the performer, OSC Events, Midi Events, HID Events, etc.
• A single stem for consumption by another DAW
• A Fiddle extension that you wish to ultimately share

In the context of Fiddle, 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 Fiddle we accomplish this either by the .chg graph file. Or by a driver-style .ck file. These files have a number of references to external assets and represent the gluing agent that brings it all together.

Non Linear

Fiddle'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 Fiddle + ChucK is programmability we've not made timelines central to the authoring experience. That said, note or event grids can be an important asset in your compositions and the Grid Editor is tuned to creating and editing them.

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 Fiddle and these are explored elsewhere. In addition, the Session Grid node can serve as a big-picture-manager for compositions.

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

• You have have "any number" of .chg, .fgrd, .abc and .ck files open in a Fiddle session. Parameters can be changed, programs can be altered, shreds can be cleared and restarted.
  This opens a panorama of non-linear, nay, non-Euclidean possibilities.
• You can author re-useable graphs 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 simply activating a recording node, you can render-to-audio the results of your current session thereby preserving it for posterity or inclusion into another context.

… Q.E.D …