Well, I’d love to see it anyway. 
GUI-wise it would be a drop-down box in the place of the words “Linked Plugin”, where you choose between linking a plugin OR RNS-commands, making it possible to automate commands like 9xx, finally opening up the possibility to control sample offset with MIDI-controllers.
What do you say?
WHAT YOU SAY? SOMEBODY SET US UP THE BOMB!!
+1 
But what should an linear interpolated automation curve for a 09 effect exactly do? Retrigger the sample all the time? What about all the “relative” effects like pitch/volume up/down? How could retrigger work from an envelope?
Magic! 
Well, retrigger in an envelope would retrigger faster, making a ping-pong like effect possible I guess. Your description of the 09 effect is dead on. By using Renoise-style 09xx-effect, creating an envelope that goes from 00 to FF would simply time stretch the sample to fit that pattern, no matter what pitch. With live play, this could definetly create an interesting (although possibly choppy (BUT COOL)) effect close to (but not really) scratching. Pitch envelopes would give a “slow pitch up to fast pitch up”-effect, and volume up/down is, well, kinda useless in this envelope, hehe…
All in all, just a couple more tools for the fun loving renoisers. 
probably the intoxication, but I’m not feeling teh brilliance quite yet 
Problem visualising this, please make a photoshop slideshow…is it like the velocitydevice on crack?
I did some photoshoping of a ‘per note’ and a ‘clip’ version of this idea a couple of years ago.
A ‘device version’ of this that would affect an entire instrument/track/column could also fit very well into this concept, especially if we some time in the future could split tracks into ‘global track fx-columns’ and ‘per note-column fx-columns’.
for instance:
c-400 … … ---- E-400 … … ----||---- ---- ---- ----
this is all one single track, but each column has it’s own optional fx-column.
After the || you see global track fx-columns (like the one we have in Renoise now).
The idea behind this was that you could see all data both graphically and as pattern-fx’s.
A quantize options for each graph could solve how often a fx should be triggered when you draw a line.
Relative commands should not be a problem here?
In fact, a relative option in meta devices would be very useful.
Also a ‘reset’ with options like first note-off, last note-off etc…
This way you can for instance choose to have the envelopes for the first note to ‘guide’ the next notes (their envelopes will be synched to the first note, until you release all notes. etc…).
+++++ i want it
whoa this is a conundrum!
i think the only way this would work is if the pattern effects commands were inter-linked to the automation viewer.
just for an example: any input in the the volume column or pan column would also have a point in the automation viewer for the pan & vol.
the biggest thing is this:
having 2 sets of commands(pattern & automation), is the most confusing thing i see atm.
Well, sample offset and a whole lot of other things!
++1
There is a discussion of a simular suggestion I made here:
https://forum.renoise.com/t/meta-device-that-generates-pattern-commands/17926
There’s a bunch of reasons this just confuses the living daylights out of me. An effect like 2 for instance would simply have to act differently as an envelope. Not too concerned about E or others that have a “one shot” effect, because enveloping them wouldn’t really be a good alternative.
The end result is really sort of abstract. I don’t see how pattern effects (which are sample playback effects) have a natural place in automation land when we already have envelopes for instruments (although not being able to automate those envelopes again is a more interesting problem if you ask me).
In my mind there is a semantic difference between automation and envelopes. One alters properties of effects over time “by hand”, the other alters states according to runtime criteria (be it velocity, volume, whatever)
In practical UI terms though, what this idea sounds like to me is an altered suite of effects applied like pattern effects but not additively, added perhaps through a *patternEffectDevice that takes automation values and pipes them through to the current pattern tick.
Reading comments throughout I must say that I originally only wanted a “09xx-device”, but thought that having all original pattern commands in one automation device would make sense. In retrospect, it doesn’t.
So I’m changing my wish to 09xx-device.
Or perhaps a sample control-device that gives automation of loop points as well as offset?
Well… but as you said, we have many different kind of effects with different durations etc, and some of us actually wanna use a kinda state in between your ‘definition’ about envelopes, and automation.
Also remember that Renoise might later on get new clips (like note clips, audio clips etc) where you in some sort is in between a per track or instrument editing, and per note editing.
IMO we should have most properties available per note, per instrument, per clip, per track, per pattern , per song.
Such a system gives you ultimate flexibility. And further you can contain these different elements either directly in an arranger or you can hook them up to new instruments. That gives you the ability to use all elements ‘oldschool tracker style’ or you can use more modern ‘seqeuncer style’ editing. But the point is that there will be many new elements that is useful either way.
You mean that you can’t see immediately the actually result of your fx-use if you use envelopes for traditional pattern fx commands? If so, then that is the whole point IMO. It’s just far easier to simply experiment with fx.
And you said it yourself. This simply opens up for those who don’t wanna use static instrument envelopes. Of course the instrument envelopes must/will be made better, so you can automate things etc. But would it not be just very cool to be able to to both?
Insted of changing the instrument when you wanna do a few edits on a note in a instrument (like pattern commands do now), you just don’t wanna use the instrument itself to do that, because your instrument envelopes could already be busy doing other stuff.
To me this is the ‘in between’ state I was talking about and just gives you more freedom IMO.
A lot of plans are made for a better instrument structure in the future anyway.
What I try to show is just a graphical view of the current pattern command structure. I see no reason why anything you put into the pattern editor should not also be seen graphical in the automation window and vice versa (or lets call it a graphical editor window instead of just Automation window). It’s the same data, just shown and edited in a different way. You can of course choose what should be shown in this graphical window. Just track/instrument automations, or notes, or note-envelopes, or different types of clips etc. It’s just a nice tool that focus the data under cursor in a graphical way.
I guess i’ve put on the cape of the interface guardian dude or whatever.
I don’t care what gets put into Renoise honestly, as long as it doesnt muddy the application. This pays into semantics, symbolism and flow of operation. When you make a crossroads between otherwise separate functionality, you better know wtf you’re doing, and this goes far beyond “making an in-between”. I get what you want, and it’s a good idea. But you should be leaving pattern effects far out of it. They operate by different rules than what you want, and coupling the two leads to an abstraction that’s inelegant and confusing.
What you want, as it appears to me, is a way to automate instrument envelopes, since automating retriggering, sample offset, reverse or any of the other one-shot effects simply makes no sense no matter which way i turn it.
We’ve wanted automatable instrument envelopes since forever, specifically in pitch shifting. This is nothing new.
If you can condense your concept, art and all, into a design that follows through rather than pose a “wouldn’t it be nice if” question without a solid foundation, at least i could picture it. I suppose i’m somewhat of a renoise traditionalist, but evolution in software should be incremental and goal oriented, not in dramatic steps without a clear line between the now and the then. It comes down to linguistics; incorporating a foreign word into your language is not something you simply do.
As a challenge, make me a compromise. Make something that fits into the way Renoise works right now without intrinsic functionality being altered.
In my case, i often have several breaks, up to the maximum channel polyphony, at the same time, having sample offset called on them on the same line. I’m not sure how your visualization would function in that aspect. Make me a visual example of what this would look like.
I’m intrigued, but i don’t see when or why i’d use it, not to mention HOW.
Sunjammer: I fully agree with your point in general, but as pysj showed, there actually is a good way to get this integrated in a long term, well thought of way.
While we are on this topic (this spins around in my head since a few weeks now):
EDIT: Split topic to
-> https://forum.renoise.com/t/organizing-ideas-suggestions-feature-design-forum/20022
i had a long hard thought about how to get this right.
(the previous post about having the pattern commands & column effects and the automation as 1.)
in order for all the pattern commands & column effects to work properly with the automation viewer.
i believe the automation viewer should have All the 3 types of node points (points,cubic,linear) available to the single automation.
this may indeed mean that more different types of points should be available for the types of commands that will be needing them.
essentially allowing automations to be created from the pattern editor, & vice versa.
