My gosh it’s been forever. It’s already late 2021 (this COVID pandemic has just made the years FLY!) and over a year since any major changes in any part of CHIMIRA! Since I last posted in May 2020, I’ve taken a look at some hardware changes and upgrades mentioned in that post and recorded a graphic score interpretation using CHIMIRA with a Guzheng (Chinese zither), but no software changes!
I’ve decided it’s time to add a more polished step sequencer #module for CHIMIRA. Now that I have separated just the colour-tracking portion of CHIMIRA into TRACI, the missing component is the application of that incoming data. Hence… sound module patches!
After a good review of TRACI (thank goodness I added an info patch and tooltips! #codeforyourfutureself) I’ve been doing some planning for a step sequencer module. I have three main sets of data from my stored coll_data set to map and manipulate:
the colour of an object
the grid_x value (type: integer in range 0, 16) – pretty sure I want x values to be the “steps” of musical time. I suppose this could be variable and be based on pattern lengths for interesting rhythmic looping results. This would mean that each row is read separately though. For now, I’m going to just attempt steps of equal length for simplicity which means at any given point in time, my step sequencer will be reading at the same grid_x value across all rows – whatever a row represents.
the grid_y value (type: integer in range 0, 12)
(Side note: I also have a coll_rgb data set with each tracked colours’ rgb values, but for now, it might be not as effective of a relationship visually to use for this application so far. I’ve also decided to keep my current 16 x 12 grid format, but of course for larger projects this can be expanded to be a different shape or with smaller grid/location sensitivity!)
When the objects are set and left alone, depending how the sounds are related to the colours and their positions, it’s possible this can be quite predictable with repeated loops (like usual step sequencers!). I like having this simplicity especially to introduce the concept and make the experience more accessible to those who aren’t necessarily familiar with step sequencers or other sound-art-related topics. So, I definitely want at least the function of a simple step sequencer with 1-to-1 object-to-sound correlations.
However… wouldn’t it be neat to mess with that? For something like an installation where it’s possible colours don’t EVER move, and to still create interesting sounds despite repetition and looping while reading the step sequencer? Perhaps instead of playing a single sample/sound file, a colour could represent a library of sounds, or a family or instrument types. The variability and addition of randomized selection could lead to interesting #generative musical results!
Some other sound parameters for each step could include:
velocity of MIDI/volume of samples
pitch
In terms of aesthetics and UX design…
I imagine part of this step sequencer would have a display similar to the step grid in Logic Pro’s step sequencer:
For the step grid display: I think the [matrixctrl] object display should definitely display their cells’ “on state” with the colours that are tracked. I found this Max forum from 2012 on how to do that and would like to incorporate it!
Some general functions/controls I want to have include:
on/off switch,
play/pause/stop buttons,
an option/mode to play through the step sequencer a pre-determined # of times only (should this be complete play-throughs only? Maybe it’d be interesting to stop it part-way before stopping?)
tempo control (bpm) (would this be a set-and-forget setting? It might be interesting to add a method of for changing tempo for rit. and accel.-type uses. If I want gradual tempo changes (vs. abrupt), I’d need inputs to specify the end tempo value and the duration in which to get there).
As the grid_x values are accounted for steps/duration, I still have colours and grid_y values to play with! I don’t really know what’s more appropriate to map to which values. Let’s go through some possibilities!
For example, if I wanted to make use of libraries of samples
the option that a colour is a percussion instrument for drumkit sounds
the option that a colour is a pitched instrument of randomly generated pitches (e.g. a piano, xylophone…) – perhaps limited or weighted with notes belonging to a certain scale/key to have more musical results (vs. jumbled random unrelated notes – but this could be interesting too?)
the option that a colour is a category of samples (e.g. different bird songs, bell samples, vocalizations… )
What might be neat too, is to have all of the above options as potential “modes” for the colours to sound, and for each colour, simply select the desired mode and provide the necessary specifications for that mode (e.g. what folder of sample files to play from). An idea that just came to me, is to also map a colour to some of the above general functions/controls too! I.e. a coloured object could also control tempo!
I’m also growing towards the idea of using the vertical grid_y data to be correlated with the volume. In a single column, it would mean the top-most coloured object correlates with the loudest heard sound in that moment, and vice versa. I might need to test it and ask a few outside opinions to know how obvious this seems, but it might be an intuitive mapping like a fader on a mixer. We shall see!