what about 2 softwares?
Renoise and Renoise arranger: that would prevent renoise to become a huge fulloptionned labyrinth.
And a renoise arranger would be a soft dedicated to mix tracks from different rsn files and ability to use as live station (as in ableton but with patterns from different xrns files instead of loops)
Nope, it gives you new and better functionalities. Things that you can not or is very cumbersome to do in the pattern editor.
I can make a list of what that could be, but please, there already is a huge pinned PR thread here. So fight there 
It would never ever be implanted as some sort of eye-candy. Functionality has the priority no matter what we implant. The problem is that you can not expect everyone to use all functions in a large and flexible program like Renoise.
Even the old 4 track trackers everyone had their own workflow… thats just the way it is.
And again, renoise is 6-7 years into being much more then just a tracker… Funny how that tracker-banned word ‘Piano Roll’ upset ppl 
But of course if anything like that would be implanted into renoise we would look for ways to make it fit and complement the rest of the program.
Bloating is not the number of functionalities, bloating is to add illogical features that does not complement the program in a new and better way. And even worse to add things that gets in the way for the already good working elements.
I said NOTHING of editing patterns side by side … I said you could place them side by side in an arranger… big difference 
I just think the added tools that this clip idea may be a bit in vain when you consider the fact that if we treated patterns as parts that could be layed on an arranger, then the whole clip concept becomes moot… clips really seem nothing more than a roundabout fix to a nonexistant problem.
As for instrument patterns, why not just have a dropdown in the instrument options that allows you to select a pattern number to use? poof… instrument pattern UI problem solved! 
No need for a separate editor… no need for some obscure clip structure… just plan simplicity. Renoise, although much needing new features, needs to keep those features as simple, and integrated into the current paradigm as possible, as Icarus was trying to point out.
Edit by pysj: crap I pressed the wrong button, nothing changed!
Summary of this discussion
After months of work, I finally managed to complete the feature design for the zoomable pattern editor.
Holy shit that’s awesome!!!
This is not the idea Psyj had 5 years ago, let’s discuss how we can make this awesome thing that everyone unanimously responds to with great enthusiasm into the idea from 5 years ago. And by discussion, I mean parallel monologues.
So true, but so fun.
Just out of curiosity - was it discussed here / decided when is this zoomable feature going to be implemented? I am assuming the “if” is no longer a question.
And how will it look like (in the maximum zoom out) when there are no colored clips?
VERY curious, VERY enthusiastic (as instructed…)
hmm… It was at least not my intention to sound like such a arrogant wise guy…
Glad you are entertained by it then 
No, no one is against Danoise’ work and ideas here (must be icarus then who seemed to be very skeptical about the whole thing? 
)
It’s more about small details we are discussing here. I’m pretty sure Danoise is with me here.
I’m just pointing out possible problems with the concept. We agree pretty much with 95% of things.
Pysj,
I certainly did not think you or anyone here is being arrogant, everybody has their own way of pointing out stuff, but I guess this comment was not meant to me and that there is more “behind the scenes” of this thread that I am unaware of, so I will shut up in this regard (better late, right? )
Now dont get me wrong - I am not skeptical AT ALL. I feel very small when seeing what the Renoise guys are doing with this application, and I am not saying this lightly.
The only reason I felt compelled to throw some words here, is that I would very much hate to see it become “just another sequencer”.
I gotta tell you, when trackers went bankrupt, and there were no alternatives, I was miserable.
I sat in my dark blue-walled room, staring at the oh so very ugly Cubase and cursed Windows, cursed Jeffrey Lim for not continuing IT (after I bought the WAV writer…) and cursed all the Windows wannabe-trackers for not understanding what a tracker is.
So, Renoise is my Polar bears I guess. Protect at all costs…
Hey, np Icarus! I’m not very serious here 
And believe me, I’m also horrified by some cumbersome features that many other sequencers (like cubase) have. Its like you feel sorry for the guys using them sometimes
You are of course right that we should not aim for ‘just another sequencer’.
We can do it much better then them
And of course every feature in renoise is and always will be based on a ‘trackers point of view’.
Thats why we for instance talk much about putting these things into the instrument structure etc.
It’s more like tracking you instrument etc.
But enough of this, lets get back on topic 
Bloody hell. This discussion is awesome on a level i don’t dare to partake in.
I’m convinced, whatever comes is going to be good. Whatever it is. And that’s all i need to know to sleep well at night.
Kudos danoise, and everyone else doodling. Mental.
All looks pretty good. And I’m glad to see someone considering incorporating a piano roll editor. I know it isn’t the way tracker users work, but Renoise does tend to incorporate a lot of different ideas. After all, vst’s never used to be in trackers. So I think it’s great to have it there, as long as it isn’t intrusive to the hardcore trackers. And I’d love to see this idea of zooming go on to include a higher resolution.Better for live playing. It would be nice to be able to play and edit a midi keyboard performance as easily as I do in cubase, energy-xt, sonar etc…
Yeah, that’s great that the topic is back again live & kicking.
I got one question though, I couldn’t find an answer for anywhere and I haven’t thought of in my version of arranger. If clips are supposed to be just pattern data, will they also include effect commands? If so, what about effect commands that change DSP / VST settings? As I understood, clips can be placed anywhere, that is also in different tracks - that would imply, that if pattern command in particular clip changes e.g. parameter #2 in effect #5, then in one track this might be filter type and in the other size of the reverb etc.
How can this be avoided? Should we leave the effect-specific commands out of the clip and thus force automation of effects from automation windows if one wants to use clips? Or should we leave it like that, because it could facilitate for some cool random mistakes? Or maybe we should make clips bound to particular track?
BTW, I’d really love to see more taktik’s input here - what are the chances of implementing any of this and - most importantly - when? What’s planned for v2.0?
cough
Cover your mouth when coughing on the Internet 
Im am following every single post here, dont’t worry. Its just that I can’t/don’t want to be so active here, because I also want to do other stuff beside reading/writing forum posts. Also we are already discussing the mostly technical parts in the small renoise-dev team.
We’ll get an arranger some when, where some when is > 2.0 - thats all I can promise - sorry. There are sooo many useful features in the que (and already done for the next release). The arranger is just one thing of many. I know how important this is for many of you, but we also have to prepare the rest of Renoise to work with/in an arranger for example.
So please continue with this and allow me to watch this thing more from an outer perspective. All the discussion here helps the internal development - thats why we have this suggestion and the design forum…
can’t wait to beta-test!
Hi Antic, I’m glad to see you around!
I’ve come up with the idea of ‘dynamic parameter’ linking, which will allow you to assign clip automation to parameters. But I honestly haven’t thought about effect commands, thanks for pointing that out!
I’d definitely prefer that effect commands were consistent with curves. So if we chose to stick with the dynamic model, clips could be playing in different tracks, and automatically re-assign automation data. In the same way, effect commands could rewritten on-the-fly. The clip would of course need to remember these settings per track, but that’s what dynamic linking is about.
We might be able to keep things simple, by allowing clips to reference only their own internal parameter list? In my screenshot, there’s two parameters assigned to the clip: cutoff and resonance. This might indicate that we are controlling a cutoff parameter, but actually, it’s just a name given to the automation data (since the curve was originally designed for controlling a filter). So we could assign the ‘cutoff’ parameter to whatever effect (reverb size) if we wanted to - and, simularly, reference the ‘cutoff’ parameter inside the clip editor using familiar hex notation.
What I have suggested is to split clips into categories.
-Note clips (notes and instrument number and other note column data)
I made a couple of pictures how this could work:
Pay attention to the top left buttons in the clip arranger window.
You see 4 buttons there.
When 4 is enabled then any clip category not currently shown will also be
edited (copy/pasted/resized/etc).
So if you for instance set it to only see the note clip, then you will also edit the
hidden automation- and fx clips at one go.
In the header of the automation clip ‘arranger track’ you can add another device
parameter to be shown (you currently only see ‘Cutoff’ and ‘Reso’ from a filter or
something in this picture. You can also see there is a ‘node’ there so you can
expand/collapse to layer all automation/device parameters so you can edit all at once.
Another cool feature could be to be able to drag a bundled/layered clip back
into the list. This would then make a clip with a [+] in front of it. So you could
then keep clips layered all the time if you want.
We could have options to automatically keep for instance note-clips and fx-clips
always bundled etc as this heavily depends on individual workflow.
For the FX-clips I really cant see any easy solution. I don’t think there is nothing
we should do about it either.
If you use specific device commands there, then you should just leave those clips
out when arranging, or fix/edit the content of the clip manually after you have
moved it to another track. There is no point of reassign those commands to new
devices, I guess?
This is at least a very flexible and working way without big changes I guess.
A more drastic change is to restructure the command/column system so
that pattern commands pointing to devices will act like the automation does.
You have dedicated columns for each parameter. And the dedicated column
is linked to the automation (showing the same data).
That’s how it currently works, if you control a filter using 1010, 1014, 1020 …commands, and then decide to change the order of the DSP device in the chain, effect commands are maintained. Pretty cool, actually.
pysj : you don’t like the idea of dynamically linking automation parameters?
yawn
…