Hey, I said drama, not flamewar I do know that this simply an important topic for you. It is for many people, so it is for us. My only concern was the way of proposing your “ideas”, not the ideas themselves.
We knew we’ll get velocity and sample multi-mapping for 2.7, so we needed more space for the key-zone editor, especially in height. The middle frame in Renoise is the only part which offers this, so it was clear that the mapping editor must go where it’s now.
If the mappings occupy the whole middle frame, there’s no more space for the envelopes & co in the middle frame as well, at least not next to the mappings in all screen resolutions. Basically there are two ways to show them then: in a new tab within the middle frame, or somewhere else. In a tab in the middle frame is not really optimal, because you then could not edit them with the mappings editor open. Have to switch around to often when editing an instrument. We already had some sample/MIDI stuff in an editor in the lower UI part, so we continued thinking about how to get it in there, while also keeping other future instrument editors improvements in mind. Instrument related editors also where spread in the whole UI: on the top/right for the list, middle for the big old editor, bottom for some sample/plugin settings. Because we already had some instr. setting in the lower frame, we thought about developing it there further.
Adding the envelopes&co to the lower frames allows us to:
- visualize the control flow better (input is left, right from it 3 tabs which show the generators - what gets “triggered”)
- make clear that envelopes/LFOs and co apply to samples only (envelopes do only show up for the “samples tab”). This was probably obvious for someone who has used fasttracker before, for anyone else it was not.
- we can make it a “modular”, open view analog to the track dsp’s at some point to satisfy the needs of better and more flexible modulation and MIDI input effects (arps, chord generators and so on). The lower frame view is fixed in height, but can scroll to the left/right (like the track DSPs tab does). So it can hold “a series” of variable elements/devices, an it describing it’s processing by the order of the elements/devices:
[MIDI input] -> [MIDI input processors (arps, chord gens, other MIDI “event” devices)] -> [Sample/Plugin/MIDI output generator] -> [Sample modulators i.e: LFOs, envelopes and stuff]
The “MIDI input processors” and “Sample modulators” should be small optional “modules” that you only add when you need them, just like you do with DSPs in tracks. So you can add as many LFOs, envelopes and stuff for an instrument that you want. The envelopes and LFOs we do have now can also be deprecated easily this way, by only loading them for old songs. For new songs you better, newer “modules”.
So basically we wanted to make the instrument layout a chain of “modules” + wanted to describe the control flow better this way.
The bad side of this, is clearly the fixed height, which some “modules” will have a problem with. This also applies to some Track DSPs. Especially the envelopes editor, which needs more space to be edited comfortably. We also have no modulation devices yet, so right now the whole old LFO/Env. section is quite crammed into a single spot, single device, which is not optimal either. But I think this will work out later, and now at least removes a lot of other clutter, keeping all the various views of the instrument editors together and describing the routing/processing chain better.
The sample list from the top/right of the Renoise UI was removed, because:
- we wanted to tie the sample properties editor with the actual list of samples, so the list went down to the lower frame as well where you actually do set up/configure a sample. Before, you had to select a sample on the top right of the interface which then got editor in the lower tab. This connection was far from being obvious. Well, at least for everyone who has not used fasttracker before.
- we didn’t wanted to have two lists which more or less do/show the same thing. Removing redundancy.
The sample list on top still is useful while loading samples from the diskbrowser. So the downside of removing it there is, that we now have lost the connection there. I think we can solve this by making the list a tree view. A list of instruments with samples as nodes, which can be expanded when you need them to:
By default all is collapsed, so you only see instruments. If you want/need, you can expand the instrument nodes to see the samples it contains. Drag and dropping can be done in-between instruments to create new instruments, or within an instrument to create a multi-sample instrument:
+ Sample 1
+ Sample 2
We probably should have waited with the sample list changes until we have such a view. This was in the queue for 2.7, but we simply did not manage to add it in time. This indeed was a bad decision, but at least removed some more redundancies in the UI for now.
Could you guys please also explain more deeply why the sample slices are so unusable? Is it just about the missing destructive processing? Or is it the missing “per-sample-modulation”?