jtauber / sebastian

symbolic music analysis and composition library in Python

James K. Tauber

Python and Web developer using linguistics, data science, and open source software to help people better understand languages, texts, and music.

Main Projects

• https://scaife-viewer.org
• https://greek-learner-texts.org
• https://digitaltolkien.com

plus many Python packages for text processing, text analysis, and more!

Educational Background

• General Linguistics
• Corpus Linguistics
• Classical Greek
• Educational Research
• Teaching in Higher Education
• Germanic Philology
• Music Theory and Composition
• Data Science

sebastian's Issues

ensure that `pitch` is used by transforms not `midi_pitch`

except obviously the midi_pitch transform itself

but pitch and octave should be the properties that are manipulated by most transforms

transforms shouldn't assume OSeq only

make transforms like reverse (and others) work with HSeq, etc.

control over instruments in MIDI output

at present, there's no way to control the instruments used in MIDI output.

NOTE: this may best be implemented once the notion of a "head point" is done

make transform writing easier with a decorator

a certain class of transforms (the majority) has the pattern:

def my_transform():
    def _(point):
        ...
        return point
    return lambda seq: seq.map_points(_)

this should be extracted out as a decorator so we can just write:

@transform_sequence
def my_transform(point):
    ....
    return point

(or some alternative name for transform_sequence)

implement diatonic inverter

should pivot around the first point in the given sequence rather than take an arg

make Python3 compatible

transform for extracting segments of a sequence

e.g. seq | extract(64, 384) where number are OFFSET_64s

move over to using a test framework

Sebastian has decent test coverage but it's home grown.

We should move the tests/* (and the if name == "main" tests) to a test framework.

prototype lilypond output

We can read/write MIDI but only read lilypond.

We want to be able to output lilypond files.

implement transform to factor out key

give key and sequence with pitches annotate the points with degree

SeqBase __repr__

should the __repr__ for SeqBase just return self._elements

advantage is print seq will give a nice representation but is it misleading for it to look like a list when it's really a Seq?

A compromise may be <HSeq [a, b, c, ...]> although that's not quite as nice to read.

support points without pitches in lilypond output

at the moment lilypond output can only display sequences if the points have pitches.

add support for display of rhythms where point is underspecified for pitch

anacrusis as negative offset

If you do A = B + C at the moment and B has an integral number of measures and C has an anacrusis, the beat alignment will be off.

Work out how to solve this

(Three Blind Mice could be simplified by this and could be used as a use case)

better use of MIDI input

While Sebastian has a library for parsing MIDI files, it isn't yet hooked up to the core of Sebastian.

implement nested sequences

integrate into IPython Notebook

Add transform for dynamics application

Adding a transform: dynamics(from, to=None)

ability to translate `midi_pitch` to `pitch`+`octave`

given a hint of key we can choose the enharmonic alternative (at least if diatonic)

eventually we can take harmonic context into account

if no key or key not enough to decide (i.e. not diatonic) always favour sharps (just as an arbitrary convention)

Using Ligatures

Hi,

How sebastian deals with Ligatures?

Cheers,
Arnaldo.

support velocity in write midi

at the moment write midi just hardcodes the velocity.

we could use a velocity property on the point if it exists

lilypond output doesn't support VSeq

e.g.

VSeq(Point(pitch=n) for n in [-2, 2, -1]) | add({"octave": 5, "duration_64": 16})

is not rendered any differently than the same HSeq

implement head points

lilypond parse should produce `pitch`+`octave` not `midi_pitch`