Realm of the Practical

Brain storming is easy; I can make things up without being held accountable. However, I need to spend time in the realm of the practical. I won’t stop collecting ideas, but if Slipmat is going to be a reality, I need to know what the issues are. This means lots of research and lots of prototyping and lots of little scripts that test various facets of Python.

For example, creating a graph of Python 3 generators:

#!/usr/bin/env python3

import operator

ksmp = 8
foo = (i * 2 for i in range(ksmp))
foo = (i + 1 for i in foo)
bar = (11 for i in range(ksmp))
foo = map(operator.mul, foo, bar)

print(*foo)

This is interesting to me because the names foo and bar do not receive an array/collect/list of numbers. Instead, they point to generator objects. These generators are not evaluated until print(*foo) is called.

By the way, if my understand or terminology is ever off, please correct me. I’m also here to learn.

The KISS Principle

Keep it simple, stupid!

Wikipedia says, “The KISS principle states that simplicity should be a key goal in design, and that unnecessary complexity should be avoided.” I’m continually reminding myself of this as I move forward with Slipmat.

x Trigger Notation

In Roll You Own Syntax, I theorized how users could construct their own systems of notation using strings. I’ve constructed a working function, called trig(), to show how it’s done.

First, let’s see trig() in action. The following is complete conceptual prototype Slipmat program that generates a rock drum groove with 8th note hats:

#!/usr/bin/env slipmat

from JakeLib.Generators import trig
from EasyKit import hat, snare, kick
    
@trig('x.x. x.x. x.x. x.x.') hat()
@trig('.... x... .... x...') snare()
@trig('x... .... x... ....') kick()

This horizontal system for notating triggers, and others like it, can greatly improve the legibility of a piece, while catering to a composer’s preferred style of working. A composer quickly scans this and comprehends it without having to reconstruct it in their head from a list of individual events:

@0    hat()
@0    kick()
@0.5  hat()
@1    hat()
@1    snare()
@1.5  hat()
@2    hat()
@2    kick()
@2.5  hat()
@3    hat()
@3    snare()
@3.5  hat()

The form is lost in translation.

Building the function is pretty straight forward if you’re somewhat experienced with Python. I put together the following function definition, with docstrings, in roughly 15 minutes:

def trig(seq, res=0.25):
    '''
    Creates a numeric sequence from a string and returns a list.

    Description:
    A string trigger sequencer, where an 'x' creates a trigger, and a
    '.' creates a rest. All other glyphs are ignored. The resolution
    of triggers and rests are determined by the argument res.

    Input:
    seq -- A string containing a sequence of 'x' triggers and '.' rests
    res -- Resolution of note triggers and rests
        
    Output:
    return -- A numeric list
    '''    
    
    L = []  # The return list
    p = 0   # Position in sequence

    for c in seq:
        if c == 'x':
            L.append(p * res)
            p += 1            
        elif c == '.':
            p += 1

    return L

The trig() function accepts a string formatted in what I call ‘x trigger notation.’ The function parses the string and auto-generates a list of numbers representing trigger times. A trigger is denoted by an ‘x’, while a rest is a ‘.’. All other glyphs are ignored. I use a single space between beats for clarity. The default resolution is a 16th note, though trig() accepts an optional argument for changing the resolution, increasing its usefulness.

Import, Reuse, Remix

The best part about custom functions is that they can be reused multiple times in multiple programs by multiple people with the use of the import. No refactoring of code, no copy and paste, no reinventing of the wheel. Just import, reuse, remix.

Functions as Reusable Score Clips

I’m not a fan of the copy and paste method for composing computer music scores. I’d rather write something once, and reuse it as needed. Slipmat uses function definitions as one method for creating reusable score clips.

The following function rock_drums() stores a simple rock drum pattern with 8th note hats:

def rock_drums():
    @[0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5] hat()
    @[1, 3]                           snare()
    @[0, 2]                           kick()

Here, the rock_drum() clip is played 4 times:

@0  rock_drums()
@4  rock_drums()
@8  rock_drums()
@12 rock_drums()

Here are 16 bars using the range() shorthand method:

@range(0, 64, 4) rock_drums()

Using functions as clips can save time and keystrokes while greatly improving legibility. The easier your code is to read, the more likely others will remix your work. If they can’t make heads or tails out of it, they’re more likely to move on.

The Slipcue

The Slipcue (@) is the object responsible for the fourth dimension of a Slipmat program: time.

The name is derived from the term Slip-cueing, which Wikipedia defines as, “a turntable-based DJ technique that consists of holding a record still while the platter rotates underneath the slipmat and releasing it at the right moment.”

The Slipcue is formally known as the @ scheduler. There are various reasons for the name change. I’ve only shown the Slipcue as a simple mechanism for scheduling tasks, though it controls so much more:

  • Syncing other Slipmat processes, ticks, threads and shreds
  • Starting, Stoping, Pausing, fast forwarding, rewinding
  • The Master Clock (or Mistress Clock)
  • Task Management
  • Units of Time
  • Tempo
  • etc

Plus, “the Slipcue” rolls off the tongue rather well.

Custom Sequence List Generators

Python’s built-in range() list generator is full of possibilities when used in conjunction with Slipmat’s @ scheduler. And that’s just one generator out of, dare I say, a million possibilities.

Imagine being able to conveniently import generators from a massive user library of modules. This will be a reality for Slipmat for two reasons:

I built a list generator called range_plus(), which takes Python’s range() function a few steps farther. range() is limited to integers; range_plus() removes this restriction and allows for floats. range() supports a single increment step value; range_plus() additionally allows users to pass a list of increment step values that are chosen at random.

Here’s the working Python defintion for range_plus():

def range_plus(start, stop, random_steps=1):
    '''
    Returns a list of successive incremented values
    chosen randomly from a list.

    Input:
    start -- Starting value
    stop --  End point
    random_steps -- A list of incremental values chosen at random or a
        single numeric value
        
    Output:
    return -- A numeric list
    '''
    
    if stop < start:  # Avoid infinite loop from bad input
        return []

    if not isinstance(random_steps, list):
        random_steps = [random_steps]

    L = []

    while start < stop:
        L.append(start)
        start = start + random.choice(random_steps)

    return L

I made sure to write the docstrings, to make life easier for anyone who may import my code later. Here's a Python interpreter session to test out some numbers:

>>> from MyListGenerators import range_plus
>>> range_plus(0, 4, 0.5)
[0, 0.5, 1.0, 1.5, 2.0, 2.5, 3.0, 3.5]
>>> range_plus(0, 4, [0.25, 0.25, 0.5, 0.75])
[0, 0.5, 1.0, 1.5, 1.75, 2.5, 3.0, 3.25, 3.75]

As applied to music, range_plus() would be a perfect fit for randomly generating rhythmic patterns, for things such as hi-hats.

@0  @range_plus(0, 4, [0.25, 0.25, 0.5, 0.75]) hat()
@4  @range_plus(0, 4, [0.25, 0.25, 0.5, 0.75]) hat()
@12 @range_plus(0, 4, [0.25, 0.25, 0.5, 0.75]) hat()
@16 @range_plus(0, 4, [0.25, 0.25, 0.5, 0.75]) hat()

Here's is one scenario for what those patterns would look like in trigger notation:

Bar 1:  x.x. x.xx ..x. xx.x
Bar 2:  xx.. x..x ..x. .xx.
Bar 3:  x..x ..x. xx.x .x..
Bar 4:  x.x. .xxx .xxx x..x

The 'x' is a 16th note trigger, the '.' is a 16th note rest, and spaces are used to distinguish between each quarter note.

Auto-Generating Lists

In yesterday’s blog, Lists as Micro-Sequencers, we discussed writing lists instead of individual events. Today, we’ll generate lists instead of writing list values.

Python comes with the built-in range() function that generates and returns a list of integers, which can be used to schedule events. The following python interpreter session demos range() with three sets of args along with their respective outputs.

>>> range(4)
[0, 1, 2, 3]
>>> range(5, 9)
[5, 6, 7, 8]
>>> range(0, 16, 4)
[0, 4, 8, 12]

The range() function can be a huge saver of time and keystrokes. Especially if you’re composing goa trance:

@range(1024) goa_kick()

“The kicks are done, man.” Just to be absolutely clear, that generates 1024 goa_kick() events, one per beat.

Frogger

This is what happens when frogger doesn’t look both ways before crossing the street / pond:

gi_square ftgen 4, 0, 256, -7, 1, 128, 1, 0, -1, 128, -1

instr 1
    idur = p3
    iamp = p4
    
	kenv line 0.00230, idur, 0.01978
	a1 oscil iamp, 1 / kenv, gi_square
	out a1
endin
...
i 1 0 0.96493 -0.707

Download: dead_frogger.csd

Lists as Micro-Sequencers

On Friday, I listed nine ways in which python methodologies could be used with the @ scheduler. How would they work in a real-world musical context? Today, I’m showcasing the List as a super convenient micro-sequencer.

When the @ scheduler is given a list of numbers, every value in the list is used to schedule an event; This saves keystrokes and increases legibility. Let’s see this applied to a simple four-beat rock groove with 8th note hats:

@[0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5] hat()
@[1, 3]                           snare()
@[0, 2]                           kick()

That plays hat() eight times, and snare() and kick() twice each. This beats having to type out 12 events.

Alternatively, an identifier can point to a predefined list, thus, a sequence can be reused multiple times. The following stores a complex hi-hat pattern in identifier p, and then plays it four times:

p = [0, 0.5, 1, 1.5, 2, 2.25, 2.5, 2.75, 3, 3.75]

@0  @p hat()
@4  @p hat()
@8  @p hat()
@12 @p hat()

Here’s the shorthand equivalent:

p = [0, 0.5, 1, 1.5, 2, 2.25, 2.5, 2.75, 3, 3.75]

@[0, 4, 8, 12] @p hat()

That’s 40 events in two lines of code, with improved legibility. If this was presented as 40 individual events, it would not be obvious that the same hat pattern is repeated four times.

Banks of Patterns

A list can be utilized as a bank of patterns, a list of lists. In the following example, an empty bank is created, filled with three patterns, and then used in a four measure sequence.

b = []
b.append([0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5])               # x.x. x.x. x.x. x.x.
b.append([0, 0.5, 1, 1.5, 2, 2.25, 2.5, 2.75, 3, 3.75])  # x.x. x.x. xxxx x..x
b.append([0, 0.5, 1, 1.5, 2, 2.5, 2.75, 3, 3.5, 3.75])   # x.x. x.x. x.xx x.xx

@0  @b[0] hat()
@4  @b[1] hat()
@8  @b[0] hat()
@12 @b[2] hat()

Bonus Round — Eight Ways to Notate 8th Note Hats

Some good, some bad, some ugly. All produce the same result.

1. @map(lambda x: x / 2.0, range(0, 8)) hat()
2. @[0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5] hat()
3. @[i / 2.0 for i in range(0, 8)] hat()
4. @[i / 2.0 for i in range(8)] hat()
5. @[0, 2] @[0, 1] @[0, 0.5] hat()
6. @[0, 1, 2, 3] @[0, 0.5] hat()
7. @range(0, 4) @[0, 0.5] hat()
8. @range(4) @[0, 0.5] hat()

Examples 2, 6 and 8 are my personal favorites.