no matter if this is feasible or not in the end, you did a very good job on sketching this. splendid approach!
Very good addition.
I’m interested - can you do a small sketch of this idea?
I had imagined that keyboard interaction was unchanged (single-row increments), but that mouse interaction was quantized with the current zoom factor (x4, in this case). So if a clip was dragged using the mouse, it would quantize to the zoom factor (every 4th row in the pattern), but if using keyboard, the cursor would allow us to edit each row.
Good point, and my guess is as good as yours. But I’d say that intuitively, the best thing would be to allow the clip to be drawn with an offset (between the rows, so to speak), until we did something with it (possibly quantizing it’s position, by using the mouse).
I’d say this is a general problem with any tick-based concept: if timing resolution will increase, the delay commands would need to change - meaning that old xrns songs would have to be converted to a new format. And this is where we could ask ourselves, if we should ditch the antiquated tick-delay commands, and go for a more fluid system. But since this is all speculation, I decided to base the concept on the existing tick/delay implementation, which works rather nicely I think 
You did see the 6.25% zoom level, right? Question is: should this work independently of horizontal zoom?
Speed is limited as it is, and what more it’s quite confusing. Lower speed equals visibly higher progress through the pattern even though the BPM stays the same. In my book this is bad for a number of reasons.
What if each clip could have an editable resolution? One clip would play as fast as the next one in overview-mode but two clips could have different zoom-depth allowing for different timing needs.
Here it is. Of course, I’d vote against using yellow as it represents no data, but I stuck with original color codes from your mockup.
Now it’s SORT-OF visible that every line contains a note, but only every second has a command. Also different colored commands would be discernible at this zoom level. At any case it should be much easier to find the exact bit you want to edit and zoom in.
This is very usable concept, like for example in Reason, but it would make it impossible to view all the data side-by-side which is one of the main strengths of trackers, imo.
Dunno, maybe there IS a way to get the best of both worlds.
Indeed. That is the main problem with this concept, and is also why IMO we should
separate the clips from the instrument list and let that be optional.
Then the separate clip editor with independent speed is made in the instrument it self
something like this (from the Rni Future Thread:
Then you choose to use clips side by side directly in a normal pattern, or to
use/track separate individual patterns. You then set the settings for individual
patterns in instrument settings where you choose to synch the pattern or not. And you map the pattern like any sample.
A clearer difference in my opinion between clips and instrument-patterns.
But the basic idea is the same…
Ace concept , how long till we’ll see this for real?
The idea of triggering clips as instruments is the BEST concept in all of Renoise’s history IMO…
danoise: any ideas on the questions I asked regarding clips?
+1
Saw this concept in AHX and unless I’m mistaken that oldie futurecomposer had something like it as well. It would also be great if there was a way to see visually the contents of the ‘MultiInstrument’ encapsulated somehow in the main pattern editor.
There’s even a lot of unused space in instrument editor, so it’s an ideal match! FTW
Hey, you tell me! This is a discussion 
But OK, these were the ones you meant?
yes, it’s supposed to work that way.
Conceptually, yes. But we would need to introduce a new, clip-only, tempo command, since the normal F1xx and F0xx commands deal with the global tempo.
I see what you mean, especially when working with a multisampled instrument. Perhaps it should be an optional setting for each clip?
To demonstrate, imagine that we have a clip containing notes from a multisampled drumkit, and we trigger that clip at various pitches, c4, c#4, f4 and so on… With simple note transpose, the drums would swap samples (hihat becoming snare, kick becoming crash cymbal or whatever). With the second mode, the pitch of each sample would transpose, making the hihat stay a hihat and it’s pitch change according to the notes being played. I think both are valid options!
Retrig: yeah, think so. Actually, we need to consider how each and every command would work.
Different note columns: I thought about this, and my conclusion (and the way I’ve visulized it in the screenshots) is to limit to a single clip per track. Why? Because the maximum number of note columns is 12, and having two clips, each with say, 10 columns, would exceed that. But we really need Taktik’s input on this, before anyone of us say what is possible and what isn’t.
Multiple playing instances/different tracks: sure. Also, with the additional benefit of “dynamic clip automation”, which would let you have the same automation curve control different parameters, depending on what track the clip is located in (this is described in-depth in the feature design).
Two things I don’t get
1: Surely the notes would not become visible side-by-side, just by embedding them inside instruments?
2: Note sequences would be confined to using whatever samples the instrument has to offer. How is that more flexible?
Great job on visualizing. Personally i’d prefer a zoom in function like shown by you, but instead of zooming out an arranger. To me it makes much more sense to arrange clips in a seperate step.
1: Thats right. You only see the note of the instrument that is triggering the instrument-pattern. Where a clip is only like a block selection.
If you add 2 clips side by side, you don’t see two notes where one note representing each clip. Instead you see entire content of the clips side by side. The clip is not hooked up to any instrument.
If you however hook it up to an instrument, then it will become embedded and you will see the clip represented as a instrument note. That way you have both worlds.
- Not true. You can add shortcuts to any instrument in the project. You just drag drop any instrument into the key mapper:
Something like this picture.
In the list you can very easily drag/drop clips from to instruments.
Now… when that said, there is nothing stopping us from having options to automatically insert clips using the keyboard. But you will then not see a note inserted, but the entire clip content just like you would copy/paste a block. But if you want instrument behavior (instrument commands and fx,note off’s etc), then you must embed the clip inside a instrument slot (you convert it then to a instrument-pattern.
To sum it up:
clip = a block selection.
instrument.pattern = an entire independent pattern embedded in a instrument structure.
With your concept. How will you decide if you wanna insert a single note or if you wanna insert the entire clip content (extracted content) in the pattern when arranging?
OK I understand it a bit more now, but still not completely. And perhaps my preferred workflow is different from yours, but I’d prefer to have the ability to edit clips while simultanously having access to the pattern arranger + editor. And, lest not forget, two of the three basic points about the zoomable editor concept deal with something else than clips:
- There is currently no visual representation of the song flow
- Renoise provides only a few tools for working on song-wide scope (Advanced Edit)
By the “entire clip content”, you mean the actual notes embedded inside the clip?
It would be simple to convert a sequence of notes into a clip, and the opposite would of course have to be possible as well (extracting the clip’s notes, turning them into normal notes) - is that what you meant?
And there’s no way of confusing notes and clips, since they are visually very different. Clips are also stored in another part of the instrument table, since they can be dragged into the pattern (unlike instruments):
(BTW picture is outdated - I’ve ditched the “automation” clips in favor of “dynamically linked automation” 
)
Ok… lets not talk through each other here…
The last two points here is obvious. Of course we want that. I have never said anything else.
Also to see several things at once. That can be done no matter what clip concept is used…
Exactly.
You can for instance make a clip by just mark a block and ’ add clip’ (this is however
also done automatically as you start entering data into an empty pattern, you will get
track sized clips as default).
How would that be simple?
Lets say I have made an instrument that contains a pattern (i trigger a pattern inside
the instrument with it),now I play a chord and also add some pattern commands to that.
How could I possible convert that into extracted data? What about timing etc? The commands.
The space it would occupy, the dsp used inside the instrument? the ADSR envelopes etc?
Ok so the clips are NOT connected to instrument then? That was ‘my’ concept all the way 
But why do you have to keep the clips in the instrument list then?
If you track normally there will be tons of clips (one for each track in each pattern, normally).
I would then much more prefer to have it separated in it’s own list:
We are talking the same language here. But I store them in another folder in the same list you
see in picture above. You can use and reuse the automation blocks on anything. They are also
optionally layered.
One of the top left buttons you see there decides if you wanna include layered clips or not (if you
collapse the automation clips like on the picture below, then you will copy/paste all clips if the
‘layered’ button is activated):
Compare the second track from top on the pictures that have the automation
clips collapsed (last picture) and extracted (first picture).
As long as I’m having the layered button activated (the rightmost button) then all
clips (automation and fx clips) will also be copied/pasted along. The other buttons you
see there are visual buttons. To see the automation/fx clips and to see details on the clips.
You see we are in the same ballpark here. Just a bit disagreement on how to
structure av few things…
I’m just trying to point out the main differences between what I refer to as clips
and what I refer to as pattern-instruments.
All you see above here is about clips. No instrument involved at all (except for the
instruments the clips point to of course).
When talking about instrument-clip, or what I really refer to as instrument-patterns
then all that is very well explained in the RNI future thread…
Now it is up to the user how they will use this.
If you just want a simple clip arranger there is no use of using instrument properties
on that. It is just a way to copy/paste pattern and automation data much faster (block
of data is stored as clips in a clip list),
If you however wanna ‘track’ your own instrument to trigger entire patterns (buzz style), then
you do that in the instrument section of renoise.
If you have a cool clip and wanna put instrument properties on it you could simply drag/drop
that clip from the clip list into an empty instrument slot. Then put instrument gadgets on it
If you wanna use both methods then just track individual instrument patterns, then insert
the note for that instrument and make a clip out of it (the clip then represent the
instrument pattern).
If your instrument patterns are 1 real pattern size in length then you just insert one
note and the clip will be made automatically at same size (default auto-create clipsize).
You then have your ‘external’ clip editor in the instrument editor. If renoise would be
more flexible in the future you could see both windows at the same time if you prefer that…
Pysj, the more I understand your ideas, the more I think we talk about the same thing 
Just a couple of quick notes: I decided to integrate clips into the instrument table since they are input in the pattern editor simularly to instruments. Putting them in the same spot would make that obvious to all. Also, they are NOT created automatically, this would be optional. And, in my previous post to byte-smasher, I was arguing that clips would perhaps be limited by the current track structure - so no full patterns inside clips. However, as I also did point out this might be too early to decide what is possible and what isn’t. To answer that, I really think Taktik needs to get involved.
I’m giving this topic a bit of a rest now, and going to spend some time making music for a change!
People - please continue to bring your ideas forth. We will do a revised version later on.
Yes, most parts are the same. This is just what have been discussed for more then 5 years now anyway 
But just answer this simple question:
When you insert a clip into the clip arranger (= into the main pattern),
what will you see? Will you see one single note representing that clip? Or will you see the content of the clip (the extracted clip)?
In other words, are you forced to use an external clip editor where you edit one clip at a time? Or can you directly edit the source of many clips side by side in the pattern editor?
I never got a straight answer from you about that… or I missed it…
The reason for automatically make clips is to keep backward-compatibility with todays pattern structure. Else you will have problems, and you would force ppl to make their own clips which is not acceptable IMO. But you can read more of that specific problem quite early in the large pinned arranger thread.
First a big thanks for the really great presentation Danoise! The flash anims are really amazing.
Some quick thoughts about the proposals. Will get more into detail later:
About the Instrument patterns:
This should go into a separate topic. Both features, the arranger/zooming and the instrument patterns can coexist without each others, so I think it makes sense to break down the discussion about this into a separate thread/proposal. Discussion threads easily go messy, so lets try to at least split the mess.
The feature itself rocks and was already discussed in various topics here. I dont think that anyone would not love to have this Also this is BTW how I imagine a Renoise VST plugin should look like: A light version of Renoise with no internal sequencer, just acting like an instrument that can be triggered from the Host…
About the Sub-Line Zooming:
Here I am with you and have no doubt about the feature in general, but there are a lot more details to be considered:
-
Speed vs Ticks:
Speed simply doesnt make sense in such an environment, as the duration of a tick (sub line resolution) changes with the speed. So the reslution should be expressed in a new way: TPL (Ticks per Line). -
Automation of Speed/TPL:
Automation of Speed (or later TPL) is and will be possible, so we have to deal with this. This makes the whole thing a lot more complex. This is especially a problem when not displaying the full zoom level (displaying each “tick” per line). -
Dealing with tick related pattern commands:
Commands like pitch up/down, retrigger, note delay (and others) are applied per tick, not per line. Assuming you can enter pattern effects (not only notes) on a tick level, how should they be translated/visualized/applied in detail?
In your proposal you simply do not allow FX commands per tick, which is of course a solution for the problem, but also very limiting. But let me stop here andgo more in detail about this later (with a complete list of the FX and proposals how to deal with each command).
Some further thoughs/ideas:
Beside the “global” zoom level, it would be nice if one could show/edit only the ticks of a single line. so that you dont have too zoom in/out all the time when you just quickly want to edit the volume of a note in tick 2. This could be done by adding small [+] icons next the the pattern line number (beside having shortcuts for this) which would then expand collaps the whole content of a line - independent from the global zoom level.
About the “Arranger” Zooming:
This is a tough descision. Your proposal makes “visually” perfectly sense and is more or less self explaining, but I am not really sure if a dedicated arranger view (as the one shown in Pysj picture) would not be the better solution for the problem.
Horizontal Arranger pros (as proposed by Pysj):
- It helps you to edit/see the whole thing in two separate modes. You either want to edit clips/content or arrange them.
- How usefull are the intermediate zoom levels? Wouldnt you anyway end up in zooming out and out and out before actually using it?
- Your arranger must be vertical, while a vertical arranger has some big problem visualizing text / wastes more space: To be able to name the clips whithout drawing text vertical, the clips have to be very width, which gives you less overview.
- Are widely used, so most people simply know how the thing works.
About the continous pattern editing:
What you want here, is basically using one big pattern instead of being able to reuse existing pattern, right? If we have an arranger, this of course makes sense, but we IMHO still need pattern boundaries as patterns is what editing with keyboard shortcuts makes so easy now. The freedom you get when vanishing them makes other things a lot harder.
I’ve said this here again and again: Everything is possible - this is software. Let the tech details be my problem and concentrate on the features itself here only please…
Second that!
And that is exactly what I have tried to point out here In a bad way I guess.
Because the way I see Danoise propose his idea, they are not acting independently (the clips and the instrument-patterns)…
So I have tried to point out that they can coexist totally independently…
That would be splendid, and expected really from such a smart program as Renoise
No more speed command voodoo just to get some more temporary resolution (right It-Alien? )
I agree… It would be a shame to remove the pattern structure.
For the convenient navigation part of the pattern structure we have now could easily be replaced using markers in the ‘one large pattern concpt’. But for the content of the pattern there really is no replacement. You could of course bundle clips between two markers and define that as a pattern… but more mess IMO.
If you really want one BIG pattern, you should just make one
The drawback of not using one big pattern is to deal with clips that cross pattern boundaries. We have discussed that quite a lot in the past. And as far as I can see the simplest solution to that is to be able to unlink individual tracks from the pattern copy/paste system (you kinda make it possible to make single tracks use the ‘one big pattern concpt’, and instead have options on how boundary crossing clips should behave when copy/pasting/altering entire patterns). But I wont go into that here now…
I agree with taktik’s considerations, including the greetings to Danoise for the great visualizations!