re-routing a sub-suggestion from another thread. the original thread (here) contained multiple suggestions, one of which (the bypass-effect checkbox on minimized dsp fx) was actually implemented, for which i am very grateful. (on further inspection, the other two suggestions - changing the NNA for all samples in an instrument at once, and expanding the options for the drumkit-generator, have been made possible through lua-scripting, for which, also, a big thank you to the scripter(s))
one of the other suggestions i made there was to show the amount of steps in a pattern (64,128,etc) in the pattern matrix. i ran into this again today. so far i’ve been coping with this with naming my pattern-row in the matrix. however, feeling enthousiastic about seeing people’s mockups for suggestions, i decided to create my own mockup. here it is:
added idea (while creating the mockup) was to be able to change the steps in a pattern through the pattern matrix as well. to be honest, i am note sure whether this would be a nice addition. i’m sure someone can come up with an objection, so i’ll leave that up to the commenters :).
That should be an option yes, but I’d actually ability to have the length of the blocks sort of match the lenght of the actualy pattern (pattern block with 80 lines would be double the height of 40 lines pattern block etc.)
@martyfmelb: yes, that would be another way of implementing the same thing. when doing the mockup i figured it might be nice to allow you to change the patternsteps from the pattern matrix, but might be redundant as well. your version is better i guess. does not take up additional room either. nice one.
On hover, show a ‘v-resize’ cursor at the bottom edge of each pattern rectangle - And highlight the edge - And make it clear visually that the resize applies to the bottom of the pattern above, not the top of the pattern below
On drag, reduce the mouse-sensitivity’Ghost’ of larger pattern size visible over old (or old pattern gets partially ghosted out if you are shrinking it instead)
OR: instead of the above, just force a full redraw i.e. patterns below move up and down as you drag, no ghosting
Tooltip or in-place count of the number of rowsSnaps to increments of LPB * 4Option: you must hold Shift key to enable this function e.g. to prevent accidental pattern-length resizesHold down Alt key to increase snapping resolution to LPB * 1Hold down Ctrl key to force a “make pattern unique” operation
Show a small highlight-coloured ‘sparkle’ (connoting “new”) in the top-right of the rectangle to indicate this
I’m not sold.
What happens if you have a pattern with only 1 or two lines (I know, hardly a ‘pattern’, but still…)
Will you have a tiny little sliver sized Matrix cell?
rhowaldt’s number idea seems more practical in this regard.
well thank you. i still like martyfmelb’s idea better than my own, because it more visually apparent, and takes up less (horizontal) space.
aside from being flattering, dformd makes a good point indeed. if the resize-idea would be executed as proposed, tiny patterns would become almost imperceptible. one option would be to have a minimum-height and apply that to the smallest pattern always. this would work i think, but it would tone down martyfmelb’s detailed (my god, are you a GUI-designer or something?!) implementation of the idea, as the height of each pattern will be variable.
@rhowaldt: I’ve tried minimum height. Generally, it doesn’t even need to take effect until the pattern-data portion of a row is a mere 5 pixels tall. Shown below … and I found the perfect place to put the numeric pattern-lengths!
(Note that the very smallest patterns lose 1px top/bottom of padding, and a smaller font-size is required for the pattern IDs. This may or may not be acceptable.)
For editing super-tiny pattern lengths and lots of 'em, we do have a vertical zoom function already. If you zoom in enough, you get to edit your pattern matrix in as gruesomely microscopic detail as you wish.
If you want to close the gap between the heights of long and short patterns, we could use logarithmic-like sizing below a certain pixel threshold (i.e. below 20px pixels tall, the height reduces by e.g. only 25% each time you halve the pattern length. So if you quarter pattern length, you are still left with 56.25% visible height).
p.s. Funny you ask, but yes: I work as a graphic artist/UI designer/front-end developer.
@martyfmelb: yes, very nicely done. the smallest ones i think are too small. they get ugly, and i think using a smaller font is not such a great idea as i think it would get too small for some people. you are completely right about the zoom-option, that would make small patterns bigger for those who disagree on the smallest ones.
The numbers are perfect where you put them! the space is unused anyway.
well then, let’s wait until this gets implemented!
I’ll be the fly in the soup and point out that the Pattern Matrix is, well, a matrix.
It’s a simple design meant for block manipulation. Any extension should keep the spirit of “grid”. It’s not an arranger, or whatever else?
I imagine Renoise evolving with
The ability to play “blocks” independently of each other, i.e the concept of clips.
A separate arranger.
In this scenario. The matrix is a fancy grid controller (which already maps to hardware grid controllers) and these visual representations will go in the Arranger, which is something else.
does it really matter what it is meant to be or meant to do? in my opinion, it matters more what people are doing with it. it speaks for the Matrix that such a simple grid-thing can be used in other ways than it may have been originally intended for. the fact that it is apparently quite commonly used as an arranger (unless i do not understand correctly what you mean by ‘arranger’ - it’s to arrange the blocks that make up your song, right?) is a testimony to the success of its design, however simple, and whatever the intentions.
i find one of the things that makes Renoise so appealing the fact that it provides you with a set of tools, free for everyone to use in whichever way they see fit. i think that dblue for example has made use of some Renoise-features in very inventive ways, and for purposes that these features may not have originally been designed for.
i can understand if, from a developer point-of-view, there is a vision of what to do with the Pattern Matrix, and it may be so that we are fastforwarding into territory that does not fit with what is currently planned. however, if that is the case, it might be a good idea to revisit those plans, and discuss the possibility of using the Matrix for stuff it was not intended for.
warn me if i’m ‘out of my league’ here or something. i do not mean to insult people or whatever with the above. the comment by Conner_Bw just sounded a bit ‘conservative’ to my ears. correct me i’ve gotten the wrong idea.
Well, I’m just speculating, like everyone else. I don’t have any real insight.I just like the Pattern Matrix for what it is. And feel that the concept of an Arranger should be a separate thing. To be honest, I’m pretty sure some of the core Renoise developers will disagree with me.
I will point out, in the case of “Connecting the Novation Launchpad to turn the matrix into a sequencer isn’t exactly what was expected” the user did this, all by themselves. They didn’t request the feature, they just went ahead and did it.
i still like martyfmelb’s idea better than my own, because it more visually apparent, and takes up less (horizontal) space.
