Feature Design: Zoomable Pattern Editor Discussion

Ideas & suggestions
41

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):

  1. It helps you to edit/see the whole thing in two separate modes. You either want to edit clips/content or arrange them.
  2. How usefull are the intermediate zoom levels? Wouldnt you anyway end up in zooming out and out and out before actually using it?
  3. 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.
  4. 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…

42

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…

43

I agree with taktik’s considerations, including the greetings to Danoise for the great visualizations!

44

Thanks! And that goes to everybody.

It was a bit of a drastic choice, yes, but I knew how complex it would be. Still, I think even patterns with differing ticks/tpl values should be possible to visualize simultaneously. As for “limiting my imagination”, that’s how I work. Instead of making a imaginary mock-up of something which would require a lot of changes “under the hood”, I focus on improving the interaction using current functionality in Renoise.

No, you got that wrong. I love the pattern arranger, and use the shortcuts all the time. With continuous mode, patterns would still be patterns, shortcuts would still be the same, but editing would work slightly different, to achieve arranger-like functionality. Anyway, I don’t see it as a wasted effort as any arranger implementation would need those features (such as the “Auto-clone” functionality for editing across identical pattern instances)

Perhaps the horizontal arranger would be more intuitive, simply because of the fact that it’s such a widespread visual model - so perhaps me and Pysj should team up for the arranger feature?

45

First of all, it’s not like the vertical arranger is not being taken into consideration anymore!
We just have to point out possible issues with it. And the technical issues with pattern-zoom has been quite heavily discussed internally. So taktik will hopefully announced some info about that soon. And after that, together with some other ideas, there will be more to be said about the arranger.
It’s a bit soon I guess to go into details about how the arranger would technically work or even how it should look. For now it’s more about the overall picture like if it should be horizontal or vertical, or if it should be separated into different windows, and how it will fit together with other parts of renoise that is still yet to be made (like you tried to do).
So please don’t let all this talking stop you from adding anything you might come up with to develop your concept further.

46

I CAN HAS TEH CLIP THREAD? xD

47

Superb concept work!

"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):

  1. It helps you to edit/see the whole thing in two separate modes. You either want to edit clips/content or arrange them.
  2. How usefull are the intermediate zoom levels? Wouldnt you anyway end up in zooming out and out and out before actually using it?
  3. 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.
  4. Are widely used, so most people simply know how the thing works."

-Tactic

My 2 thoughts on the horizontal vs vertical.

Another point:

  1. Widescreens are also common.
    Though it will be common to be able to turn the screen 90 degrees.

  2. What about context sensitive buttons?
    When the user zooms out the arranger buttons/menus gets visible. The same for the + signs, they are only visible when mouse over or when the line is selected, this way the screen is not cluttered up with + signs.

  3. Not very, just skip them and only have the usable zoomlevels.

  4. Thats valid point…

h
a
r
d

t
o

r
e
a
d
?

4 Despite that I still think it makes it way more intuitive to go with vertical.
I think Renoise gets more messy with half of the things horizontal and half vertical.

I would stick with vertical…Vertical pianorolls too…

I also serves to make renoise “stand out” which could be a good thing.

Why not make it possible to have separete views of the pattern editor/arranger open, like in paint apps where you have a zoom window.

This way one could work with a zoomed in and a zoomed out view at the same time.

48

I’ve had this idea ever since I read that some ppl have trouble with pattern/instance concept. There could be a switch button (placed somewhere close to followpattern switch & co) that could be called Continuous Edit On/Off. What it does is pretty simple. When it is on, each time you start editing a pattern that has more than one instance in your song, a new pattern will be automatically made out of it, with your new edits, leaving all other instances the way they were.

I think this gives the commodity of ‘continuous edit’ logic, while being easily implemented into current logic.

49

I think I wasn’t being clear enough about the description of continuous mode as being “one big pattern”. For all intents and purposes, that’s what it would act like. But with the additional “auto-clone” logic in place, and the keyboard shortcuts still usable for pattern navigation etc. Just to clear things up!

About the ‘subtick’ mode: while the folding/unfolding of lines, zooming etc. are not hard for me to visualize, it’s another matter with the “what is possible and what isn’t”. Taktik, you state that anything is possible. So, having a separate pattern command for each and every tick would be feasible? And similarly, how about multiple notes in the same row/note column (say, one for each tick)? And how about triggering more than 12 instruments simultaneously in the same track? Currently, AFAIK those things aren’t possible (except that workarounds exist: you could have multiple notes in the same row, by distributing your notes across multiple note columns, of course).
I’m asking, because such limitations aren’t limited to just subtick editing, but would affect any potential pianoroll implementation as well - it would also need to conform to some well-defined restrictions.

50

About the ‘continuous mode’ you talk about. Is that not almost like making the current pattern you are working on unique? Thats a function we already have.

btw, something you see on my picture that I did not mention is the linked clips.
You see a little symbol in the down right corner of the clip (look at the loop1 clip for instance). That means that the clip exist in several places in the song. So if you edit that clip, then you will also edit some other place in the song. Just as you have ‘make pattern unique’ function, you also have a ‘make clip unique’ function.
When editing in the pattern editor, this symbol could appear on top of the track in the track header (like the automation symbol) so you can become aware of that you are currently editing a linked clip.

When it comes to other editing functions involving several patterns, I would much more prefer to set this ‘continuous mode’ to the selection of patterns you make in the pattern sequencer. That way you can make smaller patterns act as a one temporary big pattern.
This way you can select data crossing/continuously between patterns you have selected, without disturbing the entire song…

About the sub-lines. Everything really is possible. It’s more a matter of backwardcompatibility and how much restructuring it would involve. But it is very possible :) And as you say, this is a decision taktik has to make in the end. But it is not like there has not been many suggestions and even very detailed suggestions and concept ideas for this. But that very technical data has been held internally for now…

The point in here is really not think of what is possible or not . So very technical data do not belong here. Even though that is a ‘rule’ that is very hard to follow at times :) But in the end it is all about what the user want that is important.

51

While “anything is possible” … I would presume that some things would not be possible in keeping with backwards compatibility?

Oh wait… I see Pysj just addressed this thought :P

52

Subtick possibilities can be resolved into these options:

  1. Don’t change data structures; tick-level editing is “illusory” but still made very convenient; or
  2. Give each tick its own full set of data: note, vol, pan, effect, and attach subtick timing data to every effect and note; or
  3. Store notes internally like MIDI events (i.e. do event X, in track Y, in column Z, on line A, in pattern B ). Abolish ticks internally. Renoise still looks like a spreadsheet, but it’s really not.

Options 2 and 3 are amicable to a piano roll, but Option 1 requires the least immediate work (essentially it is a hack).

Option 2 is still a bit “hacky” but at least it alleviates odd and seemingly arbitrary limitations as to what can happen at the subtick level.

Option 3 involves a massive change to the XRNS fileformat and possibly the playback engine (oh what fun). It also copes very, very well with changes to Ticks per Line (TPL) and is the most versatile. You could conceivably add more ticks to a single line of a pattern!

Option 3 would treat TPL simply as a “grid size” for the pattern editor, but not affect the data at all. If you change TPL under Option 2, you will probably experience data loss “between lines”.

EDIT: I kept using the word subtick when I meant to say “tick” (or “sub-line”). Corrected.

53

After years of spending on this messageboard and reading threads on speed, bpm and ticks etc. This whole tick phenomenon is still very abstract to me and vague. What the fuck is it, can somebody explain it so I can sleep well tonight? I think I’ve read the answer a hundred times before, but the explanation doesn’t stick :slight_smile:

54

Ticks explained briefly:

  • Speed 06 will offer 6 ticks per line, which translates to the initial note (with no delay) + 5 possible delay-positions, before the next line comes up.
  • Speed 03 is faster and will offer 3 ticks per line (initial+2 tick delays)
  • Speed 01 will offer only one line (tick delay have no effect, since song is running in full tick resolution).

Full explanation here: http://tutorials.renoise.com/?n=Renoise.RenoiseSpeed

55

Ok, that was simple and clear :slight_smile: cheers for the link.

56

Yeah, but it has no brains. Continous mode would cause it happen automatically, whenever needed (for some examples, see the delete, drag’n’drop, insert row, etc. animations featured in my design proposal)

That is unnecessarily complicated if you ask me. Just treat clips like instruments, and you can use advanced edit, copy/swap clip references etc. Have a separate clip editor, and you can even set it’s length (!).

What’s disturbing about being able to access any part of the song? Still, if selected pattern(s) in the pattern arranger were somehow highlighted in the zoomed-out view, that would be a good thing (I’ll make this so, in next revised screenshots)

I’d go for the second option. My previous sketches were based on the first option, but let’s see how option 2 will turn out

57

What brain do you really need for this? :)
You already have functions now like ‘make all patterns unique’. I mean, this HAS to be in the decision of the user.
It’s just a matter of having the habit of making cloned (unique patterns) when you insert a new pattern from the beginning. And this default behavior is already changed for the next version of renoise.
And so should the clips act in my proposal. The user should choose if the clip should be unique or not.
This should not cause any problems as by default all clips and patterns created would be unique. You must from now on actively make a linked clip/pattern (reuse of the same clip/pattern, its like copying a file vs making a shortcut to a file).

I see no problem doing DND stuff over patterns either way when in continuous mode.

Ok, so you still base your idea that you must use the clip arranger as instrument notes that represent the clip data? So you must edit each clips in separate clip-editors, and not directly side by side in the pattern editor?, Well I’m strongly against that, and don’t see that coming really.
IMO it should be up to the user to decide if he wants to use it as a instrument or not.
And btw, you can edit length of clips nondestructively on my picture as well.
I’m not sure what you meant about clip references in the advanced edit?
I’m missing something here? :)

I’m not sure you did get me there? I’m talking about the current pattern sequencer we have in renoise. There you can highlight/select patterns. My suggestion was that IF you mark any pattern there, then you will see that selection act as one big pattern in the continuous mode (if non/all patterns are selected then you will see the entire song act as one big pattern in continuous mode.
You are then ‘merging’ together your selected patterns temporary. You don’t see any good and flexible use of that?
However, why should linked patterns/clips be auto unique in this mode? As I said earlier this will likely be no problem for new users because of the new default clone-behavior.

58

I like pysj’s idea for the continuous mode only enabling when you select multiple patterns… perhaps the selection should be made with the pattern loop selection instead of the normal pattern selection however… I just wonder how it would handle duplicate patterns in that instance… would there be background colour coding to warn the user that changing the current pattern block will affect other blocks in the current selection?

As for the clips, I’m still waiting for this to be broken off into a separate thread but I’ll say this much: I very much want to be able to change the pitch and tempo of the clips nondestructively… an “instrument pattern” would do this… would your proposed idea allow that too pysj?

Glad to hear that the default pattern add functionality is changing… I constantly wish it would add a new blank pattern instead of just adding the same pattern number again.

As for marty’s subtick possibilities, I’m going with #3… simply because I don’t see a reason to limit the engine because Renoise stemmed from old software. We can still have perfect timing whilst also having floating point precision. Even if we go with the limited tick zoom, we could store the data in a less spreadsheetlike manner.

As for ticks, I don’t see a reason to abolish them when going for more resolution. Ticks can still be used as a measure of dividing a note, so as to keep tracker commands working. We could simply have a new default mode where the ticks don’t affect the speed of the song at all, and a legacy mode where they do. (stored in the song options of course) … something tells me we might have something similar right now, but I’ve never checked into it :P … either way, my thoughts still stand.

59

That could be… It’s a little less flexible, but perhaps easier understandable?
I guess if the block-loop would also change according to this ‘fake’ pattern length, then that should work too I guess.

I suggested that it should. Especially if we also involve clips into this. I suggested a ‘link’ symbol in the header of the track. But that is perhaps not enough? What if that symbol became red when in edit mode?

Yes indeed, but that would be an entire new feature. This would then be done in the instrument it self (called instrument-patterns).
So by default you can not do this. Clips are just blocks of data (like the multi clipboard you have in renoise now). When you insert a clip in the pattern editor, you will see all the raw data. To threat it as an independent clip that have properties like an instrument, you do that in the instrument itself.
You will then not see the raw data of the clip in the pattern editor, just a note from the instrument. To edit this clip you do that inside the instrument in it’s own clip/pattern editor).

You can of course easily drag/drop clips from the clip list into a instrument in the instrument list.
You could have functions like converting a selection in the patterneditor to instrument-pattern:

D-4 01 0901  
--- -- ----  
F#4 00 ----  
--- -- ----  
Off

Mark this in the pattern editor and rightclick and choose convert to instrument-pattern:

C-4 02 ----  
--- -- ----  
--- -- ----  
--- -- ----  
Off

A new instrument was made containing the data from the selection, then the data was replaced by a instrument note.

So doing this we can have both ways. But they are totally different features really.

Let me also point out that we could have advanced options like add a normal clip to the keyboard directly as well (monophonic). So when this function is on, and you press a key on your keyboard, then you will hear the clip transposed. But the difference is that you insert the raw data into the pattern editor, and not a single note. This data is raw and do not have other instrument properties though:

Pressing D-4 in this mode would insert the raw clip transposed to D-4 (using my first clip example will become):

E-4 01 0901  
--- -- ----  
G#4 00 ----  
--- -- ----  
Off
60

Hi Pysj, good to see you alive and kicking!

No, I don’t think so. When you enter ‘continuous mode’, you leave some things to be handled in the background (especially, taking care of auto-cloning patterns). It’s all about bridging the gap between how traditional, timeline-based sequencers work, and pattern-based ones like Renoise.
So, if you were to produce a very basic song with the same pattern repeated X number of times, all of these patterns together form a song, even if it’s just the same over and over again. If you then, like in my drag-drop animation, tried to move a selection from one pattern into another, the auto-clone logic would come into action, and produce the following result:

1: The pattern from which the notes were (re)moved is made unique
2: The pattern into which the notes were dragged (inserted) is made unique
3: The rest are left unaltered

This is about making Renoise (more) accessible to newcomers, and, at the same time, making the pattern editor capable of being an arranger as well.

So I’ve heard, and it’s a step in the right direction. As always, development is walking the thin line between intuition and efficient workflow :slight_smile:

I’ve got an idea, inspired by how Photoshop work with ‘slices’. The problem with what you suggest is, that having all notes automatically converted into clips will produce A LOT of clips, making it hard to navigate. So, what if only the ones that were actually named/assigned a color would turn up as ‘registered’ clips? The rest would remain anonymous, and only appear in the pattern editor (perhaps as editable ‘gray’ blocks). I think that would solve the problem.

All I suggest is that clips are triggered via the pattern editor. However, clip ‘instrument’ numbers are kept separate from ‘real’ instrument number - so the clip note C#4 would not be the same as the instrument note C#4 (and you would always know, because of the visual appearance, shaded background etc.)
And since any clip ‘trigger-note’ has such importance (it will determine the clip playback sequence and/or basenote), it should be the one exposed in the pattern editor, not the embedded notes in the clip. I’m guessing that for an average workflow, the actual contents of the clip isn’t modified very often (which is why it was made into a clip by the user in the first place!).
A separate editor, visible alongside the pattern editor, would also make it really easy to select & modify clips while being zoomed out.

It’s simple - if clips are inserted into patterns just like instruments, advanced edit could be used to remap, transpose, etc. Basically anything that it has to offer.

To be honest, I’d rather see an option to ‘actually’ merge patterns together with a total length exceeding the current limit of 512 lines.