No tags yet.
I now have a basic device that will allow the continuous generation of MIDI values for a preset chosen in Serum, based on the Markov chain visualised in the user interface. This seemed to be working for a little while but as I add important features, I am finding that the melodies become out of sync with the interface, and I am generally encountering problems. Up until this point, I have been using the [metro] object a lot to form a timing system within the device. This is used in a musical way (such as controlling the rate that notes are being produced) but also to represent a timing system in which the data is organized within.These objects together keep the algorithm flowing, and I have used them as partner objects ever since I began using Max/MSP. Little did I know that these have been causing all sorts of problems!
When using the [metro], the fastest it can possible 'bang' is once per millisecond. This may sound pretty fast, but when thousands of things are being triggered by these bangs, the time delay really starts to add up! I was reminded by my supervisor to make use of the [uzi] object. This object will send a specified number of bangs as fast as possible, which appears to be instantaneously. As soon as I applied this to my Markov interface, it fixed some major glitches. I was having problems where when the device was in playback mode and I chose a new probability matrix, the pitches reflected this change only after a short (but noticeable) delay. I'm sure that [uzi] is going to be an essential object in future patches!
[t] is another essential object in ensuring that all processes within my devices happen in the right order. In the past I would have bang messages hooked up to all sorts of different functions, and they would all be trigger at the same time. If the information being triggered was fairly sparse, then this wouldn't cause any noticeable problems. However, as the information being triggered became more complex and the number of functions rose, the event order began to get twisted. I would use [del] to delay a single bang by several different amounts of time to ensure that the bang was 'split' via time and thus triggered events in the correct order. This of course added an even larger delay, meaning some functions would take entire seconds to complete. [t] is of course the answer to this problem - it allows me to send input to many different places, ordering the outputs from right to left. When used in combination with [uzi], [counter] and [select] objects, I now have a system to ensure that all events in my devices are triggered as instantaneously as possible, in the correct order, in an organised manner which is accessible to understand.
I have now updated the Markov device with edits based on what I have been discussing in this post. Everything is now happening instantly and in the correct order, and appears logical and accessible as a patch. :)
send out a specified number of bangs as instan