Feature Design: Zoomable Pattern Editor Discussion

Ideas & suggestions
61

Ah, nothing is like real discussion! ;)

I think that is kinda drastic that Renoise will automatically do this. I guess I could live with a first time dialog for the behavior. But my point is that from now on you must active make duplicated patterns. As most newcomers will now clone patterns instead of duplicating them.
I would find it disturbing that renoise make them unique when I intentionally made it so it would not do that (because that is why I would duplicate patterns in the first place!). It’s two totally different ways of thinking. And so it should continue to be IMO). But this is nothing I would make big objections about…

Let me point out that when you enter some data in an empty track, then there will automatically be made a clip that is one pattern long (default, but configurable).
Yes, this will make a lot of clips, but this has to do with backward compatibility of the current workflow in a tracker. You should not be forced to make clips. You should be able to just start entering notes in the empty pattern as you do now and never even think of that there is something like clips there.
But you just came up with the answer for it. It’s all about hiding clips in the list (and visually by just adjusting the default clip color to the background if you like that…).
You actually quoted me from my first post in the Arranger thread from 2003 :):
I then proposed to sort and filter clips by how they was made/defined:

I have also written tons of things about this internally in more recent times. I should really post some of this public now…

And here we need to separate things a bit to clearly make the difference in concepts for other ppl reading this.
You will not allow someone to see the content of two or more clips at once. Right? Because you have to open each clip in a clip editor. While in my concept this is possible as you can edit clips directly in the pattern editor.
Thats the main difference we have. I say that instead you can edit clips directly in pattern editor. They are then not threated with instrument properties, just raw extracted data. But you can optionally embed the data into an instrument. And this make this into two different features really.

That said, I would not mind a split patterneditor (that would be the same as your clip editor), and arranger view. So highlighting a clip would show you the data in another part of the screen.
I also (as written on one of my concept pictures) suggested that you could see focused clips graphically in the lower panel. It make sense to also be able to see it pattern style like your clip editor.
In general I think renoise should be more flexible to split screens like this.

Ok, that should be there of course.

Me too. I don’t understand the 512 limit.
But I find myself often wanna temporary merge 2 or 4 patterns (to for instance play a complete part of the song in one go), and also edit as one big pattern, but after I’m finished it would be divided back into my originally smaller patterns. My suggestion would allow that. And your suggestion would still be valid when there is no/all selection made in teh pattern sequencer(?)…

62

So if patterns are clips… and patterns can contain clips… then does that mean clips can contain clips? … and if that’s the case… what happens when you’ve got a clip which which contains a clip using an instrument that is linked to the first clip?

… also, would we clips have their own DSP chains, or would they be entirely dependant on the pattern’s DSP chain?

What about clip instruments… if instruments end up with their own DSP chains, will each track in the clip have its own DSP chain inside that instrument?

… or would we just get proper effect routing after all?! :D

63

Patterns are clips? Ok I know the terminology here can confuse ppl.

My definitions based on ‘my’ concept:

  • Pattern = the pattern we have in renoise right now, nothing new, nothing different.
  • Clip = a block of data. The same block you get if you in Renoise v.1.9.1 mark a block and copy it. Then you have a clip of data stored n the your computer clipboard. You can then store this clip in a clip list.
  • Instrument-pattern = independent pattern that only exist in that instrument. No clips inside the instrument-patterns. The instrument you use in the instrument-pattern is usually instrument only existing inside the same instrument. Because you can now have instruments inside instruments. But they are independent instruments. I’m not sure if we should allow instrument-patterns type of instrument as sub-instrument inside another instrument. In any case you will not be allowed to point to the same instrument creating a loop.

The other type of instrument allowed in the instrument-pattern is to point to instrument outside it self.
Again, you can not point to itself and creating a ‘midi loop’.

Clips are dependent of the pattern DSP. Instrument-patterns are not.
(however I would like that single-data clips like a wave-clip in a audio track could have at least some basic independent DSP like vol/pan envelopes. But for just normal clips you would not have DSP’s directly on them (we could make it possible, but dunno if that is needed when you can just make a instrument-pattern of it instead)).

Clip instrument I guess is what I refer to as instrument-patterns then? Then yes. Every renoise instrument would have a Master Instrument DSP track, and Instrument send DSP track. But also the instrument would have normal track/master/send for each instrument-pattern it contains (each instrument can have several instrument-patterns inside it self.
You can for instance map 5 different patterns on the same key only changing by the velocity you use in that key. Each pattern can have independent instruments, or shared instruments.
When using shared instruments, then you can edit many instrument-patterns at once!

On this picture you see how that works. You can edit one single pattern, or edit all at once from the range you make in the keymapper.

I have explained all this to great detail in the RNI future thread.

BTW, one problem not discussed in that thread, but I have discussed with taktik internally, is how the instrument DSP should work. If each note you play from a instrument having instrument DSP should be true polyphonic (calculate the added DSP’s for each note, or for all notes together). Normal samplebased instruments using only internal Renoise DSP would have no problem doing polyphonic DSP. But you are in trouble using vst(i).
Part of the solution to this is to have send channels inside the instrument, and to have option for internal DSP’s to be polyphonic or not. Then it is up to the user to build a true polyphonic instrument or a partly polyphonic instrument (like vsti are… you can only use vst’s on a single track… you can’t manipulate each single note from a vsti like you can from the internal sampler in renoise).

But you see… now this go way of topic. This really belongs to the RNI threads. But Danoise have tried to integrate instruments and clips… so thats what make all this seem a bit messy now ;)

64

Edit: Hey pysj, I’m a slow poster - didn’t see your reply before now. Lets try and keep the focus :slight_smile:

Recursiveness… that’s tricky stuff. But I’d say that a clip could hold any instrument or clips, except (any of) the “parent” clip(s). Then we would avoid clips that reference themselves. And BTW: I don’t mix patterns with clips! In my book, clips are only able to hold whatever a track can hold (I’ll explain below)

I have no “clip instruments”, just clips. Clips can contain what I call “dynamic clip parameters”. It makes them able to adapt (reconfigure) themselves to different track-DSP configurations using existing DSP devices, with a minimum of GUI space. But basically, putting a clip into a track will make use of the available note columns and DSP devices, just like a any normal track would be able to.
Before you think “hell, this is not ambitious enough for a such an amazing thing as clips!”, think about how clips can be created from existing notes, and should also be able to convert back into normal notes. Part of the problem would be, that if we were to define some fancy concept for a clip including a separate DSP chain, there would be no (simple) way of converting such a clip back into a normal sequence of notes.
I really think this is best dealt by improving the xrni structure, which has a lot of potential for separate DSP chains, routing etc.

I’ve not suggested a single change to instruments (yet). Instruments are instruments, no change at all. All clips and instruments have in common is how they are dealt with (entered into the pattern editor!)
But hey, I was confused by your ideas as well, especially the instrument part (referencing other instruments?) - it’s funny how I should point to the xrni future thread too;-)

65

But you have given clips instrument properties! right? :)

Well, anyways. If your ambition is that you can convert all embedded instrument data into raw extracted pattern data then you are in real trouble. You just mentioned the DSP problem. But the other thing is what if I have many different instrument patterns (or embedded clips you would call that?) and play a chord. Lets say each instrument-pattern have 4 tracks, and DSP’s and automation devices and what not, how will you possible be able to extract that data into a single track in the pattern editor? :)

Thats why I have tried to keep a clear difference between what a clip can do and what a instrument-pattern can do. I just can’t see your concept work in a consistent way. At least not with quite fundamental limitations like not being able to edit the content of several clips at once, side by side in the pattern editor. And also how that all would be backward compatible with the current pattern sequencer etc.
But I may have got something fundamental wrong about your concept here :)

We are not far away from each other, but I actually am not 100% sure what your definition of a clip really is.

What will I see if I drag and drop a clip from whatever list you have that clip in, into the pattern editor?
Will i see a note representing that clip (like on your flash where you see the external clip editor side by side of the pattern editor) or will I see the extracted data (the real content of that clip)??

66

Ok… taking into account that I’m pretty sure the clip idea stemmed from the need to have some sort of non-destructive arranger concept…

I have one question: if you have a clip, followed by a few non-clip notes… and you zoom out to arranger view… and decide to move the clip down a bit… what happens to those stray notes? are they automatically going to form a clip of their own? will they exist under the clip you just moved on top of them? Will they simply disappear? What are the exact rules for these sort of circumstances?

67

If you ask me:

There is no such thing as notes that do not belong to a clip.
If you enter any note in an empty space in the pattern editor then there will be created a clip automatically.
The size of this automatically made clip will be one pattern length by default. If there already is a clip occupying half the pattern length, then a new clip that covers the other half of the pattern length will automatically be created.

Clips can not overlap. Just the same way that you can not copy/paste a block today several times upon each other. Then you just overwrite. But any clips that overlap another clip will not destroy the clip(s) underneath it. It’s still there if you remove the top clip, but you can only hear the one on top.
In other words you resize and overlap clips nondestructively. But only the visible clip will be valid. No hidden data in there.
With a modifier key you can resize a clip destructively over it’s original size (and you can of course merge and split clips destructively as well).
If you want clips that behave totally independent, then you use the instrument-pattern instead. Then you can trigger anything like you want, but you only see the patterns you trigger as a single note(s). To edit these instrument patterns you do that in a separate editor that is connected to the RNI structure, and not in the main pattern editor where you only deal with clips.
You see the difference between clips and instrument-patterns?

68

I guess I’m just kinda confused as to how the nondestructiveness would be displayed in a pattern if in the arranger, you moved another clip on top of the pattern-long clip for instance.

69

In the pattern editor you would not see clips at all (or we could use color coding or a ‘frame’ to indicate where the clip start/end, but in principle you would not have to know there even exist clips at all if you just wanna track the old school way). In my concept you deal with clips only in the arranger mostly (although I see no problem also doing some basic clip resize/split/merge things directly in the pattern editor as well). How small clips do you think you normally will use anyway? How many lines? I see clips as something you would use mostly 1 pattern length in size or more, then some linked clips (duplicated clips) could be useful for half/quarter pattern lengths to quickly set up some beats or baselines etc, and in a very few cases down to 8 lines? So how much information about clips size and boundaries would you find useful in the pattern editor if you had an separate clip-arranger window? I’m not sure…

To edit the frame of clips destructively you could either do that in a separate clip editor (graphical as I have suggested, but why not also pattern editor like one).
But anything you do in the clip-arranger is not destructively by default. If you delete a clip there, then the clip is not gone, it is still in the clip-list. If you however delete something from the clip-list then it is gone for ever (although we could have a function to directly destroy the clip in the arranger using shift+delete for instance, delete from arranger and project).

So lets say you have a clip that is one pattern long, then you drag/drop another clip that is half the pattern length that overlap the first clip, then we have two ways we could deal with that, either the underlaying clip will be nondestructively deleted under the overlapping part. So if you then remove the second clip, then you must manually resize the first clip to its full length again (if you wanna use the full length of it right there). But no matter what if you drag/drop another instance of the first clip into some other part of the song, then of course the entire real length of the clip (1 pattern length) will be added. = nondestructive.

The second way is that if you delete the second clip the arranger, then you will see the previous state of the first clip (the entire size of it, no need to manually resize it again).

I’m not worried about this at all. It’s in the clip list the real data is stored. As long as you don’t delete things there, you will never loose any of your data. No matter how you overlap clips in the arranger…

Also remember that we are not just dealing with note clips. There would also be audio clips (streamed in audio tracks), automation clips, and perhaps even fx-data clips. And that is also why I think the separate clip-arranger might be the better solution…

70

Ah good… the what is a clip discussion :lol:
Let’s be consistent. I’ll call my idea of a clip a “note-clip” from now on :slight_smile:

First of all, no arranger features without clips. I imagine note-clip as a pretty clean-cut separation from other elements in Renoise. It’s neither a pattern, track, nor instrument. It’s made from pattern data, along with some additional space for automation curves and mappings, which can then be linked to the “main pattern” track DSP’s in a dynamic fashion, to control whatever effect that we might prefer it to.

The secondary editor is in essence a small version of the pattern editor, containing a single track worth of pattern-data, as well as options for controlling automation curves.
So, with note-clips, no audio processing is taking place, it’s made from simple note/controller data and mappings.

I’d say, let’s expand the track itself :slight_smile: Current limit is twelve note-columns, with a larger limit, that wouldn’t be a problem. As for DSP automation, note-clip parameters are already linked to actual, existing devices, so that wouldn’t be a problem either.

If you decided to drag a note-clip into a busy track in the pattern editor, what you would see was perhaps a track which previously had one, unregistered clip, make room for the new clip, or have the new clip “float” on top of it (we largely agree on the idea of “unregistered” clips, and how they work). As for clip content visibility: it depends.

Standard arranger features, the kind of stuff you need a mouse for

This is where we disagree the most. I’d say, let’s work directly with clip trigger-notes, as the default editing mode. You are saying, let’s keep all notes available at all times (except for “instrument-clips”), if I understand you correcly.
But perhaps we could come up with a solution, an automatic toggle for displaying clip contents. Imagine when you’ve opened the clip-editor, clips in the main pattern are displayed as trigger-notes. When closed, these clip instead display contents as a (editable) note sequence. That’s the best of both worlds.

71

Thanks for explaining that. You think as I thought you did :) Just needed it confirmed.

About if you see the clip content in the main pattern editor or not:

Bingo :) That is the difference I have tried to point out all the time here.
And I see huge problems when:

That is not as easy as it sounds. In an ideal world we would have independent clips that can have it’s own tempo and devices and so on. I wanna restrict that to what I call instrument-patterns. What I define as clips can not do this. Thus you can not extract/convert the content in the main pattern editor like you want.
You on the other hand want to treat all clips as instrument-clips where you toggle between to see the note trigger or to see the content of the clip directly in the main pattern editor.
That can work to some degree if we give heavy restrictions like no independent tempo and perhaps how many tracks it will be able to use (one track clips only?).

However, what I have suggested with instrumnet-patterns is that you can actually map several entire patterns into a keymapper in the instrument. You can in principle trigger as many entire patterns you want by just pressing a key on your keyboard. And they can all have different length, different tempo, different dsp, different and independent instruments, and even different sustain and loop settings. This would be totally chaos to try to convert any of this directly into the pattern editor. Also when you have transposed trigger notes, and then extract the clip, and then edit some content in there (still transposed) I feel the whole thing will just be messy :)

Another thing is that there will be a hell of a lot of clips. So will each clip then occupy a instrument slot?
If not, how will you then show the trigger note for the clip?

Don’t get me wrong. I also have thought a lot about your concept here. It was how I initially thought is could be many years ago. But after a while I changed my mind as it would be too messy and in some way restricted.

But right now it is not clear what we will end up with. It will probably not be far away from what we have discussed in here. But in the end it is up to taktik to decide as either way can be quite much to change to make this work (if we also include the RNI structure change in all this).
The advantage of what I have proposed here is that it does not need much extra restructuring to make a simple clip editor up and running. No trigger notes etc. Stuff like that could be saved later for the big upcoming RNI change. It’s just a clearer difference in how you do things, and clearer/easier to implant one thing at a time. IMO of course.
But time will show :)

72

Why not just make clips the same thing as patterns then? … that way you can arrange patterns however you want, side by side, whatever, just like this clip concept, except you could trim down the number of required tools, and confuse users a whole lot less? I don’t see one real benefit to defining a separate construct from patterns, looking at what you’ve mentioned here… these could all be changes to the current concept we have of a pattern… and it would overall make things a heck of a lot more flexible.

73

What do you mean you can edit several patterns side by side?
You must edit individual patterns right? what if one pattern has another tempo then the other? How would you visualize that?

A clip can contain a pattern, or many patterns by using instrument-patterns. Is that so confusing? :)

This was discussed in this thread many years ago. Probably many of the pictures in that thread are gone now…

74

I have read some of the posts in this thread - specifically the ones on the first page, and watched the demonstration flash videos.

The visualization is superb, and the ideas are quite nice, but I have some points I would like to mention.

My bulleted two cents:
I probably missed the description of the piano roll feature. I also do not understand what is it for, and am generally against piano rolls and everything they stand for. So unless there is a really good reason for adding one to Renoise, I would avoid it.

So, generally speaking I would say this:
I am +1 on the zoomable - if it will also provide a decent solution for songs with no clips.
I am +1 on clips - if I can keep doing songs naturally and nicely without them
I am -1 on making the continuous edit so it will automatically clone patterns, but it will not bother me if this is a configurable feature (i.e. i can stay with the current behavior)
I am -1 on the piano roll - unless there is an explanation for it.

The bottom line - since the people who designed renoise so far seem to have done an unbelievably amazing job, I trust they will continue doing so with or without my comments so whatever is decided is probably gonna be excellent.

The short version of this post is:
Keep Renoise a tracker.

75

I respect your opinions. I really do!
But to me it seems you just comment on something you do not have the fully picture of. So you naturally get a bit worried if this is all bullshit that you will never use?

Let me put it this way:

Should we remove the mixer? Or what about the automation window?
And, do anyone really use vst and vsti’s?
Lets get rid of that bloated stuff…

We should just keep it a tracker, right? :)

Of course anything that will be considered added to renoise has to go through a longer process of discussing. Then a alpha team will evaluate the thing, before even more finetuning in betas. If anything feels wrong in any part of the process it will usually not make it to the program.
And backward-compatibility is not something taken easily among the team.

I would not worry…

76

It’s confusing, because we still have separate ideas about what the clip contents is actually made from. It’s obvious that when you use the term ‘pattern’, everybody will think that it’s a full pattern with all features. Is this what you want? And how could a separate editor hold all this information (at least, in your screenshot, there’s not nearly enough room).
I’m suggesting that a clip can hold information that corresponds to a track, without a separate DSP chain. Instead, it relies on existing DSP effects to achieve per-track automation. This would keep things simple, and remove the processing overhead resulting from an extra audio layer (note/controller data only). I say, let the RNI Future instrument come with a DSP chain, built-in arpeggiator/sequencer or whatever. I would still want to be able to use clips in the way I’ve described.

I still think we can come up with something with regard to tempo. After all, we’re not talking BPM, just speed, right? So, in essence, all clips would be running at the same ‘tick’ tempo, it’s just a matter of supporting multiple notes & commands per tick, and clips could easily fit into a normal track, no matter how fast they were playing.

Apart from the DSP part, which I disagree with, I think that everything you suggest is possible. Why shouldn’t it be? The next screenshot I’ll make will depict a way to map note-sequences onto a keyboard.

I wouldn’t. Unregistered clips still show as editable content. After all, the most important reason that normal notes are automatically made into clips, is to provide a way to visualize them in an arranger. Once registered, they will show up in the “instrument table”, where you can assign name + color :slight_smile:

77

I am not worried :)

And of course, there is a balance of what should be in and what not.
I did not mean keep it an eighties tracker, just a tracker.

You know when glorious pieces of software cease to be popular? when they get over bloated.
Back in the happy 90’s, when software companies realized their mistake, they released a “Lite” version of their software, hoping to fix the damage, but it was usually too late.

So, my only point is: be careful of over-doing. This is a traitorous ground.
Also my point, is that you have to decide who is your audience. You cannot make a software that will appeal to all audiences. Its too vast of an area.

Of course, no disrespect meant - I think the renoise designers are the SWAT unit of software design in this decade and they should be studied in the history books of our grand-grand-grandchildren… :)

78

nono!
What you say there is what I have said all the way. :D
A clip (note clip) is ONLY a block of notes. Nothing else. I have never said clips are more complex then that. It’s like a selection you make in the pattern editor now. So a clip do not have DSP or anything fancy stuff.
It is literally just a bunch of notes saved as a clip.
HOWEVER, you can indirectly trigger entire patterns using separate patterns that you hook up in the instrument (that is a instrument-pattern).

So that is why a clip indirectly can contain many patterns if it contains notes from a instrument that has patterns inside it.

Its really simple. You would have two cool new features in renoise.

  • Clips that is just pattern note-data bundled together and saved in a list.
  • Instrument-patterns that is independent patterns that you can trigger as a instrument.

Very simple if you ask me. Everyone should understand that. How you use these features is however a different story…

It does not matter how or where you make the instrument-patterns. You could load a pattern from another song, or you could convert one of you song patterns into a independent pattern in a instrument etc. That is all up to you. You use the already existing space in renoise to make the instrument-patterns.
My instrument pictures is very old and just bloated with features to show most in one picture. Just tab up things and the interface is the last thing I’m worried about…

Well, ideally I want independent PBM too. (Not for clips! but for instrument-patterns). But I know that is hard to do (to code), but I really think it would be worth it.
In the long run, instrument should be tempo independent (with option to synch). Every other synth and program I can think of have independent BPM, for a good reason…

Possible perhaps, but is it useful? How confusing would it be?
Suddenly one of your tracks does not show 3 notes as a chord, but instead show 3 patterns with transposed data and pattern-sustain points that make it very different from what the instrument-pattern originally was. And what will happen if I change one of the notes of this extracted data? Will I then destructively change the instrument pattern too?
If not, how can you then toggle between the two?

And yes, the tempo (bpm) problem there really is no answer for…

Ok, so you say, that as long as you don’t do anything/create/register any clip, then you will not see it in the instrument slots.
But when you do register it, then it will be there?

What I say is that, all clips, registered or not, will be made in separate list that has nothing to do with the instrument list. In this list I use simple drag&drop to the arranger/pattern editor. I can change colors etc without wasting instrument slots.

Then I say, if you wanna use instrument properties on one of your clips, then you drag/drop this clip to one of the instrument slots.
Now this clip is converted to what I call instrument-patterns.
Why the ‘pattern’ name and not ‘instrument-clip’ name?
Thats because I wanna have a much more advanced instrument. Using a pattern instead of a clip I can have many tracks with different DSPs, send tracks etc inside my instrument. More complex routing and possibilities.

I do not want to waste instrument slots on all the clips I know I will never want to trigger as instrument (see as a clip-note instead of the clip content).

IMO this is cleaner. You have one list for pure clip content. Nothing fancy there. Just DND from list to another part of renoise.

And you let instrument list be just for instruments.

Better to organize things this way I think. Because there will be alot of clips, even registered clips. I see no point having all them occupying instrument slots.

That said, an option to automatically add registered clips to the instrument slot as a instrument-pattern would merge your idea and my idea 95% together, except the toggle content part (as I think is more or less impossible anyway, but that depends on what limitations there finally will be in the engine).

Ok, I better end this discussion now, because this is starting to confuse me even more. And I can just imagine how confusing this must be to you and especially all the other that read this. I should just post my own concept, even if it is 95% the same as your, so you do your stuff, and I do mine. :)

79

One term I’ve learned on this board is “featuritis”. But since this is just a discussion, not actual decisions being taken, so we can have ideas clash & collide with each other… it’s all part of the brainstorming process. As far as I’m concerned, the design of zoomable pattern editor is basically still the same, but pysj’ input had me realise a couple of shortcomings (which is good).

And while you say that you’re not fanatic about Renoise remaining a “pure” tracker, how come you oppose the pianoroll (apart from it being extra work for the developers, of course)? Being able to select all C-4 notes in one move, and transpose/move them around visually, amounts to a good thing in my book.

@Pysj: I’ll prepare the next revised version in a while.

80

What is the purpose of the piano roll? Does it simply show the notes of the selected track?
Just to give me visualization of the notes?

If so, thats bloatness in all its glory.
I mean, it wouldnt hurt to have one, and I am sure you guys will be able to design it so magnificently, that I will have to swallow my hat if I had one, but it should be so low in the priority list that it should be launched in Renoise 8.2 … at least. :)

I mean again, it wouldnt hurt also to have a CD burner in Renoise, and a rich text editor for song info right? But the fact that it would not hurt does not mean it should be done.

Transposing notes is not a task you spend too much time on, and it is not that complicated that it requires an additional quarter-of-a-screen feature.
Just Shift F3/F4 the notes (if my memory serves me, at work now, no renoise here…

Also - in my opinion, one of the strongest points of Renoise is the vast amount of easy and useful keyboard shortcuts. So you will have to excuse me but all the dragging blocks of notes, or dragging notes in order to transpose them, just doesnt do it for me.

Also, an important characteristic of a tracker is top to bottom scrolling.
So, piano roll, and the nice pattern arranger I saw someplace here are nice, but are right to left.
I think you should not mix the two axes - in the tracker world time is top to bottom.
Get a good idea, and stick with it.