Pattern Matrix Rethink

Ideas & suggestions
1

The above words have stuck with me for the last few weeks. I’ve always been of the opinion that Renoise was great for composing.

The above statement postulates that, instead of writing a song like you would a book, the idea is that you should be able to easily offset and juxtapose various ideas.

From a nerd perspective, Renoise is like merging text using diff algorithms. Or, the idea that “writing a book” from several different MS Word documents is fantasy. If you want to move text in a MS Word document, you cut and paste. There’s no magical way to blend two different paragraphs of text together to make a better paragraph. You manually integrate the ideas of both into a new one. Same goes for coding.

As of today, at least for me, the key to tweak the Pattern Matrix. I will now lobby that the PM’s primary design goal should be: I have made a new sound, it should go here and here and here. It’s secondary design goal, to represent the patterns. Somewhere in the PM is the ability to represent “the code” but also the ability to shift track 4, pattern 5 to half of pattern 4 and 5 by drag and drop?

Since you read to here, I am hammering a stake into the ground and making this my thread. It’s not a floodgate to bomb ideas of dissatisfaction. Fuck you in advance. Start your own thread. My goal here is is to discuss: how do we tweak the PM with finesse and subtlety to allow for the basic idea of “composing” as defined by BOTB, but not change Renoise into a clip system, rather keep what we have. Is it possible?

Good times.

2

One idea, off the top of my head, is something like “Onion Skin” or “Photoshop Layers.”

That is, the Pattern Matrix stays intact. Tada! But, you can activate different layers. In these layers you merge squares, lasso notes, name them, and drag and drop them. There’s a post by Psyj that shows something similar for the Pattern Editor. This is also conceptuially similar to PM Clip, in that it keeps track of note structures but isn’t really clips.

These separate “onion skin layers”, on top the pattern matrix, allow me to define chunks of data and move them around giving me the illusion of control, but the reality is just intelligent representation of static data that is auto-merged into regular patterns.

3

with ‘layers’, do you mean a clip-system that sort of ‘hovers’ above the PM? so you can change all of the stuff you want that comes with the clip-functionality, and ‘behind the scenes’, Renoise builds it into the normal pattern matrix. a bit similar to what software is in relation to hardware, or a GUI to code?

if i understood that right, i think it’s a great idea.

4

No, the old-school tracker pattern paradigm didn’t change with the introduction of the pattern matrix, but at the time (2.5) I think Renoise seriously needed a way to visualize the song structure.
A “proper” arranger would be something else, since it would have to deal with re-usable data (aka clips), and basically introduce a whole new way of working - and probably still not satisfy a lot of people who like the non-linear nature of Buzz/Ableton style sequencing. This is also why I put forth the PMClip concept, because it deals with clips in a almost completely transparent way. Write a “riff” once, use it anywhere you want. This is interesting because it promises to be a kind of hybrid between linear and non-linear.

Another thing to consider is the idea of “instrument patterns” - this is also a kind of clip idea, where you link a note sequence to an instrument. Much like an arpeggiator on steroids, you could get the combined power of tracker notation/sample manipulation and the ease of use that an arpeggiator can offer - and the result could be a very performance-friendly instrument. We could take cues from many existing products (my favorite “arpeggiating plugin” is Consequencer by Sugar Bytes - it has a nice balance between chaos/control).

Also, there’s completely alternative ways of working - for example, the still-in-beta Recorder application for Duplex was heavily inspired by Conner’s talk about a 4x4 grid. Apart from the fact that it’s strictly sample-based (you need a audio source - microphone, a second Renoise instance, whatever…), it’s basically a non-linear workflow like Ableton’s, where each pattern represents a “scene” (a unique combination of active clips). There’s a lot of potential in that idea, and I’m sure it can be applied to other things as well.

5

Hopefully related brainstorming.

Assuming we want to keep Patterns as main building blocks and the Pattern Matrix as birds eye view on the song, but also want reusable clip content. Wouldn’t using pattern slots as clips, pattern slots instead of whole patterns as reusable content solve most of what we want here?

PM clip tries to emulate clips by automatically copying changed content to other similar places. Why not allowing “real ghosts” of pattern slots in the matrix.

A picture may be easier to understand:

Now:

  
 SEQ Pattern Matrix Slots  
[1] | [1.1][2.1][3.1]  
[2] | [1.2][2.2][3.2]  
[2] | [1.2][2.2][3.2]  
[3] | [1.3][2.3][3.3]  
[4] | [1.4][2.4][3.4]  
Each slot can be hard copied around.   
Each slot is unique unless a pattern is repeated, reused.

Matrix Clips:

  
 SEQ Pattern Matrix Slots  
[1] | [1.1][2.1][3.1]  
[2] | [1.1][2.2][3.2]  
[2] | [1.1][2.2][3.2]  
[3] | [1.1][2.2][3.2]  
[4] | [1.4][2.2][3.4]  
  
Track 1 repeats first slot 4 times, then creates a variation at pattern 4  
Track 2 repeats first slot all the time  
Track 3 contains 2 different slots, one at the beginning one at the end.  
Patterns still can be reused (Pattern 2 is used two times here), still form the songs main structure.

Different visualization of the same thing.
x.x numbers would only be visible for ghosts, empty slots can be left out, so the real picture would look like:

Matrix Clips (real slots vs. ghost slots):

  
 SEQ Pattern Matrix Slots  
[1] | [XXX][XXX][XXX]  
[2] | [1.1][2.1][]  
[2] | [1.1][2.1][]  
[3] | [1.1][2.1][]  
[4] | [XXX][2.1][XXX]  
XXX is a clip.  
x.x a a clip ghost, repeated clip content.  
[] an empty slot

If slots can only be reused in “its” track only, we only have a pattern reference per track to create ghosts; end up in something like a multi track sequence. This can even be entered numerically then and not just copy and pasted around like in traditional arrangers:

Matrix Clips (ghost slots reference pattern numbers only):

  
 SEQ Pattern Matrix Slots  
[1] | [XXX][XXX][XXX]  
[2] | [1][1][]  
[2] | [1][1][]  
[3] | [1][1][]  
[4] | [XXX][1][XXX]  
XXX is a clip.  
x the referenced pattern for each ghosted slot.  
[] an empty slot

Aka, each slot in the matrix forms a clip, which then can be ghosted into other slots in the same track instead of hard copying it - what the matrix right now does. A ghost to a ghost may either not be allowed or would point to the head, the final resolved real clip.

This still is quite limiting, cause you can not put multiple clips in one pattern and a pattern’s length forms all its clip’s length.
Dead end, just a compromise, or worth thinking more about it?

Or did I missed the point of “Onion Skin” and it’s exactly this?

6

Absolutely something worth thinking about! First thing that comes to mind is why we couldn’t have independent length for pattern tracks? It’s something I had been considering with PMClip - that you could specify a different length for the clip, and it would simply repeat if the pattern you inserted the clip into was longer than the clip itself (as usual, I’m sure there are many pitfalls I didn’t realize when I came up with that )

7

Am I the only one who loves the matrix in it’s current state ?

8

Sure it would solve some things. And is better then nothing. But will it be flexible enough in the end?
I think only a real linear type clip arranger on top of, or directly merged into the current pattern system, can completely solve this once and for all?
That together with instrument-patterns can make you sequence any way you want.

Sorry for another long post :) with lots of repeated stuff, I’ll try to only mention the essential things:

EDIT: I hope the following text don’t deserve a “f*** you” in advanced from Conner_Bw :P But really, its very relevant in telling why the pattern matrix can hardly be “finetuned” to a better arranger without some clear changes/additions.
Let me know if you want me to delete this…
Taktik is way more on topic, coming up with ideas that is within the current limitations.
Another small suggestion could be an optional view of the pattern sequencer/pattern matrix. Toggle to show real length of patterns there. As now it is a fixed size for all patterns in the PM. It probably wont help you arrange any faster, but could be easier on the eye and understanding the structure even better, visually.

The rest:

[details=“Click to view contents”] What I find useful about clips in other sequencers is how to keep order of all the clips, easier to do retakes/variations etc. Be able to rename properly. And be able to add the clips where ever you want, sample accurate. Like mentioned before, I have a sound/clip, i want it to be “there and there”, while its not quantized to an entire pattern length, not have to go into pattern editor to move the sound, not have to destructively edit the sample, or add offset commands etc. Just grab the clip and place it where you think it fits. Or be surprised when you offset it a beat, or finetune it just a few ms to get the extra precise punch or whatever.

After countless discussion about this, I only see two really fully flexible systems.
1:
Can’t we just add a clip pool that works independent of the current pattern system.
Perhaps the only technical change to the current pattern system is that there will be a hidden reference to all the clips and position/range of the clip that is used in each pattern.
A pattern is still just all the data on all lines within the pattern boundaries, no matter how large each clip is. When copying/delete/changing a pattern that contains clips that cross the pattern boundaries, it does not matter. This will just crop the clips to within pattern boundaries. But then the user can optionally resize the clips back to original sizes. In other words, the default behavior of pattern sequence editing is to nondestructively chop of the ends/beginnins of clips that cross pattern boundaries.
Seen from the clip point of view, resizing the clip in the pattern editor is nondestructive. Seen from the pattern view, the same operation is destructive.
Clips have properties, like original size and content and is stored separate in a clip pool. And can also optionally be edited separate in a clip editor (but you don’t have to! Any content changed directly in pattern editor is destructive for the clip, but the resize of the clip in the pattern editor is not destructive for the original clip). Patterns ignore all this, what you see is what you get within the pattern boundaries.

Overlapping clips are not allowed. Unless you actively merge them to separate note/fx columns in same track (this is optional, and will not happen automagically).
To sequence more freely with overlapping clips or clips with different tempo etc, just use instrument-patterns instead.

If you use very small patterns, chances are that you work very “block oriented” anyway?
If you want to do things more freely/unquantized , chances are that you use some larger patterns to begin with?
To better navigate vertically in huge patterns, it could be useful to have markers you can insert anywhere in a pattern. Then a function to jump to next/previous marker, and to mark block of data within two markers etc, and a marker list implanted in the pattern sequencer as well. So in theory you could just as well skip the entire pattern system if you want to, and only use one huge pattern for the entire song, and then use markers list for easier navigation (jump between markers instead of jumping between patterns in the pattern sequencer.

2:
Another entirely different solution to all this is to let the current pattern system only be an optional sub-framework that you add to a classic DAW like linear system.
You can even have multible pattern sequences to exist side by side, totally independent.
So:
-If you wanna sequence traditionally DAW like, just never add the pattern framework. Just use clips in a linear way. Rely on markers for better navigation. The “pattern editor” looks like just one huge pattern. But it is not a pattern really, just linear endless tracks side by side. Each clip can be edited in a clip editor.

-To sequence old school tracker style, then only use one pattern framework, and forget about the rest.

-To sequence advanced, add several parallel pattern sequences (that can have different sized patterns, independent tempo etc).
You will see this sequences side by side in the main arranger window and the pattern sequencer window. Each pattern sequencer having its separate matrix system etc.
And you can also use clips outside the pattern framework at the same time.
A pattern sequence is just a section of one or several tracks, ordered and sequenced in traditional pattern style way.
In the main sequencer/arranger window, a pattern sequence framework/section will just look like any other clip, either collapsed to one clip, or extracted to individual tracks and clips that exist inside each pattern sequence.

This might seem messy, especially without any pictures to back up all the words, but I think it’s not. It’s just flexible. You make it just as easy or advanced that you would like it to be…
[/details]

9

I like the way to arrange a track in sunvox, This is simple and effective. <_<

10

I have been thinking past several months whether we really need to be able to reuse patterns. In my personal experience this only causes me trouble (accidentally forgot to uniquify the copied block and I destroy earlier part of the song). Maybe we should just have linked blocks in pattern matrix but no linked patterns what so ever.

11

Here’s a simple ASCII drawing of what I mean. I’m not sure Taktik’s post addresses this?

Before nudge:

  
C-4 Pattern 1  
---  
D-4  
---  
---  
  
--- Pattern 2  
---  
C-4  
---  
D-4  
---

After nudge:

  
--- Pattern 1  
---  
---  
---  
C-4  
  
--- Pattern 2  
D-4  
C-4  
---  
D-4  
---

Obviously, the above is a bad oversimplification of what two patterns look like.

In my “Onion Skin” idea, I was able to activate some sort of selection tool, select two notes, and drag and drop them “wherever I want”. Once I submit? this layer (like a web form?) I get booted back into the normal PM, and Renoise has done all the dirty work of merging. When I go back to the “Onion Skin” maybe ‘C-4, D-4’ is stored in a “clips” array and I can pull them out and drag more of them anywhere onto the pattern(s)?

Basically, an onion skin is a set of tools and data storage on top of the PM, as summarized by rhowaldt.

In my mind it’s a bunch of lasso tools, maybe even automatic pattern analysis, and a list of clips I can pick and chose from if I ever want to drag and drop more of the same thing onto the PM. It’s important to break the block way of thinking in this mode, but it’s understood by the user that this mode is a superset of what already exists.

12 
I also thought about this a few weeks ago. Or, maybe I read one of your past posts in the past and it festered in my mind for several years? Whatever the case, I think this is a good idea.  
  
The way I describe it is that, in the future, all projects are one huge pattern.  
  
If I want "multiple patterns" I pull up some sort of "Advanced Edit" like dialogue and put a checkmark next to "Visualize blocks of 0x80". This is just a way to constrain the mega pattern so that it behaves like the old-school tracker. It's still just one huge pattern, but it reverts Renoise to it's current behaviour from a GUI perspective.   
  
More complicated "visualizations" would be welcome, maybe sub-visualizations (a pattern within a pattern), and these act as a sort of clip pool? I dunno, I think I'm repeating what you are saying, just trying to use different words.

EDIT: I’m breaking my own rule talking about this… I want this thread to be focused on ideas that tweak the existing system, not an overhaul, for which we already have plenty of threads. Doing the hide thing, like you did. :)

13

Ok. Yes, then we are basically talking about the same things here. This is like my first option I wrote about.
The patterns and thus the matrix is dividing and representing the data that is there. No matter if it is a clip that has “generated”/inputed the data.
It doesn’t need to know there is a clip system at all.
We just need some rules for what should happen and how to visualize things that are reused/linked (either pattern or clip).
The clip pool is basically just a separate pool of clip data that is not necessarily stored in any pattern.
How these clips are created is another story and not so important in this discussion( but I wrote some thoughts about that in this ancient post.It’s about clips being automatically made, and using tagging and smart sorting filters to keep control of them.
A clip can also be a audio clip, and perhaps automation clip and fx clip or whatever we find useful divided into separate clips.

Anyway, a separate clip system or not, a better way to move data between patterns is much needed. No need to thing about clips to do that.
Like danoise has pointed out very well about the ‘Improved “continuous” mode’ in the Zoomable pattern thread.
Also the post I wrote about pattern data being automatically and temporary bundled for easier handling (as you also linked to) is just another example of several ‘arranging tools’ coexisting.
So yes, I agree with you. The patterns we have now should not limit us in any way. It should adapt to us, and not the other way around.

14

linked slots makes the most sense in my head but any thing which makes A/B comparison between pattern variations more efficient would make me happy.

it would be very nice to be able to open up a project and quickly try out, for example, a half tempo drum beat by creating the new drum pattern and then substituting the old drum pattern

might be that some sort of extra functionality of managing unused patterns would come in handy. maybe we should have views which separate the set of clips/patterns from the layout/arrangement of the tune. would make it easier to have multiple versions of arrangements as well.

edit: ok, seems like what i wrote above is basically what’s been called a clip/pattern pool by others. to take things one step further: shouldn’t we have an arrangement pool as well?

15

I’ve not played aroung with the Pattern Matrix much. But the Pattern Matrix as it is basically mutes / unmutes tracks within patterns doesn’t it? Could a future option be that rather than muting/un-muting parts, the Pattern Matrix ‘triggers’ parts within a pattern? Then you could mix and match parts from different patterns.

This would give Renoise the basic function of Ableton Live’s session view. But for people like me that use Renoise to compose and Live to play gigs, this alone probably wouldn’t be enough to move over to Renoise exclusively. To do this, I’d also need the Launchpad to work in Renoise exactly as it does in Live. And I’d need some way of recording and editing performances.

I don’t think it’s helpful for Renoise to try and play catch-up with other programmes. It needs to develop in its own way. Ironically, in my view, this is exactly what has gone wrong with Ableton Live - they’re trying to make it all things to all men rather than focussing on the things that make it unique.

16

I agree with you.

So on that note, my opinion is that Renoise is great for composing. That is, typing songs. That is it’s historical strength. Instead of musical notation and paper like it was done 200 years ago, it’s on a computer. Trackers are great at this.

What I realized is happening is that “composing” is being redefined to mean “noodling”.

In the first post I quote BOTB who used the word “compose” and brought up expectations around the Pattern Matrix. Therefore, for me atleast, somewhere in the existing interface there should be a way to meet that expectation because, well, that’s what people expect? E.g. ‘Put note, here, here, and here’

I’m looking for a compromise.

17

this also occurs to me from time to time

18

This is something I also wonder. Personally I always make every pattern unique as I know there is quite a high likelihood I will go back and either add variation or automation which I wont want repeated through each instance of the pattern.

The only ways I can see of advancing the arranger are to break the old pattern mould.

If each track was to effectively be its own pattern, never tied to any other, each track could be of any arbitrary length, rather than being the same as length of other tracks.

The arranger (matrix) would show track lengths graphically.

Each track could be lined with with single pattern line precision within the arranger, with quantise modes to have keeping to beats and bars easier.

The pattern editor would still look the same, except you would be forced to use the mode where you see previous/next pattern at the start/end of currently playing section, and tracks which going over more than one pattern have a clear dividing line in the pattern editor.

You would still have Blocks, to make editing sections easier. You would set a default length and start offset for the song. This would then replace the overall patten sequence and looping via that.

Looping of different length and positioned sections could be achieved by highlighting in the arranger and selecting loop selection, or showing only a single track for editing and looping that.

I know this is pretty much Clips but I’m just trying to describe a workflow change that may work in Renoise without using terms which people may already have connotations about.

Any of that make sense and seem like it may work?

19

That’s what I was thinking… And I don’t know if I’m stupid or something but I’m still not getting it. Why do we need clips? WHY? If it’s the “reusing” part then isn’t simply copying and pasting PM slots the same as “reusing” them?

20

a good thing with this is that it will be pretty transparent to anyone who doesn’t want to use it. what i think is good about it: it’s great for trying out variations. especially in the phase when you haven’t fully fleshed out the tune with those small variations like fills and such but where you are trying out different things and work with a lot of basic blocks to get a feel for where a track is going.

also, if the devs/scripters go down this path then i think that we will eventually see added functionalities like clips which loop until the block has reached it’s end and possibly asynchronous clip launching.

well, sure. that thing here is that i think a way of reusing data is just faster and neater. it will be easier to read your own and other’s xrns files.

people writing sheet music has been doing this since day one: “repeat this part x times”, “jump to coda”. defining a piece of music by reference is simply smarter (when it’s possible). it’s well known to all of us who work with programming and databases: keep only the data in one place and point to that place.