Envelope Meta Device...

Right now, you can’t change an instrument’s envelope mid song…it’s static. Would be nice to either have commands to ‘shift’ the envelope vertically and horizontally (not edit points on the envelope, just change it’s position in the editor) OR (more preferred), an envelope meta device with which you can edit during the song via commands and automation. Even a simple ADSR would be grand as long as it can be routed to anything. My guess is for it to work, it would have to have commands for on/off (similar to note-on/note-off) triggered by commands. Combined with a filter (or 5!), and custom oscillators, renoise would officially (in my eyes) have full synth capabilities.

So how about it?

+1.
Meta device solution has one big advantage - its use is optional, so there is no overhead.

this is not the right direction, in my opinion.

of course having the ability to change envelopes would be great, but the current meta-device mechanism is not the best way: meta devices are bound to tracks, which does not make much sense together with instruments, if you think at it; a better way to achieve this is by enhancing the XRNI structure as already mentioned lots of times: giving user the ability to automate XRNI parameters through an integrated XRNI panel would be much more consistent.

this and other great features would be much easier to implement and manage.

Envelope related FX commands that we would introduce with a new XRNS structure, would also be bound to tracks, or?

Another idea was to let the “#Automation Device” control a few things our sample instruments can do (not only using the Automation Device for VSTis), like the volume, panning. There we could also add loop and other instrument related controls.

let’s say we have an hypothetical VAxx command, which multiplies the current volume envelope by a xx/256 value (stupid one, I know, but it just an example)

and you put the following on a track:

  
--- 01 VA40  
  

do you mean that only the notes of instrument 01 which are being played in that track should have their volume envelope amplitude halved?

I don’t think so: in my opinion, any XRNI parameter modification should be applied on all the tracks where the XRNI is going to be played, id est: it’s a global XRNI parameter for instrument 01 that you are going to change with the 01 VAxx command

edit: NeuRoTiX agrees with taktik on this. he will explain his point of view later or tomorrow

I read NeuRoTiX reply several times, because in the beginning I found a per-track behavior confusing. for me, things such as an envelope are global properties of an instrument, and should not be track-based. the main objection which I pose is the exact opposite of this:

what happens if I want to apply a property globally for the instrument? should I have to set the property in every track?
on the other hand, it is unusal to use an instrument on all tracks, but still a drumkit could be used on lots of tracks.

I agree with NeuRoTiX on this, and also this makes me have a second thought on the per-track design.

With the ability of choosing amongst multiple envelopes, the idea of a per-track scope does indeed make sense:
suppose you have made a drumkit which has 10 drums pieces and 2 different volume envelopes, one for sustained sounds, and one for muted sounds (for example, a muted cymbal).
If you use a different track for each drum piece, you will be able to set up the muted envelope for a single piece, while the others are still playing with the sustained envelope.

so in the end I think I have changed my mind about this: a per-track design is better

How about keeping the original instrument structure and just adding a meta-device.

Best of both worlds. You dont have to turn on the instrument envelope if you dont want to.

I’ld rather see this part changed that instruments will be approached differently from the DSP rack and attaching different rack-layouts synchronized to the cursor position:
If the cursor is on the note-track, the DSP rack shows all relevant effects or parameters applicable to the note (slides, arpeggio, vibrato). When the cursor is hovering above the instrument column, it will show all effects that allow you to control the instrument (at current row or in general, depending on the option of the rack-device) and when the cursor is hovering above the volume/panning column, it will show all effects applicable to that note in terms of retrig, volume commands, panning etc.
You could even remove the panning column if you can use the default track device to change the volume and panning for that particular subtrack.

This widens the possibilities for the DSP rack without having to actually change too much the pattern layout and for the effect column you could add more DSP effects that would allow you to apply effects to the whole track in general. This could also allow to redim the effect column amount back from 4 to 1 effect column.
It makes the system (in controling manners) a lot more simple to the average or new user yet gives Taktik a lot more space to extend commands and effects.

Or the current layout of column values remains as it is (compatability matters) and the default output can then be used in two various flavors.
For the old-skool skilled trackers, the old methods remain existing and for the hex-fearing, the DSP rack will be their best friend.

I can understand NeuRoTiX’s point of view, but he should be less biased about this topic: an “XRNIDevice” and pattern commands can exist together, exactly as now the awkward 91 xxyy syntax and MIDI-CcDevice exist together too:
you could want to set XRNI parameters via pattern commands or use the automation facilities for more complex (and continuos) changes.

indeed, most of Renoise users have this rule of thumb:
when you have to set an exact value or a switch, use a pattern command, when you have to create a ramp of values, use automations.

Wow, didn’t mean to set off arguments.

I like tactic’s idea of the automation expansion, HOWEVER, it would definitely need an ‘instrument’ pointer, much like other devices have an effect-pointer and the VST automation has a VST pointer.

If it went this direction, I think if it was possible to add some of the xxyy commands in there as well, some newer users could be drawn to the program as well (theoretically). I introduced a buddy of mine to renoise and he loves it, but the automation and pattern commands overlapping nature confuses him a bit and the biggest kickers are the pattern commands that don’t exist in automation-land.

At any rate, it’s obvious that this is not just me being ‘needy’ with the devs…others wish for some way to control instrument settings during songtime as well, so let’s all hope that whatever gets implemented is smart, easy and versitile (which it probably will be).

:)