Yes, the functionality required for clip view is quite different from the pattern editor, and integration with all the shortcut keys might be a hard nut to crack. But I really don’t like the idea of adding more windows with new short cuts to learn, Renoise is starting to feel bloated IMO.
All I’m saying is I think people will have an easier time grasping “zoom out to clip view” and understanding the correlation between the clips and the pattern data they contain. Of course I have no idea how much impact it would have on the learning threshold for newcomers or work flow, but I think it’s important to discuss and not shoot down any ideas too fast.
What if you could open another pattern window on the other screen and set zoom level anyway you like?
Of course. But it’s hard to adapt suggestions to fit a framework that we don’t know much about.
And these suggestions would be a major overhaul of the GUI and other functionality, so I wouldn’t expect it in the next release… the discussion is more like brainstorming about the general direction, so taktik can take any interesting ideas into consideration, adapting the framework for the future.
Not sorry on my part, Renoise has never disappointed. Whatever is in the works, is probably better and simpler than anything mentioned here.
Personal note: I made the screenshots to bring discussion to a more practical level They can be thought of as a kind of “feature compilations”, trying to fit as many concepts into a single picture as possible.
A good screenshot will assist in the development of new features, not obstruct it, and having many different elements in a single picture will help the brain to understand the inherent complexities - complexity is good - it will eventually give birth to an organizing principle (chaos/order, you know).
BTW : I happen to be developing a horizontal timeline in flash. More info, later…
True. And that also partly why I have not put this into the Design forum just yet (but mostly cause the lack of time!) However, these large features are kinda complex beast to think through before we have settled the basic engine behind it first. With v2.0 some of these things will be much more clear I think, and we fully understand what is possible and not possible (to quote taktik: “everything is possible”… but I mean possible without recode the entire program). Now that a path for 2.0 dealing with timing/resolution and a more defined pattern engine (a timing/resolution design), then we can iron out the larger stuff IMO.
However, I’m not sure how much of this should be discussed in the open like we do internally. I mean, normally it’s the users that are gonna tell us how they want it based purely on user experience, and then it is up to the developer to make it happen. But in this case, not everything is possible within a reasonable amount of developing time I’m afraid (but what is reasonable is up to taktik in the end!).
Anyway. There has been nothing new in this thread since the start of it really I don’t blame ppl for not reading 14 pages of rather complex information and expect them to come up with something new.
And it’s been discussed quite a lot internally too.
So you are right. It’s about damn time to get these things into the Feature Design forum. Because now we are basically just repeating ourselves, and talking about the same things in 10 different ways.
Exactly! So we want more screenshots/flash and any crazy idea from you all that might pop up in your head.
Pictures and stuff are especially useful to simplify your ideas and very quickly give you an overview of the workflow behind the idea. It’s not always extremely useful for the developer, but it sure gives him options and most important it is very effective to generate new ideas.
The ideas/brainstorming about an arranger indeed exists as long as Renoise exists. I can actually remember adding an arranger was my first idea when I started to extend the old NoiseTrekker sources.
There has been done a lot of work been done in planing, yes, but nothing is really settled. If it would, you would already see it implemented.
As Pysj already pointed out, we currently take care of the speed/resolution issue. This is a fundamental thing which IMHO has to be solved before putting another level of complexity with the arranger on top.
So, yes, we still need your help with the Arranger!
I dont fear the coding, I fear the concept which is still not yet settled. Yes, even after 12 pages in this forum topic and all the years I still think we are not yet ready and don’t know what exactly we want/need.
You dont need to know about any Renoise internals. This is a ideas & suggestions forum, not a “how can we code these ideas & suggestions” forum. I say it again: Everything is possible. If there is codebase missing for something we want as its THE solution for the problem - not a half-assed compromized solution that maybe can be done in half the time, well, then we have to implant this codebase first and then do it.
We are not in the situation that we have customer that bought features that have to be ready in a strict timing plan, so we dont have to apply all the limitations that are implied with this way of working. Do you want any Arranger or THE Arranger?
Now thats something. Thanks Danoise!
Most of my concerns are already pointed out by Pysj, so let me go a step back, trying to organize things a bit:
We first need to decide some rough guidelines for an Arranger before going into the details. Basically there are 2 ways of integrating such a thing into Renoise:
2b) As proposed by Pysj (and others). We add a new arranger on top of what we’ve got now. This would be a new tab like the mixer which simply allows you to arrange the components we already have now. it would be a dedicated view with its own shortcuts and editing methods.
Both have their advantages and disadvantages, so I think we should continue the discussion by splitting it into two parts. Discussing each alternative in detail, then choose the best of the two at the end.
So how to continue with this arranger topic?
As said above, I think we need two separate designs, one for 2a, one for 2b, then finally !unpin this messy thread! and go into details in the feature design forum.
Danoise: May I aks you to take care of putting your Idea into the design forum? You would then be the main responsible for that idea - leading the discussions.
Pysj: May I ask you to do a feature draft for 2b?
Most important is IMHO, as Danoise did it, to start with a graphical overview of how this would look alike. This is the easiest way to give people an impression of your idea. Then details should follow in text form.
The details could be discussed in topics within the Feature Design forum.
Sorry, bit harsh of me, but you have had 5 years, loads and loads of suggestions, loads of pictures and a stickied thread with 12 pages in.
Seriously, I wish you luck with this, and I am sure the user base will be really happy when it comes about. I didnt mean my post to be offensive, just a sarcastic dig more than anything.
Sure I could, and already have. As you should know
I’m not sure how much more it is to be said.
I can for sure try to organize what really have been said in this monster thread about the arranger into the Design Forum.
Danoise and others that already have and are willing to put an effort into this are more then welcome to get a more specialized task to maintain in the feature design forum (not just the arranger).
Now, the thing is that both 2a and 2b are essentially the same, just one is vertical and the other is horizontal (however, like I have pointed out, if you just switch coordinated on 2b you have basically the same editors.
2b would have it’s own button/window while 2a probably would need some 'clip-view/edit switch and zoom presets.
The advantage of 2a is that you can instantly in the very same view and zoom level (while you track) see the clips there and move the clip around. So this is very good if you quickly wanna move the current clip you are working on a few lines up or down or to another track etc.
The downside is that if you wanna do some overall arranging then you have to zoom out very much. When you do that there is not much point in doing tracking stuff there because of the low resolution, only clip stuff. And the fact that you have to collapse tracks to get it compact enough, and you need new functions and keys to edit clips, will essentially make this arranger a 2b arranger.
The advantage of 2b is that if we later allow to see several windows at once, then you can bet many ppl would like to see both the arranger and the pattern editor at once. This is more clear for the user what window do what, then to for instance spawn another pattern window (allow several instances of the same window), although that would also be very cool too, but for other reasons…
What I was hoping for (and what me and martinal talked about from the very beginning in this thread (and in private discussions) is to have both ways possible.
Even if we make a 2b, i see no reason why we should exclude 2a completely. Perhaps then the 2a should never collapse, but keep the track width and always show pattern content. This way you use 2a for micromanagement of clips (no need to zoom much, or to zoom at all), and use 2b (could be optional vertical/horizontal) for larger structure arranging.
When dragging a clip from the cliplist into the pattern, I would expect that to work. But I would also expect to find a arranger window somewhere (2b) where I can use the same list and drag/drop clips into that.
About 1 vs 2. Thats all fine by me to choose 2.
However, the problem is ,as always, pattern boundaries. Number 2 will not allow clips to cross pattern boundaries without first freeing that track from the pattern system.
We have discussed this thoroughly internally before many times. I think that is the only option without starting to overlap/hide clips etc.
But thats just fine with me. Some tracks will then not be copied/pasted along the pattern system. Most people will probably keep clips within pattern boundaries anyway. Those who like a more freely approach can just ‘unhook’ some or all tracks from the pattern arranger system.
About not mentioning the word ‘code’ in here. Thats easier said then done. As you pointed out yourself, it’s hard to discuss details when we still are discussing/making the very platform for the discussion.
This can get even harder in the Feature Design, because some of these things will make us have to redesign a hell of a lot… not impossible, but almost.
Thats partly while I have not set things up in the Feature Design just yet. And I still have a few technical questions for you that I’ll ask internally first.
After that I’ll start setting things up in the ‘Feature Design’.
But you are right, I should not bother other with any code stuff, and limitations of this or that. And certainly not talk like I know anything about coding
I’m curious…how will this affect Renoise - will tick-based pattern commands have increased accuracy?
Sure thing. But please confirm with Pysj that he is OK with the way you defined “his” arranger concept, as I was with “my” concept.
And thanks for stepping into the discussion
Edit: Well Pysj replied just before I did - reading his post now…
It seems you and I agree that 2a and 2b are simular concepts (that’s 2a in a “zoomed-out” view). So, I’ll try and keep my ideas relevant to a horizontal arranger as well.
A question: when dragging a clip onto the arranger, are you suggesting that clips are stored in the same place as the instrument-table? If so, would it be intuitive to drag clips using the mouse? For example, instruments are not draggable in this way, even though they conceptually are simular.
When going with the concept of “the pattern editor == the arranger”, keyboard would of course be fully supported, and the benefits obvious: using the keyboard is faster, and more flexible (you have all the “notes” to choose from, when entering a clip). I’m not saying that mouse usage is bad, but it’s not good enough to have a 100% mouse-based solution, and I personally find it hard to see a keyboard-based solution that isn’t based on the well-known pattern editor shortcuts - why come up with something new, when we’re already dealing with 100’s of keyboard shortcuts?
Concerning pattern boundaries:
I think the problem is reminiscent of audio streams. So, perhaps the solution should be as well: that clips are simply “able” to play, even if their triggering point is in the previous pattern? A kind of “look-back” mechanism?
Yes, they are very similar. But unlike many might think, I’m not so sure one rules the other out.
I think there might be room for both (with a purpose for doing so!), but with slightly different functionality.
Let me put it this way, single samples are not in the same instrument list either (you have to map them to a key in an instrument first). Yes by default they get autoassigned. But each and every sample do not necessary have it’s own instrument slot.
For the very same reason I think we should have a pool of these things outside the instrument list.
Then it’s up to the user to map clips or any other element any way they want (put them directly into arranger/pattern editor, or put/map them on keys in an instrument.
I made a draft of such a pool a long time, this was more aiming at renoise instrument structure:
Same picture, but the list only (many things have ‘changed’ since this old mockup though…
You drag drop any element into the instrument key/velocity mapper to create different type of instrument.
Clips as well.
I also made some mockups about a separate arranger. In these pictures you only see the list/pool of elements, and not the instrument list (the upper frame is hidden on these pictures)
The list you see can also be used to 2a. Drag/drop directly to pattern editor.
Of course everything is possible to do with keys.
In a 2b concept I would think you only press tab to switch between list and arranger window. Then use arrows to navigate. Simple as that. Pressing enter insert clip. A toggle to be able to play a clip using your keyboard (bypass the instrument list, but thats another story that is not as easy as it might sound, this might not even be possible).
Before we have designed how instruments will work in the future, we can not decide if/how clips can behave as instruments, and thats the ‘flaw’ by having clips always in the instrument list.
There are also two ways a clip can be in an instrument. You assume that we will see the entire clip in the pattern editor if I press a note with when a clip is in the instrument list? Or do you assume I will only see a single note for that instrument (that will play the clip).
Either way I would prefer a separate pool/list for everything and make it optional to automatically insert every clip into it’s separate instrument (if that was even possible).
Also… if I do lot of long recordings from someone playing the guitar for instance, those audioclips I would not have to put into a instrument. I could just drag/drop it directly to a audiotrack.
Other would like to f*** it up and adds it to a new instrument right away. It’s just a thing what ppl is used to. And how to organize everything.
Also in addition for note clips and audio clips we had plans for automation clips and perhaps fx clips.
Nothing you should be forced to trigger from instruments I think
That was not the issue I was referring to. The problem is when clips are longer/stick outside pattern boundaries.
What should happen to the partial clip that is ‘on the others side’ of the boundary?
If I have a pattern 01 that got one of those clips going into pattern 02, what happen to the part sticking into pattern 02 when I suddenly remove pattern 01? Also, what about colliding clips? etc etc.
It’s a long discussion about this very early in this thread. And has been ‘processed’ even more backstage.
For now the best solution I think is to simply cut clips at boundaries, but get an dialog when you change patterns that make clips collide, and one of the options is to detach the track entirely from pattern arranger (content in those tracks will not be copy/pasted or moved when you change anything in the pattern arranger).
These things would not be a problem in taktik nr 1 solution for arranger. But for nr 2 this is the reality.
I never though so, but maybe I have misunderstood something in Danoises drafts. Beside that the one is horizontal and the other one is vertical, Danoises arranger never really leaves the pattern editor, or? So the workflow, which tools you need, how the keyboard handling works and so on must be very different?
Wasent the step wise zooming also one part of Danoises draft. Then the shortcuts and tools also have to change depending on the current zoom level?
But decide you both if its worth to do 2 designs or not. Also a big thanks from me to bring this topic back to reality!
OK, so I just made a new design forum topic - Zoomable Pattern Editor.
But let’s keep this thread going - there’s still some cross-pollination going on!
For example, clips are essential to both of our ideas. But they are still not clearly defined…
In terms of screen real estate, a reworked instrument table could suffice, I think. It could hold all sorts of content, as your screenshot depicts. As for waiting for instrument specs to appear - why? I mean, lot’s of people are really pouring some good ideas into this, which are all based on existing instrument capabilities. Some of the ideas, like “instrument patterns” were conceptually the same as a clip, and, IMO, there would be no need for such a thing if clips were introduced.
Now, I would really like to see Renoise have a very sophisticated way of dealing with clips, it’s one of the major things to happen for this tracker (for me, it would have a bigger impact on my workflow than the arranger). And we could easily make a specification fully portable to any future implementation of the xrni instrument format, if features were to be kept sort of “generic”.
Here’s some (ambitious) ideas for clip-control, it’ll give you ideas:
Clips can be pitched (relative basenote) per instance
Clips instances support a subset of commands, such as the offset command [09xx] or playback direction [bxx]
Clips can be single-shot or looped (relevant when a clip instance is longer than the clip duration)
Clips can have various trigger modes (such as mono, poly, or a simple arpeggio)
Independent tempo setting using speed multiplier command
Yes, I imagine my screenshot as being the pattern editor all the time, with (mostly) identical keyboard shortcuts, but perhaps you didn’t notice that this picture had room for the whole song inside a single view (the highlighted numbers on each side of the editor should indicate the active pattern)? What I did was to take the “continuous” mode to it’s fullest
I will post any and all information to the Zoomable Pattern Editor thread, once I get around to it.
Yes. You would have to change the behavior of things in the pattern editor when you wanna edit the clips directly there (2a). A “clip edit mode” if you like. Thats exactly what would happen if you switch to a 2b arranger as well. So this is more like talking about different “view presets”. Then different concepts.
Horizontal: More compact with readable names (remember not everyone only use 6-7 tracks in their songs, in addition we have other clips as well, like automation clips etc).
Vertical: if you don’t change the track width when you zoom out to “clip edit mode”, then you instantly are familiar where you are (you see the zooming etc).
If it was up to me, I would have both options. I could like to press a few modifier keys or a toggle in pattern editor to enable “clip edit mode” to very quickly move clips around (no zooming etc needed).
If I wanna do some serious arranging with lots of tracks and automations clips, audio tracks etc etc, I would not mind at all have a separate arranger window for that task. Then I don’t care if I ‘lose visual focus’ from the pattern editor.
Yes of course. Who said you can’t do that?
You would then add clips inside a instrument. But that is optional. And require us to finnish/change the new xrni concept first. Then you can trigger 10 clips at once if you like by pressing trigger them with notes.
But as said, there are two way to do this think of this:
Lets say I have a note-clip
called “Note clip 1”
it looks like this:
D-3 00 5C
Off – –
E-5 00 48
Off – –
Lets say I add a “Note clip 1” to instrument slot 01 (by default this clip will then be mapped to all notes C-4 note as base).
Now lets make this clear:
Do you mean that when you now press C-4 on your keyboard, that you will see:
C-4 01 – ← this note trigger the sequence in Note clip 1, but you don’t see this clip in the pattern editor, instead you see it in a separate clip/pattern editor in the instrument it self).
Or do you mean that I will insert the complete sequence directly in the pattern editor when I press the C-4 key:
D-3 00 5C
Off – –
E-5 00 48
Off – –
Lets get this straight first so we know what we are discussing here :=)
Now if you meant the first options, then that is what we have discussed quite much in the RNI future thread (and even more backstage). And of course you can use this way to arranger stuff more like (buzz style) etc. (If this ever will come true that is).
If you meant the other option, then yes, i agree (and also suggested that) that you can use the keyboard to insert clips directly from list into pattern editor (also transpose them that way, but to put other fx on them without encapsulate the clips into a instrument first (first method), we need to discuss far more).
But you do not have to put the clip to a instrument slot to do the basic insert/transpose (could be done by a checkbox in the list to use keyboard to insert/transpose directly).
You did also not take into account automation clips and fx clips for instance?
I see no reason to waste instrument slots on them. (there can be a hell of a lot clips you know!). And does it make sense to have a automation clip in a instrument slot anyway? If it does, I still think that should be optional
Thats why I want all that to be optional and by default separate clips from instrument list.
No, on the contrary - I imagined that the clip could be composed of several different instruments. It would be really hard to make a rhytmic sequence composed of just one (multi)sample, I’d rather be able to make use of whatever samples I want to.
Yes and no. Yes to working with clips in the pattern editor using clip trigger notes. No to a separate editor. Editing could be done on the spot simply while in edit mode (and affect other instances in realtime
To support the more advanced stuff (trigger modes etc.), an extra panel could be added next to instrument settings / automation / song settings. But things would work fine without that.
I did a rework of the instrument table.
Samples should be listed too, forgot to add that.
It’s now the song resources panel
There’s a search filter, and perhaps the space for dragging the clip could even contain a tiny preview.
Clips are identified by name and color, both possible to change.
Mate, I was just about to post the exact same thing.
IMO it’s very simple. You arrange patterns like Fruity in a block (pattern) vs time graph. Each block represents a pattern (which includes automation). This way the pattern editor is not linked to time, moreover it is simply the ‘clip pool’. The current system allows great flexibility, but a simple ‘arranger’ overview (like Fruityloops) allows easy macro-level song structuring. For me at least, the most important thing is being able to arrange synchronised patterns in an intuitive and ‘global’ way.
I’m sad to hear Taktik disregard the option #1 completely, because I thought I showed in my post that both worlds can co-exist perfectly. By keeping the restriction of current patterns and clips being unable to stretch outside the pattern boundaries, you really change nothing to the current workflow. Music (my music, at least) will still be ‘blocky’ and repetitive, which I tried to avoid by proposing the detached from patterns way of sequencing…
Well, regardless of the approach, I can’t wait to see first (any) results!
They can be thought of as a kind of “feature compilations”, trying to fit as many concepts into a single picture as possible.
I don’t blame ppl for not reading 14 pages of rather complex information and expect them to come up with something new.
