Generative music feature ideas

MIDIbox SEQ
1

http://discourse.midibox.org/t/topic/18560

 

On the SEQ, the algorithm conceivably could control many more drums than the Grids module can control.  This could also be very interesting combined with some random/robotizer-type features.

 

I haven’t worked this out 100% yet, so suggestions are welcome.

For experimental purposes I may implement a basic version of this in the FX menu, just because I understand how that menu area works pretty well now, and we could make it into a track type later if TK likes it.

CELLULAR AUTOMATA CONTROLLED GENERATIVE TRACK TYPES
This idea is still a work in progress, but I think there are some interesting possibilities with using Cellular Automata for generating changing patterns that aren’t quite “random”, but have recurring features without being repetitive. They’re pretty simple to generate, and a track type that generated a new iteration of one or more cellular automata with every step would probably not consume too many resources. Those automata could be used as sources of bits to produce music in a variety of ways…

I’ve attached a simple python script (rename it to [sOMETHING].py) that visualizes a 64 bit wide strip of one-dimensional cellular automata data. It uses the three neighbouring “bits” above each bit to determine the state of that bit, and for the leftmost and rightmost bits it loops around to the other side of the strip to get the third “neighbour”. If you look at the code, there are several rules in there - just move the one you want to see to the bottom of the rules section. Or make your own (most rules create fairly boring results, but of the 256 possible rules in the script, there are many that go on forever and are interesting).

Here’s the output of one rule:

 

O OO O O OO OOO OO OO OOOOOO OOOOOOOO O OOO O O OO  
O OOO O OO O O OO OOOO OOOOOO OOOO O O OO O O
  OOO O O OOO O OOOOO OO OO OO OOOO O OO OO OO O OO 
OO O O OO O OOO OOO OOO O OO OO O OOOO    
   O OO OO O O O O OOOO O OOO OOO O OOOO OOOOO OO OOO
 OOO OOO O O OO O O OO O O O O OOO OO OO OOO O O 
O O OOO O OOO O O O OO O O OOO O O OO O OOOOO O 
O O O O O O O O OOOO O OOO O O O O O OOOOOOO O O OOO O 
O O O O OO O O OO OO O O OOO O OO OO O OOOOO OOO O O OO 
O O O O O O O OO OO O O O O O OOO O O O OO O   
O O O O OOOO O OOOO OO O O OO OOOOOOO O O OO O OO O OO
  O O O OO O OO OOOOOO O OOOOO O OO O O OOOO O
 OO O O O OO O OOOO OOOO O OOOO OOO OO O OOO OOO OO OO
    O O O OO O OO OO OO OO OO O O OOOO O O O  
OOOOO O O OOO OO O O OOO OO OO OO OO OOO OOOOO O
OOOO O O OOO O OOOOOO OOO OOO OO O O O OOO   
 OO OO O O O O OOOO OO O O O OOOOOOOOOOO OOOO OO O OO
    O O OO OO O OO O O OOO OOOOO OOOOOOOOO OO O O  
OOOOO OOO O O OO OOO O OOO O OOOOOOO OO OOOOO O O
OOOO O OOOOOOO O OO O OO OO O OO OOOOO O OO OOO O  
 OO OOO O OOOOO O OOOO O O O O OOO OO OO O OO O
    O O O OOO OO OOO OO O OOOOOO O OOO O O OOOO O O
 OOOO O OO O O O O OO OOOO O O OO OO OOOOO OO O OOO
  OO O O O OO OOOO OOOO O OO OO OO O OOO OO O 
OO OO OOOO O OO OO OOO O O OOOOOO O OOOO OO 
   OO OO O OOOO OO O O OOOO OOOOOO OOOO O O OO OO   
OOO OOO OO OO OO OOO O O OO OOOO O OO OO O O OO
OO OO O OO O O OO O O O OO OO OO O O OOOO OO O
O O O O OOO OOO OO O OO O OOO O OOOO OOO OO      
O OO OOO O OO O O OOO O O OOOOOO OO OO O O OOOOO
      O O O OOO OOOO O OOOO OO O OOOO OOO OO OO OOOO
 OOOOOO OO OOOO O OO O O OO O OO OOOOOOO O OO 
O OOOO OO OO OO OO O OOOOO O O OOOOO O OOOOOOOO   
O OO OOOOO O OO O OOO OOO O OOO OOO OO OOOOOO OO
  O O OOO OOO OOOOO OOO O O OO O O O O O OOOO O O
 OO OOO O O O OOO OO O OO OOO O OO OO O OO OOO OO OO O
     O OO OO O OO O O O O O O OO O O O O O
 OOOOO O O O OO OOO O OOOO OO OOOOOO OOOOO OO OOO OOO

 

Bits in a one-dimensional cellular automaton have only two states, but it’s possible for each “bit” to have many states in higher-dimensional cellular automata… It’s pretty easy for each “bit” to have many possible states - certainly easy to create a set of rules that would generate 128-state “bits” that could be used directly as MIDI data (or you could just pull 7 bits from some offset in a one-dimensional automata). Morphing two automata together could be interesting as well.

Using the same “rules” approach, but checking against already existing data on the SEQ instead of checking the previous iteration of an automaton to generate new states could create some interesting dependencies, too. (like checking notes in the note stack, and applying rules to that data to generate dependent new data)

These tracks could have “profiles” composed of a set of rules that would determine how the cellular automata data is processed into MIDI signals, and would make the output more “musical” in different ways, with configurable parameters.  Many different profiles could be developed for different types of track behaviour, even with different UIs and parameters.  The user could select different profiles to get the tracks to behave in different ways.  Or the automata could be used to automate changes to trigger layers like roll or repeat. There are a lot of possibilities.

 

I’m not sure if these CA based track types would use a 16 step editor like the other track types do, and have separate configuration menus, or if the edit screen for these CA track types should just show the configuration parameters.  Using a step editor as well as config menus could allow some neat automation of the CA parameters, but it might make things too complex.

There are lots of other types of cellular automata that could be used. Conway’s Game of Life is one that could conceivably be interesting implemented on the BLM, for example.

…I have a lot of experimenting to do to really flesh out this idea before I have any solid ideas on how it should be implemented (and there are probably several different implementations that would be useful), but I’d be interested to hear any comments or suggestions. There are other CA based sequencers out there, if you know of any particularly good implementations, let me know.

…and I’ll set up a new branch of the code in the svn playground when I start experimenting with this stuff, since I don’t want to break anything.

[auto.py.txt](< base_url >/applications/core/interface/file/attachment.php?id=11850)

2

The MI grids implementation sounds amazing. I’ve considered picking up that module many times. It would be nice to be able to tweak the three main parameters (x, y, density) using three separate encoders on the same screen. Perhaps that’s easier to do if the functionality is implemented as an FX rather than as a track type. I wonder if the midi data generated by the FX could be stored to the track for later copying or manipulation. 

3

However the Grids thing is implemented, I’d definitely have a config screen with editing of x-y position and densities.  I’ve been thinking about building a recording function into the robotizer FX, so that you could use the robotizer to automatically extend one measure patterns to fill a track with variants of that first measure, or copy (evolve?) a pattern over to another pattern slot with variations…  Implementing the same sort of thing for the Grids thing would also make sense.

 

I think recording of the robotizer is probably already possible via the UTIL -> RECORD function with a loopback, but I haven’t tried it.  It would be nice if the RECORD function could record from output ports as well as input ports…

4

It would be great to have a Grids like track type implemented in the SEQ.

I built a Anushri over the weekend and really like generative drum sequencer feature. Being able to use something similar with any midi device would be very powerful especially if it could be controlled with the BLM.

5

Both the Anushri that had the inchoate version of the generative drums idea and Grids are amazing :slight_smile: It would be very nice to have those ported over and available for MIDI output and recording. Really looking forward to see those in my MBseq. Actually I’d like all my gear to have it, but if the sequencer does it’s more than good enough.

6

I would love to see this happen!

7

Has any progress been made on these suggestions, in periticular implementing the Mutable Instruments Grids algorithm? 

 

I’ve recently bought a MI Grids and I think it would be an amazing addition to the MBSEQ. Being able to use Grids functionality over MIDI would be really useful. 

Anyway, I just hope that these proposals are still being worked on 

8

A neat trick for generating good pseudorandom patterns is to use the cadences of speech.

I automated this by taking the text of Alice In Wonderland, passed it through a text-to-speech engine to extract the phonemes and timing information, and then classified the results to get a beat pattern. The following web page contains preprocessed data, and grabs a random 16 beat chunk of the result - voiced on the top line, voiceless on the bottom:

http://www.bismuth83.co.uk/~lisa/madhat.html

 

1 Like
9

A neat trick for generating good pseudorandom patterns is to use the cadences of speech.

I automated this by taking the text of Alice In Wonderland, passed it through a text-to-speech engine to extract the phonemes and timing information, and then classified the results to get a beat pattern. The following web page contains preprocessed data, and grabs a random 16 beat chunk of the result - voiced on the top line, voiceless on the bottom:

very cool idea…to get some main beat grid for fitting lyrics (e.g. Hip hop)