Remove pattern boundaries for automation (or patterns in general) and instruments (bind each track to an instrument)

ffx · April 28, 2019, 11:06am

If I was asked (I know I am not),I would consider the last, “doubled” point in the automation lane as conceptual flaw, since it leads into a lot of nonsense. Instead the automation lane should always look into next patterns next point. Ok there are pattern boundaries, who btw. actually needs to repeat a pattern using the same pattern number at all?! Still only have 64kb of RAM?

IMHO remove pattern repetition possibility at all (only keep numbering for comfort reasons, but not editable, auto increasing), remove vertical aliases (it is not that hard to use shift-f4 / shift f5), make automation drawing and handling boundary-less, make a linear representation of the song position in the api, not caring for patterns at all, then people can easily adapt their tools to make it work boundary-less and also Renoise internal tools easily can adapt, like adv. edit.

Since talking about removing not helpful complexity: Then remove instrument numbers, and the instrument list (or make it a track overview instead), put the instrument into the track chain at the left position as in Bitwig, then the instrument device also will be the automation device, no more cluttering or possible use of multiple autom. devices or on tracks not related to, etc.

Then remove all old versions Renoise backwards compatibility (people still can use Renoise 3.11), remove all “old mode - want to convert?” - behaviour (but no need to remove old dsp, doesn’t hurt), only one time write a 3.11->new version converter / song import so old songs adapt to the new structure, without any option. This to unclutter the amount of code. (Of course keep ft2 / protracker import).

API would break a bit, but also not that hard to fix for the tool devs, and in the end, it will be a lot more easy to use.

Super Renoise geeks gonna hate me now.

LofiMat · April 28, 2019, 11:33am

neinMC · April 28, 2019, 12:34pm

Who needs to lack the ability to repeat patterns if they want to for some reason? Still can’t use complex software?

I love the idea about looking into the next pattern for the automation, but everything beyond that is unnecessary to implement that, and seems pointless by itself.

For what? “Let’s change something for no benefit, so everybody can easily adapt their stuff to it” Any helpful ideas on how to get BER airport done, while you’re at it?

All my no for this. “no more cluttering or possible use of multiple autom. devices or on tracks not related to”, what keeps you from not putting things where you don’t actually want them? What is the “etc.” supposed to expand to?

ffx · April 29, 2019, 9:25am

Look, just that you understand what I meant, which you didn’t seem to. I overlooked the live mixing / performance ability above, but you still could highly unclutter Renoise from programmer’s side, while keeping all performance possibilities intact:

Repeatable patterns could be internally replaced with the alias mechanism. No need to keep both.
A non linear or non virtually linear sequence brings a lot of complexity to tools, pattern selection even to internal Renoise functions like the advanced tools: So the Renoise devs did not make it work across pattern boundaries, because they prevent to make a decision, due to their self created conceptual dilemmas.
You could also replace the pattern repetition and alias mechanism with phrases. Then all would make sense from programmers view, since phrases are nested into instruments now and it is no spaghetti order anymore. If you would use “make alias” on a pattern, renoise could create phrases of the tracks, place the trigger note on each pattern. Then you could even make aliases independent from pattern boundaries.

I can, but I also know software which is more capable and also more easy to use, because of a better thought, more strict concept. Also it was not about users view, but programmers view.

neinMC · April 29, 2019, 12:28pm

From a programmers perspective, what are concrete examples where this is a problem for people who make tools? Where have the Renoise devs said this is something that hinders them in any way, that it’s the reason we can’t select across patterns for example? It’s not that I find it impossible to believe that’s true, and I haven’t even looked at LUA/xrnx stuff in years, but “less clutter” is just so generic, you know? All the tools you say could be easily be updated, how many of them are still developed… will you update the others?

ffx · April 29, 2019, 1:49pm

Just use advanced tools, move a note sitting on the last line by one line to the bottom: Nothing will happen.

Select an area in the pattern, can you move it across the boundary? No.

But I get it, you are trying to compensate your lack of imagination and understanding with pseudo rhetorical questions.

No, I will not update your tools, don’t be so lazy.

neinMC · April 29, 2019, 2:49pm

But I get it, you are trying to compensate your lack of imagination and understanding with pseudo rhetorical questions

They’re pseudo rhetorical alright, as in not actually rhetorical ^^

You mentioned convenience for the programmer, not the user. I’m absolutely for being able to select and shift things across pattern boundaries, but I wouldn’t just assume that Renoise is lacking this because we can repeat patterns in the sequence editor, so I just don’t see the connection between these things and your proposal, and that’s why I asked if there as any concrete reason for you to suggest this. Same with tools.

I simply haven’t paid attention for a long time, and I actually searched topics with “across pattern” to see if I could find anything related to the issue you claim exists, but no luck.

No, I will not update your tools, don’t be so lazy.

Well, the tools you suggested to break. I asked for the concrete benefit, more than generic stuff like “less spaghetti”, you know, maybe a code example. You say I just ask because I lack imagination, I say you just delude yourself into thinking I lack imagination because you lack a straightforward answer

Yes, I’m lazy, but since I still haven’t gotten around to updating my old tools to even the current API, for me it makes no difference, I’ll wait out the next Renoise version either way.

Raul · April 29, 2019, 2:52pm

Just use advanced tools, move a note sitting on the last line by one line to the bottom: Nothing will happen.

I guess it depends on how it is programmed. In fact, this should be integrated into Renoise. It is only necessary to program it.

ffx · April 30, 2019, 6:04am

Yes, and all this would already work since a decade, if the song was a linear representation in the api. So what prevented to make tools working boundary less? Ah, maybe it is because it is a pain in the ass to handle those boundaries without a linear abstraction!

Yes, thx Raul, also what happens, if the next pattern is the same pattern (since this is possible)? This is what the developers consider a reason to make it NOT WORKING AT ALL.

That’s why I suggested to consider any pattern / track repetition possibility (too raw anyway), and e.g. use phrases. Then the api would a lot of more easy.

Stop to confuse your brains with unnecessary complexity. Stop to trip over your own feet.

ffx · April 30, 2019, 9:15am

I thought it is very obvious, but ok, here a pseudo code example.

Let’s say we want to add a simple note echo with 3 lines delay to a track over 10 patterns in the sequence.

It would look like this with the current design:

-- at pattern boundaries, note echo is not added
-- you may get nonsense results, due repeated patterns
-- cur_line index is resetting to 1 for each pattern, as we are used to it

local start_sequence_num = 10
local used_patterns = {}
for (seqnum = start_sequence_num, start_sequence_num+10) do
  local patnum = RNS.sequence.get_pattern(seqnum).num
  for (linenum, cur_line in RNS.patterns[patnum]) do
    local cur_pat = RNS.patterns[patnum]
    if (linenum < cur_pat.length - 3 and used_patterns[patnum] ~= true) then
      do_3line_delayed_noteecho(cur_line)
    else
      used_patterns[patnum] = true
      break
    end
  end
end

With a linear representation:

-- cur_line index is increasing all the time, not jumping back to 1
-- echo also appears across pattern boundaries

local start_sequence_num = 10
local cur_line = RNS.get_sequence_at(start_sequence_num).get_first_line()
-- cur_line.index would start at 1280 with a constant pattern length of 128
while (cur_line ~= nil and cur_line.get_sequence().index < start_sequence_num + 10 and cur_line.index < RNS.num_lines - 3) do
  do_3line_delayed_noteecho(cur_line)
  cur_line = cur_line.next()
end

Raul · April 30, 2019, 9:19am

With linear do you mean that the index of each pattern is always the same as the index of the sequence?

I recognize that to create tools, the fact of having a “variable index” is a bit more complicated to program (instead of using a short code, we have to use a slightly longer code). But deep down, it’s just about using the right index. There is no more problem.

Being able to repeat a pattern countless times can be useful in a very specific case. When you know that you are going to need to change pattern data (notes, effects, automation), and you need to change at the same time in all those indexes of the sequence. That is, you only change the data of a pattern, not the data of several duplicate patterns. For other cases it is practically useless to use the same pattern.

The second utility is to be able to change the order of patterns in the sequence. This is also quite useful.

It is possible that the main problem here is that users find it too difficult to “duplicate a pattern” by making a jump in the sequence. But in practice, it can be even faster than changing an index in a box. In fact, it is even advisable not to duplicate patterns, to favor the variety in all the sections of the song.

But deep down, if the API were simpler we could do the same as what there is now. It would not change anything, since the patterns are still “a separate thing”, regardless of the pattern index you use for each index of the sequence.

Each pattern is like a page in a notebook. You go to the next page, and you can number it how you want. In the API, all you have to do is use the pattern index correctly for each sequence, both for the pattern editor, stop the Matrix and for the automation editor. I know that in the API it is a bit confusing, but if you use it well you will not have problems.

But yes, everything is improvable, like passing data from a pattern to the next pattern. For example, the previous image capture is a very common correction operation. If you record live notes, it is very likely that some notes end up on the last or next to last line of the previous pattern, when you need that note to be on the first line of the current pattern. If you do not have a tool made on purpose, Renoise is a shit for this.

And now if you look at the automation editor everything gets worse. Editing points in different patterns is uncomfortable. It is a too basic editor, I mean the handling of points in general, creation of ramps and others. But maybe the problem is not “the indexes” but the design used for the user to control it.

By the way, the API has much more serious problems than this. Rather, it lacks certain skills, such as differentiating between different mouse buttons (right button, middle and left). The easy possibility of combining commands with the mouse (CTRL, ALT, SHIFT and their possible combinations, together with the mouse). By adding these details in the API, it would be easier to move data from one pattern to another with your peripherals.

joule · April 30, 2019, 9:25am

Pattern boundaries and API never been much of a problem to me (I never dealt with automation though). In many cases, you can easily extend Renoise classes to provide what you need.

I would suggest you add .line[global_line_index] to renoise.Track if you want a simpler song-wide access+iteration.

(“Unwanted” behavior might occur if you use repeated patterns, but imo the user assumes responsibility if they want to do something like that. Seems stupid to add a restriction by removing them.)

ffx · April 30, 2019, 9:28am

Fine, then keep your nonsense repeatable patterns. Actually almost no tool at all is dealing with pattern boundaries. Just a reality check, why do you think this would change in future then?

joule · April 30, 2019, 9:31am

What do you want to do across patterns (except automation)? I can think of nudging and anything dealing with voice handling.

I agree that “pattern wrap” should always be available where appropriate. It’s not difficult, but maybe scripters are a bit lazy.

Then there’s always patterniterator available., but sometimes has a bit too much overhead for my taste. Maybe best is to make your own iterator with a different syntax, line_iterator(track_index, from_pattern, to_pattern, from_line_index, to_line_index). Not too hard, and seems to allow very simple coding.

My experience is that once you start extending the native classes with what you need, the code becomes much clearer. Make objects provide the information you need, and scopes and syntax will just fall into place

Raul · April 30, 2019, 9:51am

Well, speaking on this subject, I only miss a very specific thing. I put here the steps, because I think a lot of people miss it:
1 Select an area of the current pattern that contains notes.
2 Press and hold the CTRL key.
3 Drag that area with the mouse into the next pattern, or within the following patterns.

Step 3 is not possible. Renoise should be able to jump between patterns while dragging a specific area with the mouse. The same thing happens in the automation editor. All are “too isolated” patterns for the meticulous edition. I do not care about the pattern index, I care that these things are possible. And I suppose that with the current design it is possible, it is only necessary that @taktik (or some subordinate employee) programs it. This implies that part of the area remains within the previous pattern and part of the area remains within the current pattern or following patterns (depending on the number of lines of each pattern and the number of lines in the selected area).

I call this problem “the corseted pattern.” Edit things within it, but do not make several patterns in a row as one. This is one of the things that can be improved by the pattern editor and the automation editor. But calm, now someone will come and say that everything is perfect and that you do not need to change / improve anything. But before changing anything in the API, these cases should be resolved under the hood, I think.

Edit: Has anyone tried to select an area in the automation editor and drag it with the mouse to duplicate the points or drag them? I wish @taktik would come and say, “Let’s make that possible, and we’ll do it among patterns too.” Dreaming is free.

taktik · April 30, 2019, 10:54am

@ffx the ideas all make sense - in general - but it’s unlikely that you’re going to find a lot of people here that are willing to change Renoise from the ground up - completely. You also seem to be quite frustrated about how Renoise works and what Renoise is in general.

So why don’t you take the chance to either start a completely new tracker project on your own, or look for a project on github and co which isn’t that old and mature as Renoise is? It’s a lot more likely that you can realize those ideas there. If it helps I could even contribute to such a project too.

ffx · April 30, 2019, 2:31pm

Thanks for your reply, @taktik. I am not a genius like you, programming a whole daw like tracker, even for cross platform. I am also not frustrated very much about Renoise, only about the current bugs for me as macOS user, just to make this clear. Maybe my tone is sometimes a bit negative, but it is mainly because of the bugs, that often sum up here, and maybe because of the usual answer style you get in here, if you mentioning any kind of critics or frustration.

This only was about “how I think it could be better for all in the end, if there were resources and motivation to do so”. Maybe I only love some other specialities about Renoise than the vast majority like about it. And there are a lot.

And since there already is Renoise, it would be somehow nonsense to me to start again another tracker project, that most likely will never reach the level of quality Renoise already reached, thanks to you. Maybe think about that a bit more, if you ever decide not to continue with this project.

I don’t expect this to be changed. So I am fine with your decisions.

LofiMat · April 30, 2019, 4:56pm

ffx is a good dude with his own unique thoughts. at sometimes maybe a little diva - like on the forum but also always acurate and sympathic as a whole. and I am also fine with taktik’s decisions whatever they will be.

Raul · April 30, 2019, 5:49pm

I have to rectify this situation. From Renoise is possible to drag or copy selected areas between different patterns, but the user must use the mouse wheel to jump between patterns in the pattern editor. Then, it is possible to move an area or copy it (clone it) between contiguous patterns or make jumps, with the trick of the mouse wheel to change the pattern.

It is even possible to move the mouse wheel in the sequence to make larger jumps between patterns while the user is dragging the area. I do not know if this detail is in the user’s manual, maybe it’s not very agile but they are very useful control tricks.

Where it is not possible is in the automation editor that is where there are still more shortcomings.

Obviously, the user can use the keyboard commands to do the same. But with mouse control it is desirable that it be as easy as possible to do this operation. With the wheel it is a little complicated. There will be many users who do not even know this trick.

Edit: By thoroughly testing this, in the pattern editor you can only copy one area between patterns, but you can not drag an area from one pattern to another, because it will copy it as well. I had not realized this detail until now. Maybe it’s a little forgetfulness or bug under the hood.

Steps of the problem:

Select an area that contain notes.
Drag this area with the mouse wheel until the next pattern.
The result es a copy-paste not a cut-paste.
The desired thing to drag is a cut and paste, not copy and paste.

Edit2: In any case, it is not possible to drag an area between two contiguous patterns, divided this area into two parts.

ffx · April 30, 2019, 5:55pm

Also actually - if you or anybody had the motivation to clean up Renoise from conceptual view - I think that the api v5 could be adapted fully to the new structure, and nothing would break at all. For API v6 though, there were then a lot of reduction and simplification. I think in the end, v6 would greatly win. A win-win situation.