An experimental GTK2 JACK MIDI sequencer/arpeggiator
BoxySeq is an experimental JACK MIDI application whose functionality lies somewhere between sequencer and arpeggiator but can't be said to be either. It operates using a customized bin-packing-like algorithm based upon the behaviour of the Fluxbox window manager.
That is MIDI notes are an outcome of various processes interacting. What is usually being worked with is an 'event' whose final form is yet to be established.
Boxyseq represents all possible pitch and velocity combinations in a two dimensional grid - 'the grid'. The grid represents pitch horizontally and velocity vertically, with low to high pitch mapped from left to right, and low to high velocities mapped from top to bottom.
Within the grid, event boundaries can be positioned which define an area where events will be placed. When an event is placed there is never any spatial overlap. That boundaries may overlap each other does not enable spatial overlap between two or more events. Each boundary has it's own placement options which determine the manner and direction of the search for an area of empty space.
An event therefor requires dimension so that the search routine can identify an area where the event will fit into. Events originate in a pattern (ie a sequence of events) and each event can have a specifically defined dimension or the pattern can assign a random dimension to each event as it plays.
Boxyseq is not ready for end users nor will it be for some time. Manipulation of boundary position, size, play/mute/ignore status, and search options (via keyboard shortcuts) are implemented but boundary creation and deletion is not. Other working features within the engine are not accessible within the GUI. The creation of patterns and boundaries and MIDI ports must be hard coded but this should be fairly straight forward for someone with basic C knowledge. Boxyseq source code is only available from github.
Development began around the Summer of 2010 and stopped later that year in September due to finding it too challenging for my skills at the time. In mid January 2012 I picked up development again with a greater determination to fix those problems which had seemed insurmountable in the past.
The most pertinent problem was the free space search algorithm not operating correctly. Events often protruded out of the boundary that was meant to contain them. Several tests were implemented to highlight any bugs in the placement and thorough scrutiny of the code eventually revealed the problems. The other problem was the event handling routines made certain false assumptions about the ordering of events within each processing cycle (problems which are too subtle and intricate to easily sum up - see the ChangeLog file).
All of the audio presented in Audio 2010 was produced using Boxyseq. In particular, a screenshot can be seen on (invisibility) boxyseq_grasshopper.*g. Additionally, notes I made during development were published in the Journal but might be more readily found by using the BoxySeq keyword.
DISCLAIMER: The opinions and attitudes of James W. Morris as expressed here in the past may or may not accurately reflect the opinions and attitudes of James W. Morris at present, moreover, they may never have.
this page last updated:29th April 2013 jwm-art.net (C) 2003 - 2017 James W. Morris