the little infinity symbol which shows that a track segment is the same as in the last pattern is very cool… but also kinda limited, since it doesn’t work when you for example keep alternating between two track segments.
(* represents that symbol)
A B B* B* = yay
A B A B A A* A* = aww!
I have no idea if this is actually feasible, but what if each track segment had a checksum? then you could number those checksums in order of appearance and display them instead of the infinity symbol. the above examples would turn into
noticed this limitation as well. some type of solution would be to give unique patterns (per track) a different color (or darkness/lightness). otherwise, there’s no practical way to distinguish slots in a pattern (trying to guess which is which by examining the mini images in each slot is unreasonable)
Actually I was going to append that suggestion to my first post, but then I thought this could be very annoying? Okay, I was actually thinking about the same segments lighting up when hovering the mouse over them… just lighting them up when they’re actually selected might be good though.
Well, the colours are being gradient across the PM the more you repeat it.
Just pick a track and duplicate it across more patterns an notice the gradient getting darker.
It however indeed does not work once the repeating pattern is getting interrupted by a change.
Using the same principle with the colors when patterns get interrupted will make things only more confusing instead of help.
Johann’s checksum idea will allow you to get this distinction a lot better.
There was a feeling of something looking at the PM, I just didn’t have the words for it yet.
If nothing can be done about it, at least the issue is on “paper level”. By that I mean one could always write it down on paper to keep track of where the variations are vs. where the duplicates are, though I do hope something can be done about it…
Aside from how to visualize it (= can of worms ) I really wonder if it’s even feasible, that is, if a track segment can readily be serialized and turned into a checksum? And also how long that would take, and when to do it (certainly not every time a note is entered or a value changed… in the background when there is no input might work, something like that).
Although: whatever “arranger” means, it likely would mean something like “reusing stuff in several places”, right? So this might be wasted effort… but if it would be easy to do and not totally kill Renoise on slow computers, it could be a good step in between perhaps.
(btw: I keep calling a box in the pattern matrix “track segments” because I don’t know how else to call it. Is there an official term? If not, one should be made up!)
Buzz already has a Sequence Editor that works perfectly - just use numbers (which you can rename to whatever you like, if you don’t like using numbers) to represent each pattern.
Renoise’s pattern matrix is a triumph of form over function. It looks very pretty, but simple numbers are much better than trying to graphically represent the pattern in any way.
Using numbers presumably means that none of the problems listed above apply.
Totally agree (again). Except, why not use numbers AND mini-representations of patterns (numbers overlaid)? The Pattern Matrix already is a huge step in the right direction. But it’s just not completely what it needs to be.
First of all, what is really needed, is a certain change in the structure. Patterns are monolithic now. They need to not contain notes directly, but a set of references to subpattern items which contain the notes. These subpattern items represent what now is the content of a particular track in a pattern (let’s call them tracklets). The Sequence Editor / Pattern Matrix would then basically be a superpattern editor which scores tracklets instead of notes.
The whole Pattern Matrix concept would make much more sense this way. It could be completely backward compatible and everyone who wants to keep the old work flow can just keep it.
It would be almost like in Buzz, but even better, since in Buzz the tracklet entities are bound to machines and thus bound to fixed signal flows, whereas in a Renoise working as described, the same tracklet could be placed in different tracks throughout the song (or even at the same time), so for example a beat could change from one DSP chain to another by simply putting it in another track.
No more copy-and-paste orgies as well. A hihat tracklet repeating almost all through the song wouldn’t need to be copied as raw notes directly into patterns all over the place and once changed, this change also propagated all over the place and so on… All this tedious stuff - no more! What a bright world this would be!
) I really wonder if it’s even feasible, that is, if a track segment can readily be serialized and turned into a checksum? And also how long that would take, and when to do it (certainly not every time a note is entered or a value changed… in the background when there is no input might work, something like that).
