I don’t understand what do you mean? The envelope section is still there, just located in different place (instrument settings window on bottom bar). It might be a bit tedious to go to, but it’s functionally the same as it was before.
I think renoise might need is some input from usability expert. What I have found is that some of the changes have made renoise bit cumbersome to use, and I don’t see an easy way to fix them either. There isn’t really a defined Standard Workflow for that kind of software anyway: Renoise GUI strays away from regular Windows/Mac usability guidelines, basically defining it’s own. Everyone has based their own workflow around that and if you change something in Renoise, you end up breaking someones workflow.
Maybe someone could analyze what there is and define some new guidelines to follow, to make dealing with new features easier. But who that someone is I have no idea. Cause as said before there are many ways people use this software and not really one unified way that would make everyone happy.
Hey, I said drama, not flamewar I do know that this is 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:
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:
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”?
a tree view would be nice, but you suggested it earlier so I am patient on that one. But it is a very good idea . A single button to select all slices in the instrument would be very nice too.
About the sample slices, the destructive processing is indeed what is missing, I would like to ask if render to slices in instrument tool could go native.
For future, maybe it would help to divide renoise into “sections” which could be movable in a way the user wants them to be - so if someone would decide to have envelopes and automations in the lower frame he may, but if he wants to focus on them more and move them to the middle section he can do it as well… with this kind of modularity, you could have a default layout as it is proposed by creators now, but if you want to do some changes you will be able to. Maybe having arranger in an upper section instead of the left section may be helpfull at times… (but that’s just an example) Renoise already works in that way somehow, with the different screens (f1,f2,f3 etc) so perhaps just extending this possibility would help for users (also at least some degree of resizing the sections would help too) atm the lower section is indeed a bit too small for high resolutions 1920x1080
what i would like to see layout wise would be some “rack” where you could view the dsp chain from the mixer next to the sequence for example etc…
i understand this may be too major change
about the meta slices, indeed I think the problem is that you cannot acces them and edit individually… for example when i’m working on drums i like to cut the breakbeats and then treat the hits individually, process them / change envelopes etc, then resample it to another breakbeat again and continue in editing, sometimes you need to do this process in few rows until you are satisfied in result, if you use a slicer now, you can basically just use the original sound, or process the break as a whole which won’t give you the same result. - if there was a “render instrument from slices” option it would be great. Personally I think slicer executed lots of ideas that were proposed on forums and I’m glad it’s made, but this render option is missing a lot for me.
@B-Complex: just a single request. could you please not quote an entire post just to reply to it? in the cases above taktik’s comments have been huge, and there was absolutely no added value in quoting them completely. you could’ve just done @taktik or something like that and it would’ve been clear, especially since you were the one starting this topic so the main conversation is between you and him (or so i feel).
about the Sample Slicer: are you saying the absence of a single ‘render instrument from slices’ feature is the reason this entire thing is useless? there must be more to it than that, right?
Not completely true, although it’s not as easy as it could be.
You can highlight a slice by Ctrl+DoubleClick. Then Process FX, Smooth, DC Offset, Reverse etc etc etc only apply to the selected area and it is fairly quick.
I don’t see why, when viewing an individual slice (EG when Auto-Select Played is on) it is greyed out and you can not edit. Maybe force the length to be fixed but you should be able to do any other process from the view on the individual slice IMPO!
I really don’t get your aversion to the Tool that does this, which has been pointed out and mentioned multiple times in this thread! Sure I agree there should be a native option but this really does suffice in the interim.
I don’t think tools should substitute for crutial things like this, if there was no “render vsti to sample” etc tools that are native it would be probably stupid to ask - also rendering sequence to sample etc - it is already
native process within renoise , so why not with slicer ? i don’t get why not ?
Yes and the amount of threads that have asked where this functionality and been pointed to that tool we can hope it will be added in a new release. Tools are not meant to replace Renoise’s native functionality but can provide access to something that wasn’t thought of during the development phase of a release and popular ones may find their features added in a later release. No need to repeatedly whine about it in the same thread where a perfectly suitable workaround for the current version has been pointed out to you.
If not necessary, it should in doubt not be destructive. As Kazakore pointed out, you still CAN edit the original and thus also the slices, and once you “render” slices down to real samples, you can’t edit anything fluently anymore.
But hey, if that’s such a big issue for many people, making the whole feature “totally unusable”, then we should try address this and allow rendering slices without tools. I doubt that alone is the problem though, because you can workaround this. Maybe you simply have no need for the feature in general in your workflow?
Another related feature, that was asked for many times (and which also got realized as a tool) is the ability to write down the sliced instrument into the pattern as a starting point for slicing up beats in the pattern.
As useful this is, the main reason we did not added this, was that it’s hard to integrate into the instrument or pattern workflow. Where would you look for such a feature? In the pattern editor’s context menus, somewhere hidden in a sub menu? In the sample editor? You don’t see the pattern, don’t know where it gets added in the pattern when invoking it from the sample editor.
If anyone has an idea how to properly integrate this and how to “name” it to make clear what it is, then I’m all for this as well…
Why make it so that you can’t do this from the view of the slice? I can understand (to some extent) locking the length of the slice ones it’s created but applying effects and the like I feel should be allowed, especially as you can via highlighting. (Although an option to unlock slice length would also be appreciated at times.)
Some kind of slices instrument creation/editor tool could be nice. Ability to drag and drop slices into different positions, copy paste and repeat them, auto-generation of slice markers if a piece of audio is pasted within the main sample. Generate from a list of samples (create a long sample of them pasted to each other with slice markers between.)
I do understand this may be a headache to many and possibly not get much use though so definitely not a request I would put high in my list of desires. Would enable the cutting and rearranging of breakbeats while being able to view the waveform and then still allow further mangling by triggering different slices of your rearranged break. The Ruler set to Beats would come into it own then for keeping you from going too far out of time (and would need the above mentioned ability to change length of slices) but I think it could give some interesting results and good groove
I would use the slicer as it is while i get my breakbeat to it’s final sound , but in the process i would like it to have this option, so that i can have more control in it, there would be no conflict in using the slicer as it is with the improved “cutting” option would it ? working on slice as an individual sample is sometimes necessary and it would be easier to do this with having it cut as a sample
i find the slicer to be good tool , because it can find individual samples much faster than i would by doing it one by one, and adding/deleting markers is also very handy, but in the end it won’t do what i expect it to do (natively) hence why i won’t use it in the end for this task
i’d rather see people going off about renoise-related drama than see no posts at all and everyone just being quiet about any issues they might encounter. I don’t think any of this has resembled a flamewar yet. yes the needless quoting is annoying, but that can just be edited out. I’m looking forward to the next version of renoise.
And B-Complex is quite correct that even tho tools allow us to have the “should-be-native-to-renoise” type features which the devteam hasn’t deemed worth their while to implement, the sliced sample to new samples should be native to renoise (much like expand + shrink shortcuts, more display on/off and saving of disk browser states (i have no use for Song in disk browser, yet it always defaults to that instead of samples…)))
The real problem is that Renoise is too good to not get passionate about it. You’re bound to have a bunch of people who actually use renoise and have developed a workflow, complain, when the workflow gets messed up, even for one version (I’m hoping the instrument menus will see updates in the next version(s)?).
let me make clear that my comment on B-Complex’s quoting was not out of annoyance, just to give a friendly pointer. the annoyance came when my friendly pointer seemed to be ignored . i have no real power here. you can safely ignore whatever i say and get away with it
I do know that this is 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.
