process: sequencer environment design experimentation, Autotel


process: sequencer environment design experimentation

16_8 step sequencer

I am designing a environment to make sequencer systems, based on the licog composer, but with the intention to allow the user to design any kind musical pattern making system. I have been working on the building blocks of this environment : what is the set of components that would allow the user to make the widest possible gamut of pattern making tools.

There are many decisions to be taken for component within this environment, regarding the communication and functioning protocol, that I realized that was crucial for getting a healthy base for any future developments. If there is anything whimsical on the way that this device is trigger, or about what this device outputs, then in future developments I would need to make compromises either in the functionality of these devices, or in the compatibility that these devices would have with the older ones. A good illustration, as always, is the Lego building block. By good luck or by a good decision, lego has been able to keep innovating and creating new pieces, allowing the user to build a very wide range of things, while still keeping compatibility with their earliest pieces. All this was dependent on that very first design of the mechanical joint that the first Lego block had. I personally find that the not so positive example is little bits. Little bits, I think that was a nice opportunity that got spoiled because of a poor definition of the communication between modules; because each module is orthogonal, and the physical shape of the first little bits was mostly designed for one input- one output pieces, now they face the following two problems: a) there are many components and systems that cannot be done, and b) some implementations of the environment have to break some rules. An example of the point a, is that despite all the enthusiasm around littleBits, in my opinion, there has not been really interesting toys made out of this. In general having a set of littleBits allow a very limited range of things that can be built. Playing with littleBits remain within the spectrum of making ‘hello worlds’ over and over. The for the case of Korg little bits, the spectrum of possible synths to be built is so narrow, that I can’t see how can any synth could be built that doesn’t already exist. An example of the point b is that in little bits Korg, the filter module needed an additional input than that single input that the environment seemed to specify, and it ended up having a lateral plug to allow that additional input.

IMG_20170503_131730While making a environment , it is impossible to define a correct interface between the system elements because usually it is unknown what the future elements are going to be. A possible approach to solve this, that I have taken, is to explode the current units of my system, into units that could build the units of my environment . Within the current context of actually making the building blocks to make pattern-making systems, this means that I am either defining the sub-components of the component in order to define the components in a way that will ensure that any other future component is compatible, assuming that it will be possible to build these still unknown components from the same sub-components than the components that are currently being designed.

For every current component in my digital prototype, that was built in JavaScript, I started exploring what are the processes that happen inside, and trying to adapt these processes in such a way that they can be also applied to the other components. What I was looking for, is to have the minimum possible amount of different components that would allow building the maximum of my current components.In this way, I discovered a cycle. From a set of desired components for the system, one can perform this cycle, and discover what are the sub components that allows us to build the current component, and potentially build many other future components that are currently unknown.


These components, however, could have properties that can change how the object behaves. In this way, the process can be cheated in a way that we end up with a single component that has so many configuration options, that it can cover any functionality. Perhaps for some system designs this could be handy, but as I am targeting the design of physical units, I put a limit to myself where each object should have the simplest parameter tweaking interface possible, and the script that defines it’s behaviour should be simple, and as monolithic as possible (avoiding too many switch statements).

After working on this process, I ended up defining a message as being a 3 byte message, that makes it midi friendly but also has an optional header for n-length messages, and four modules to process these messages.

messages details (are very prone to redefinition):

The first image on this post shows how a 16 step sequencer can be made out of these components. A licog round-robin can be made on the same principle. Licogs are also easy to implement with these modules, as one can trigger a sound upon bang, store it in fifo until next clock, and send all messages in fifo on every clock to the next Licog. This distribution of parts satisfactorily covers the domain of sequencers and licog composer, but it still needs more testing regarding the domain of note offs and control messages.

I speculate three potential interesting products out of this environment:

Tags: ,

Leave a Reply