Brainstorming: Xrni Future

Ideas & suggestions
128

How about ADSR where A,D and R are envelope ranges of which duration you can manipulate, and S is S and can be turned off to make the envelope ADR. This way it would be possible to make any shape of attack, decay and release and still have the simplicity of ADR. The default would of course be simple linear AD(S)R envelope, so it would be as easy to use as regular ADSR.

If loop is enabled the envelope can become ADLR envelope. Then either then S controls the level of loop, or it has a separate setting, or loop level is controlled by envelope points. (I’m not for the last option, it conflicts with the idea of AD(S/L)R envelopes easiness.)

If S does not control loop level when loop is enabled it could be possible to set the S to anywhere in loop range to provide more flexibility. Or then it could be restricted to loop start and end points for simplicity. This would speak for separate setting for loop level.

On the other hand making S level control the loop level would make the envelope super simple and streamlined to use.

e_Okay I just read this again, and of course sustain level could control the loop level, because if sustain point is set within loop range, the sustain level control has no function - so it’s free to affect the loop range amp level, and thus affects teh sustain level too.

Then to have more control over attack, or any other range, the velocity could modulate the duration of envelope ranges.

One option for controlling envelope points with velocity would be to integrate the velocity settings for points to the graphical envelope view and show the settings on per-point-basis somewhere, like under the envelope. For ADSR envelopes I think y-axis velocity control would be sufficient. This would of course apply only to points in between the culmination points that control the shape of each evelope range. That way it would be possible to have for instance linear attack for low velocity and kind-of-logarithmic-like attack for high velocity, to provide one very simple example.

Simplified version of this idea would be that the ADR parts would have setting for curve shape, maybe velocity controllable too. This would mean easiness of use instead of control.

I’m just feeding this discussion with ideas. What do you think?

btw. Fladd, that snap is usually done with filter and amp envelope amount modulation working together.

129

Sure, the same automation should be applicable to the cutoff envelope as well.

130

Simple(ish) idea, although will be forcing Renoise to do more calculations and consume more CPU for each note played at anything but maximum velocity:

Each current Envelope becomes two envelopes.

You have one envelope for playing at maximum velocity (7F)
Plus another for playing at minimum velocity (00)
Both have to have the same number of points.
Renoise then will morph between the two, calculating mid values for anything played at anything but the extreme velocities.

Still wont allow easily for basic automation though, and if you just want to change Attack for the classic Electro House Bassline type effects then the easiest way will still always be an ADSR Envelope!

131

Hi everybody.

I did not read the full thread, but I would like to make a suggestion. It will be useful for me to have an automatic sample import tool to build instruments based on filenames.

For example, if we have these files into al folder:

stringA3.wav
stringA4.wav
stringE2.wav
…

It would be nice to see Renoise being able to load all the selected files and then assign the right note in the instrument arranger automatically (at least, the main note).

Regards,
Juan.

132

Can be done via scripting and sure it has been discussed. Not sure if anybody has actually created a Tool to do so yet though…

133

Hello, i don’t know if the subject has been treated yet, sorry if I make a doublon.

So, the thing is that one may have multiple instruments sharing the same samples, for example, multiple versions of an instrument with different envelopes and settings.

Then, one issue is that when exporting the instruments, it also duplicates the samples, which may be good in some cases, but also may become a bit huge in term of disk space if one has large sample libraries with multiple versions of the same instruments.

So, i thought one could imagine some kind of “meta-instrument” definition which would define an instrument exactly the same as an instrument, but searching for samples into folders shared by multiple “meta-instruments”, therefore reducing the disk space usage when backing up instruments.

Of course, one could still export an instrument as an independent and self-contained instrument archive, if one wishes, but also merely save instruments as meta-instruments with shared samples between them.

Don’t know if it is something that has already been envisaged yet, but i thought it could be useful, eventually.

134

I’ve read the entire thread. Originally to post about a feature I think is really missing:

1) Delay in instrument LFO

FT2, OpenMPT, Sunvox have it, IMO it really is a must have. I miss that feature almost every time I track a song with Renoise. I usually end up bloating my patterns with V commands.

Anyway, after reading the entire thread, I think one very nice feature would be, as already suggested:

2) Meta-device for instruments

This would fix #1 (although I still believe having a LFO delay built in the instrument envelopes is a must).

But it would also enable other really cool things, for instance by combining a key-tracker and pitch LFO one could create a FM synth (LFO modulating the instrument samples).

Some have suggested to go “modular”, but allowing meta-device in instrument would essentially offer that (to push the idea further there could be some “modular view” for those who like it, I for my part I’m happy with the linear rack view).

Now, I guess it would be a natural extension to allow:

3) Any DSP device associated instrument

I sometimes find myself in situation when I get, say a “Lead” track, for some patterns I want some lead instrument with a certain set of FXs, then for other patterns another lead instruments with other FXs. I usually create 2 tracks, but with #3 I won’t need.

All this would allow people to create really awesome native Renoise instruments… and happily share them. :slight_smile:

135

+1 For Dsp attached to xrni !!!

136

I would love it if renoise came with a General MIDI style 128 voice library. And have an option when loading up midis for the appropriate xrni to load for each midi ins.
With a nice solid standard 128 xrni library for midi renoise will have its own distinct sound when people load up there old midi files in renoise.
plus it will give the new user a nice library to work with on the get go.

1 Like
137

+1 for attack/delay on instrument LFOs
+1 for ‘meta’ instruments
-1 for fx chain attached to instrument; that is, i’d prefer the instrument+dsps combo to be saveable/loadable in another format. The separation of instr/track as it is now in renoise is actually one of the great freedoms as opposed to a lot of the pianoroll-type daws. let’s hear how the kick sample sounds on the snare track, etc.

edit.
+1 for fx chain attached, now i think about it. especially, many keytrackable fx (including phaser!) could benefit. on the other hand, wobble bass and stuff… it’s really alright to have that stuff just in the track.

138

+1 For Dsp attached to xrni !!! after i sad goodbye kontakt

139

+1 for ‘meta’ instruments

yeah. and ,like, duh. who doesn’t miss this? common hardware feature that has vanished for some understandable reasons in software but would make renoise ‘instruments’ much more meaningful?

140

Time-stretching?

Time-stretching.

141

Oh and For Dsp attached to xrni should be associated PER OSCILLATION because if its not that will be useless !

142

“Time-stretching.”

143

Lock Columns / Mute Groups
Discussion

144

I have updated the first post of this thread to reflect the starting proposals to the features included in 3.0, and it seems that finally they got all covered.

there is surely room for many improvements, but definitely version 3.0 has turned “XRNI Future” into “XRNI present” :)

145

some ideas for instrument editor.

146

Not only improvements I am afraid… Just look one post above yours for example.

147
  • Mute Groups
  • Map sample Groups within an instrument to output to specific tracks (as multi-out VST instruments can do)
  • Full read/write support for .sfz format instruments
  • Big increase to limit of maximum number of samples per instrument.

Generally anything that TX16Wx can do…