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.
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.
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.
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.
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
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.
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.)
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?
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 
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.
@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.
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.
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. 
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:
Edit2: In any case, it is not possible to drag an area between two contiguous patterns, divided this area into two parts.
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.
Interesting find. The feature is inconsistent though. If you do a normal drag (not ctrl), it will not remove the original selection data if you drag it across patterns.
It doesn’t need a genius for this, but just someone with a lot of passion and time.
It’s not. It’s the only chance to realise “really” new ideas.
We’ve got lynched for every single button or functionality that we dared remove in new releases. Backwards compatibility is not an option, it’s a requirement for a project like this.
Renoise is build on the base idea of trackers. Trackers are build on the base ideas of patterns. There was no graphical “automation” back then. Songs most of the time where build with the help of repeating patterns. So that’s where the idea of those patterns comes from.
Depending on how you use Renoise this can be really helpful, or a pain in the ass. In your current workflow they seem to be just limiting. Maybe because you started to get more and more into the traditional linear timeline workflow in other DAWs (Bitwig in your case).
It’s a good idea, really. But it will be frustrating to raise it here.
That’s why I recommended that your time maybe will be spent better in raising those ideas in a project which isn’t bound that much onto backwards compatibility. Take the best of the two worlds that you now know very well an combine it into something new, instead of trying to make one of them like the other one.
Removing patterns just in the Lua API isn’t really going to solve any problem either. The Lua API is a representation of how Renoise deals with stuff internally. It must be, in order to allow access to all it’s features.
But this doesn’t mean that you can’t build your own abstraction layer on top of this which allows you to do on some specific thing more easily. Just like joule said. One good example are the existing lua pattern iterators. They are doing exactly this.
Thanks, Taktik, for your detailed point of view. And if you say it is a good idea, I believe you. But the point for me is, that there already is Renoise and there also already is Bitwig. Both doing a lot like I ever dreamed of. And Bitwig is progressing steadily, so no, I wouldn’t start another daw/tracker project. I also have a bit experience with very huge, complex projects, and I know it can lead into lot of frustration, when you are not a very good salesman or don’t want to do the customer support/communication side of it, because of the complexity. So my project would maybe end up in a powerful result, but in a very autistic way. And TBH, I think there are enough projects out there like that. That’s why I like plugin dev, it is always a manageable size, and you also can sell a lot of voodoo and be creative on marketing.
Often you see that at beginning the creators of DAWs are very flexible regarding the base structure. Then later, even if times have changed, and much better, more modern concepts have arisen, often these people now do preserve the base structure of their work, and only adding stuff on top, so adding more and more complexity on top of an outdated base structure. I have seen this with Octamed, Cubase, Logic, Buzz… Even worse, there is a tendency to recreate old studio mixing concepts endlessly. So those agile liberals turned into ultra neoliberal conservatives, and the only goal now is to keep it like it always was. Maybe they just got old.
Bitwig really is trying to do different. They also remove stuff, if it turns out not to be efficient. It must be a hell of a lot of work. But these guys seem to found each other. So I always wondered why you are not there? 
If you say, you guys were almost lynched because removing stuff, I would say your analysis of the problem was a bit one-sided. Since you can change even the base structure without breaking compatibility. And there are always those conservatives out there, want to keep the same structure, because it is so painful to relearn stuff (including me).
I also suggested this, because I sometimes I have the impression that you are stuck in your own created complexity (and that’s why lost motivation in the past, too, next to other reasons). So I wanted to give you at least an impulse to maybe rethink your point of view in some regards.
As you of course know, a DAW is not just another software. It is more like an operating system, which a lot of working will be based on. That’s why it needs to adapt to recent time, staying flexible, but also stay compatible. I think Apple did it right in the past, throwing away outdated stuff from time to time. But now they are also throwing away very useful stuff, and not for sake of a better development experience, but for their very own autistic ideas. Windows is kind of opposite, you still can feel the dos core inside (even it was removed). Windows stays compatible, that’s true. But also is the worst example how to create a monolith, never changing, very, very outdated base structure. Like “all ideas already were thought”, which of course is completely nonsense.
So a general approach for a progressing, complex “OS” may be to reduce complexity from time to time, remove redundant structures, only keep the most flexible one. If you don’t do, you will end up like Microsoft or Apple (since they also adding lots of nonsense stuff on top lately).
FYI almost all people I was talking to, mostly on IRC, even wanted MORE change when 3.0/3.1 came out, not less. So from my point of view, I cannot say that Renoise users always want Renoise to be a better Fasttracker. Maybe those people just do not write in here anymore, or already switched.
Everything seems to come down to resources and priority. With smaller resources, it seems only natural to focus on ‘desired features’ rather than long-term structural changes.
Regarding patterns:
I also think the concept of patterns is a bit dated and flawed. Imo and optimally, patterns boundaries should just be an arbitrary way of visualizing the song structure.
Realistically, maybe it would be possible to let us have a try at a different workflow by allowing an “infinite” number of lines in a pattern? Single-pattern mode. Maybe simple operations would become too slow, like insert/remove line?
With such a workflow, I envision:
I could see myself tracking in that style, instead of dividing everything into patterns (not a big fan of the PM though). Let us have a taste and evaluate?