Let’s be honest, how many times do you really repeat exactly the same pattern (by repeating the pattern number in the sequencer) – TBH, I never do this, since dead repetition sucks and makes your track dull and less interesting. In reality you do repeat certain elements, but always vary a bit with something (beat, melody, fill-in, etc), so a plain repetition is (for me) never the case. Within the workflow of Renoise there is nothing to help the composer with this form modularity, on the contrary the workflow is still based on the good old Amiga tracker, where plain repetition of patterns is used to reduce module size. Which is cumbersome, especially when you want to change a beat in an existing song for example (you have to copy+paste it everywhere!)
I think this is really the area that Renoise should improve. The pattern matrix was a great improvement already, but what we really need (IMHO) is to turn this thing into more of a sequencer/arranger where you can arrange your various length tracks with line resolution (not pattern resolution, like now) – something similar to what Vastique posted before:
But then without pattern quantizing, so there will be no pattern borders anymore in the sequencer – it will all be lines (which can be zoomed out to birdeye’s view so you can see the whole song and all different tracks). In fact, the pattern idea will be history and perhaps only exists as indicator. Somehow this relates to the “clips” idea but then only basic functionality.
So, with my poor PS skills I created a mockup:
3253
Actually the new Aliases are exactly to help this type of modularity, where you may be varying some sections and not others or only want Automation to differ.
But that aside I like you idea a lot and see it as an extension/comment on the zoomable pattern editor ideas which have been discussed.
Indeed aliases solve that problem but currently still in a pattern mindset. What if your alias stretches over multiple patterns, or just a half? I definitely like the idea of aliases but it will be more intuitive when things were “broken out of the pattern borders” so that these “clips” could be aligned to any line. the same goes for the Automation lanes: You see with 2.8 there is a natural evolution to song wide automation display (zoomable), so why keeping the pattern border at all?
Yeeeees ! We all understand that when the first soundtrackers appeard in the 80ies, computers had a few kilobytes of memory, and game & demo makers had to find tricks to make long tracks without using too much ram space, so they made pattern repetitions easier. But today we’re working on computers that have a huge RAM size, and terabytes of disk size… nothing in common with the old amiga/atari st - systems. Repeating musical structures has no interest anymore, nor musically nor technically.
However, the pattern, considered like a regular framework, stays “usefull”, it acts like “temporal unit”, in which you have to define a beat or a melodic structure. When you’ve got this kind of temporal unit you’re helped as a composer.
So, even if I totally share your point of view about musicality, repetitions and the necessary variations in the listening esperience, I still need a pattern for other reasons.
I’d like to propose you something : what about a “boring tune detector” ? For example, we’ve got a function that deletes unused instruments or unused samples or unused patterns.
We should eventually, before the render to WAV exportation, create an analysis process, that detects for example too repetitive things, i.e. a 4rth pattern strictly similar than the 3 previous ones. It should display a kind of warning, a red light, with an alarm signal, a messagebox like “WARNING, your’re exporting a boring track”, get the picture ?
Nope. But I see the issue you have with the use of the term “pattern”; it is basically a naming issue. I would call that container a clip since it is of an arbitrary length, and IMO it doesn’t contain multiple tracks (it could contain multiple note bars though). This way the clips can still be aligned per track, and would fit in the current matrix without changing it too much.
I think you should see it as this: The pattern matrix will become ONE BIG ZOOMABLE PATTERN, containing clips that are aligned PER track (so they have to be single track for that).
I wonder if you need to name, as you can see the summery of note data and give them a diff color to identify a single clip. If naming is strictly necessary, I would go for 90 deg rotated, elipsized text. Elipsizing (for example placing ‘…’ in the middle or at the end of a text-string) is dynamic and based on how far you’re zoomed in/out.
As I said I agree with the general ideas, my point was just that Renoise has recently actually been introducing features which aim to do exactly what you claimed it didn’t (“Within the workflow of Renoise there is nothing to help the composer with this form modularity”). Sure as yet it’s only a small step but it seems they are moving that way. Especially if you case your mind back to the discussions when 2.8 beta first came out and remember there was apparently a big discussion during the closed Alpha about completely removing pattern numbers all together. This hints to me of movement in this direction.
I’ve considered this but I think we still need an overview Matrix (it is good to be able to see song structure alongside the note data itself at times.) Also having Clips isolated isn’t good either, you need to be able to view multiple tracks side by side to see their relation to each other. But without Patterns and clips possible to be different lengths where and now do you define this and when? Means you can’t just go to a point in the song and start tapping away/recording as easy, you first need to make sure there is a blank clip there, which you need to decide its length. Plus what happens to line numbers at the edge of the edit view? Guessed based on the Clip the cursor currently resides in might work… Between clips? Blank?
But these general ideas are what I’ve often referred to Renoise introducing a “true” Arranger feature and I hope it is moving that way and I trust that if it does all these considerations will have been thought of by the Devs and a suitable implementation performed.
In a zoomable clip editor you have by default lots of overview (You can zoom in/out by wheeling the mouse + holding down ALT-key for example). Starting a clip will just be a right click in the arranger where you select “insert a clip” from the dropdown. I reckon it is as fast as, or maybe even faster then navigating to the track in a certain pattern. By default the clip will be truncated to “pattern lengths” which is just a grid definition. Recording will auto extend the clip which solves the multi pattern recording problem instantly. Indeed, between clips there is nothing.
And as far as line numbers go maybe it’s time Renoise finally got a Time Signature/Measure section. Then it could show the actual Bars, Beats and sub-division (Lines or whatever if it becomes Zoomable) of the current position in Song. For main editor at least. If there was a separate Clip Editor then it could always start from 00.
Yes but imagine that a musician prepares an album of 14 tracks of 5 minutes, proudly and quickly composed with the help of the copy-paste function, so 70mn of a boring listening experience, right into the ears of friendship. You know what, those musicians will quickly lose their friends. Hopefully, a boring music detection system is a feature that should preserve friendship.
Patterns serve to divide time into smaller, manageable segments, a very good foundation for composing IMHO.
If the result is a boring tune, I guess it could be compared to entering straight notes on lines and wondering why they sound machine-like, rhythmically speaking. It’s basically a question of working with the software, and challenging your own habits (good as well as bad) .
So, as you might have guessed I’m personally not a fan of dropping the pattern system altogether, but I agree that it’s restrictive that you can’t have pattern-tracks of different lengths.
On a sidenote: a tool like Grid Pie is promising to bypass this limitation, enable this type of workflow. But as it’s not implemented natively it comes with limited visualization options - matrix slots, a track’s name, color, pattern names and sections are the means we currently have for marking up our songs and displaying their content.
Well, if the lemniscate symbols in the pattern matrix doesn’t give you enough sign of how boring or versatile your song is, then i could perhaps write a bore-‘o’-meter that counts the amount of repetative patterns or tracks and based upon the rate of repetitions gives the song a bore-factor and a description. The only problem is that the track-repeat factor which is indicated in the PM, is not available as an API feature, so that would take a little while (which i don’t consider my worthwhile) before such thing is whipped up using the iterators.
[quote=“Knetter”]
So, with my poor PS skills I created a mockup:
3253
I don’t like it if it means splitting all tracks up into separate patterns(as the mockup seems to imply), I think having all note data for a given time selection not disjointed into different windows is a big advantage of trackers. This is a lot of the reason I could never get into buzz and why I stopped using FL, I don’t feel like it makes sense to compose that way at all
Maybe its my own fault, but the whole idea of this thread was not to talk about repetition or something… It should be about how a better workflow and a modular approach could be achieved with the ideas that are mentioned earlier: clips/arranger/zoomable patterns should bundle their forces. Currently they are just dead topics in the pinned section. In the meantime Renoise comes out with workarounds (like the alias) while the real problem is to fix the 25 year old pattern paradigm which was designed for CPU/memory optimization not for workflow. I have tried to use all the other DAW (FL/Ableton/Cubase/Reaper) but still the Renoise vertical interface works the best for me. So maybe I’m not a “real” tracker user but I consider the pattern border not as pure tracker benefit and whish it could be different as I personally always bump against these multi-pattern-bound issues during production (and I think a lot more people).
Some powerful ideas here, but I’m sorry to say I’m of the old paradigm: just put the hard yard (the work) into making all the parts unique. And depending on the style you are crafting sometimes completely robotic repetitive things are just perfect and need to be drill drill drilled. The current system doesn’t hold me back at all - it’s simply up to me to put the work in. So get to work!
Have you tried buzz? I haven’t used it since development resumed but I think it’s kind of what you’re looking for, it’s even modular in it’s approach to chaining instruments and effects as well as having a playlist fragmented by instruments
I would also disagree that patterns are solely a CPU/memory thing, it’s just as easy to copy patterns into unique instances as to use the exact same patterns in Renoise, then from there you can make your edits easily enough. I rarely ever actually use the same exact pattern twice but I don’t feel like Renoise encourages me to do so anyway…actually if you’re only really changing one or two tracks it’s probably less work this way, rather than copying each track individually. That being said it’s all subjective, some people will like classic tracker style, some will like something more like buzz or FL. I’m just kind of against it in Renoise because I think it fills that niche the best at the moment, there are a lot of modern clip based sequencers by comparison.
! We all understand that when the first soundtrackers appeard in the 80ies, computers had a few kilobytes of memory, and game & demo makers had to find tricks to make long tracks without using too much ram space, so they made pattern repetitions easier. But today we’re working on computers that have a huge RAM size, and terabytes of disk size… nothing in common with the old amiga/atari st - systems. Repeating musical structures has no interest anymore, nor musically nor technically.
But I see the issue you have with the use of the term “pattern”; it is basically a naming issue. I would call that container a clip since it is of an arbitrary length, and IMO it doesn’t contain multiple tracks (it could contain multiple note bars though). This way the clips can still be aligned per track, and would fit in the current matrix without changing it too much.
tracker user but I consider the pattern border not as pure tracker benefit and whish it could be different as I personally always bump against these multi-pattern-bound issues during production (and I think a lot more people).