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


(joule) #21

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.


(Raul (ulneiz)) #22

@joule, sure enough, I was writing down exactly that right now.


(taktik) #23

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.


(ffx) #24

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? :smile:

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.


(joule) #25

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:

  • using customized F9-F12 navigation keys (jump to 1/4, 2/4, 3/4 of the current beat in a long pattern)
  • old style patterns can be used as scratch pads (notes)
  • pestering the forum with requests about optionally changing the left line numbers to beat/measure indications, or other visual cues.

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? :slight_smile: