custom step sequencer UI
I'm in the beginning stages of coding an elaborate step sequencer, but I'm having a little bit of a problem that I can't quite find the source of. Right now I'm just getting the UI logic worked out, and I'm using LCD and a coll to create the pattern grid. The issue is with the method by which I store the values of each grid section. Any time I release the mouse button and then click on another section, it will invert the last section that was toggled again, but without painting it. I can drag my mouse across multiple sections and they will all update fine however. Also, sometimes while dragging across multiple sections, a seemingly random button will be inadvertently inverted a second time, updating both the coll and the UI. a second click will re-enable it just fine, but in accordance with problem #1, whatever the last value was before that gets inverted a second time.
I apologize if what I'm trying to say is hard to understand, I don't know any other way to put it though.
By the way, I briefly use Peter Elsea's Lobjects, so if you don't have them, you should. It's a wonderful library. If you just don't want to though, you can probably just figure out what's going on by looking at it, none of them are very essential to the core functionality.
Is there a particular reason you're using [lcd] and not [matrixctrl]? It has it's logic already set up and you can simply load in an image file for it to use. If you want to change the number of columns or rowns while maintaining the size of the object you can do that with scripting.
lh
matrixctrl doesn't offer the flexibility that I want to add later on, like velocity, gate-linking, and pitch control. Thanks for giving me the heads-up though, I'm glad to know that the graphics of matrixctrl could be replaced.
Ah I see. In fact you can store something like velocity with [matrixctrl], you can give it 127 states and use for example an image that changes colour to display the current value. It isn't the most flexible if you want advanced control though.
lh
try using deferlow instead of delay 50-- that seemed to make it a little more reliable for me.
T
Bryan Dodson wrote on Fri, 13 March 2009 04:28matrixctrl doesn't offer the flexibility that I want to add later on, like velocity, gate-linking, and pitch control. Thanks for giving me the heads-up though, I'm glad to know that the graphics of matrixctrl could be replaced.
How about two matrixctrl objects, one on top of the other, where you can use one for placement and velocity, the other for pitch etc? Using [modifiers] you could have the second one come to the top when you hold Shift, for example. (change placement or layering of objects with [thispatcher] as in the example below.) Lots of possibilities with multi-state cells, though it can be cumbersome to click through many states without shortcuts.
Did you know that you can use [pattr] with matrixctrl? So you can save presets and interpolate smoothly between them, including the range of state values, morph between different settings easily which gives a whole spectrum of possible states that are generated automatically, it's great.
You could also use a jit.matrix, similar logic to the [lcd] method you're using, to paint your cells (though they can't have the borders, maybe overlay a grid on top for this--like a mostly-transparent fpic, with Ignore Click so you can click through it). The great advantage is that you can use jit.op or other video effects on your sequence, which will alter your patterns in interesting ways. For example, using jit.brcosa's Contrast, you might get some neat new possibilities between adjacent cells; jit.op * will let you scale the whole thing; and jit.xfade would let you crossfade between two saved configurations. Tons of generative ideas possible there without laborious clicking, and there's no end of image or video files as "seeds" for your patterns. Probably many will seem like random noise, but certainly not all, and you'll find certain kinds of images will be quite useful. Then you could make a whole series of images which give good results when transformed into the step sequencer, and have them loadable in your patch. plus it might be cool to see the images or videos that are generating the patterns.
You could also use [matrixctrl] and have the states saved in a jit.matrix as described, use the matrix operations as you want, then update back into the matrixctrl. This way you can take advantage of the matrixctrl UI which takes care of most of the legwork.
Some other ideas in the patch below, which could be used regardless of what route you take. Have a look, they've been helpful to me in the past with similar projects.
I have repurposed [matrixctrl] in this way. My riddumbank patch is only concerned with creating a pulse-based control signal. Pitch and veloity are handled further down the signal chain for me. It's a central element in my performance patch now. Here's a picture...
I use a series of custom graphics with [matrixctrl] to achieve the interface you see. Hooking it into [pattr] makes presets a breeze.
My custom graphics are attached in a zip file. There is an issue in Max 5 with the saving some of the [matrixctrl] attributes for image masks, so if you use them you'll need to [loadbang] a message saying "imagemask 1, autosize 1".
Even though I don't use Eric Lyon's wonderful collection, this little bad boy is sample accurate. If you've seen the Greequaincer plug-in I did for Hipno, this is the continuation of ideas that started their. I hope to release it to the community soon, but I need to put a little more time into the docs first.
--Nathan
I really don't want to use matrixctrl, at this point its probably just stubbornness... but I just want some help figuring out where the flaw in my logic is.
and Terry - the [deferlow] actually made it a bit less stable for me. the [delay 50] just gives it a little bit of time before it clears the [zl change] to make sure the same section can be enabled and re-enabled repeatedly.
Ok I think I figured it out. Altered /added objects in red.
main problem was message order (used swap to fix) and list being sent on both mouse down and mouse up (used [gate] to send only on mouse down). also the not object was unreliable (dont know why (i use lobjects too) ) so used [== 0] instead.
ah, perfect! thank you very much.