Automation item pre-release thread

[mccrabney]

Originally Posted by gpunk_w

Get rid of it entirely and force new automation to be completely item based. Obviously that will never happen for the usual reasons, but it should.

yes yes yes. at least give us the option to do it ourselves via some sort of "automatically create AIs for any envelope data" and "disable envelopes where no AI exists"

Originally Posted by ovnis

Am I the only one to think that it would be a good idea to be able to bypass the normal (and to make the envelope invisible) envelope without bypassing the automation items ?

no, you're not. to me, this remains the most valuable potential feature involving AIs, for several reasons. number 2 below is the biggest.

1, visual cleanliness. no envelopes visible where there is no envelope activity.

2, and this is the most important, this would allow your learned MIDI controls to be used again where there is no automation activity (ie between AIs). right now, if you learn a MIDI CC to a parameter and then enable the envelope for that parameter, the midi cc no longer controls the parameter. it is overridden by the envelope. however, if AIs enable and control the envelope while they are played, but RELEASE the envelope when they conclude, your midi controller is not locked out of controlling the parameter.

^ this has immediate and powerful implications for using REAPER live.

[OPI]

I have the latest update but i dont see any options for automation items. Do i havr to install and extention?

[EvilDragon]

Nope. You need to install the latest PRErelease. Not release.

[OPI]

Yikes. Sorry bout that. This looks exciting.

[Win Conway]

seems all relevant actions are being added for AIs now, does that mean we should stop commenting here and get used to these now ?

[EvilDragon]

Looks like!

[Dehenry]

Bug (or intended - not sure): If the edit cursor is within the time selection when the AI is inserted, the AI is created within the time selection and is as long as the time selection (as expected). But if the edit cursor is outside (either left or right) from the time selection, the AI is created outside the time selection and it is always two beats long. The edit cursor line moves away from its red triangle head.

Originally Posted by mccrabney

yes yes yes. at least give us the option to do it ourselves via some sort of "automatically create AIs for any envelope data" and "disable envelopes where no AI exists"

+1

[ovnis]

yes yes yes. at least give us the option to do it ourselves via some sort of "automatically create AIs for any envelope data" and "disable envelopes where no AI exists"

+1000

[jm duchenne]

Originally Posted by ovnis

+1000

Can we hope that some extension or script will be possible to hide and mute the underlying regular envelopes, and only show and active the AIs, even if Cockos doesn't implement the option ?

[mccrabney]

Originally Posted by jm duchenne

Can we hope that some extension or script will be possible to hide and mute the underlying regular envelopes, and only show and active the AIs, even if Cockos doesn't implement the option ?

i can't believe that i'm saying this, but "it should be native." you'll probably only hear me say that once.

in my opinion this is the defining feature that would make automation items automation items rather than just a much improved toolset for copying, pooling, and manipulating existing envelopes.

this is excitement, not impatience btw, the work that has been done so far has been great

[schwa]

Originally Posted by jm duchenne

hide and mute the underlying regular envelopes, and only show and active the AIs

There are a number of complex situations that would need to be handled in order to support this. For example, even plugins that support sample-accurate automation do not support automation that starts or ends in the middle of a sample block. So automation items would effectively start and end on sample block boundaries, the exact timing of which can vary depending on when playback starts. It's not well defined what automation values would be sent for these start and end blocks. Seeking would also have a non-deterministic effect on parameter values -- during playback, automated values would effectively latch to the last value of the previous automation item, but those values would not be chased if seeking from before an automation item to after it.

These things aren't impossible to handle, but it is a lot of added complexity on top of what is already a lot of added complexity.

[vitalker]

Originally Posted by schwa

These things aren't impossible to handle, but it is a lot of added complexity on top of what is already a lot of added complexity.

Well, I've already asked you for adding latch mode for AI, so I think it covers what jm duchenne is asking for.

[sonicowl]

With new AI, is there a plan to limit visual range of envelopes?

For example, I have a full range of envelope from 0-127, but want to automate only values from 0-7. With full range of envelope this means I have to make envelope real large to be able to see low values. With limited visibility range I could set values from 0-7 to represent full visual scale, and easily edit envelope. Any solution for this?

EDIT: AI = automation items

[vitalker]

Originally Posted by sonicowl

With new AI

What does new AI mean?

[sonicowl]

AI = Automation items

[MT_]

Artificial Intelligence!

[vitalker]

Originally Posted by sonicowl

AI = Automation items

Ok, sorry. I should ask again . What does NEW ai mean? :0 A, ok, I think I got it. You mean new inserted, yes?

[SmajjL]

New York Artificial Intelligence

"ohh shit" *meep meep*

[sonicowl]

Originally Posted by vitalker

Ok, sorry. I should ask again . What does NEW ai mean? :0 A, ok, I think I got it. You mean new inserted, yes?

NEW, because it is something new, it wasn't released yet, only in pre-releases. When it will be finally released, it will be new.

I thought while they are at it, maybe it is a good time to think about implementing some sort of value scaling, to be able to focus on just part of envelope. To be able to zoom in on specific range, if it is too tiny to work on.

For example, If I automate CC or Program Changes, it is hard to be precise in range 0-10 out of 127. Would be very helpful if one could zoom in, or define visible range of values, so that for example only values from 0-10 would be visible. Maybe something similar to vertical zoom in MIDI Editor, where you can have notes bigger or smaller, and scroll up/down into specific range.

I don't know, is something planned in this regard?

[vitalker]

Originally Posted by sonicowl

NEW, because it is something new, it wasn't released yet, only in pre-releases. When it will be finally released, it will be new.

But why new ai, not just ai?

[gunny]

Originally Posted by vitalker

But why new ai, not just ai?

I think it did not mean anything special.
Just ignore the word "new" and everything will be fine... =)

[vitalker]

Originally Posted by gunny

I think it did not mean anything special.
Just ignore the word "new" and everything will be fine... =)

Ok. It makes sense now.

[sonicowl]

Originally Posted by vitalker

But why new ai, not just ai?

Vitalker, new AI was not meant as "new AI" as opposed to "old AI". It was meant as "new development" that is called "AI". But I don't think it matters much that I used that word NEW. Don't get too fired up about it.
I think of AI's as NEW development in regard to envelopes. I'm just wondering if vertical zooming or custom vertical range for envelopes (or just AI's) is part of this NEW development, or not?

[mpl]

Originally Posted by schwa

Thanks for the suggestions. You are correct that the fundamental design of poolable automation items is unlikely to change, although very few of the implementation specifics are set in stone.

FWIW there are some limitations with the abstraction you are describing, where automation signal flow is treated just like audio and MIDI. For example, when sending the same automation signal to multiple targets, you want to preserve the shape of the automation, but since different automatable parameters have different ranges and scaling (say, volume vs filter cutoff), you usually want to vary the baseline and amplitude depending on the target.

So technically there is a formula for converting range [0-1] to reaper volume [0-1-2-4]. Is it too complex to let user define formula by string (like I did for parameters modulation in MappingPanel script)?

[heda]

I can't get automation items to work on parameters in the video processor. The normal envelope works, but not with AI. I'm sure it has to be a bug.
I know we can't automate with modulation from MIDI or audio isignals in the video processor, but it would be so cool to be able to synchronize video effects to music at least via pooled automation items.

[run_esc]

This feels like a dumb question, but: when we say that an AI (or MIDI item, etc) is "pooled" in Reaper, what does that mean?

[ferropop]

Originally Posted by run_esc

This feels like a dumb question, but: when we say that an AI (or MIDI item, etc) is "pooled" in Reaper, what does that mean?

If you make a 'pooled' copy of the AI, any changes you make to one will affect all pooled copies.

[ovnis]

When we move an edge of a not looped automation item, I think it's sad not to have the possibility to add new points in the new section immediately :

[Travesty]

It's different to general item behaviour, but it makes sense to me in this case

[schwa]

Originally Posted by ovnis

When we move an edge of a not looped automation item, I think it's sad not to have the possibility to add new points in the new section immediately

In your specific example, moving the edge with the "collect new points" mouse modifier (control+drag by default) would have the effect you want. But that's only because the underlying envelope value is the same as the automation item value on the right edge.

We can add an option for the behavior you want, but that means if there are other automation items pooled with the one being edited, they will also be affected by the edit. In particular, looped items pooled with this unlooped item will be altered in possibly unexpected ways.

[vitalker]

Originally Posted by schwa

We can add an option for the behavior you want, but that means if there are other automation items pooled with the one being edited, they will also be affected by the edit.

Please don't add such a behavior, because it already exists as you've written above.

[schwa]

Here's an example of unexpected behavior this change would cause:

[ovnis]

THX, schwa !

[Alkamist]

I found a small bug:

- Make some automation points in a lane.
- Make a time selection and copy.
- Paste what you copied some time before where you copied it.
- The playhead will jump to the end of the time selection bounds where you copied the contents originally.
- This happens with automation items or just regular points.



Also, automation items don't obey the relative snap setting.

[joe2]

This might be of limited use, given how much work as been done on AI already (and the fact that I'm guessing REAPER is aiming for a more flexible, powerful, configurable, etc. solution), but has anyone checked out how Propellerhead's Reason automation items work?

I've been playing with it recently, and some aspects of it are quite nice. e.g., if you copy an AI from one automation track to another, and their "types" don't match, the item can still live on the other track, but is essentially disabled and visually flagged as being "alien". You can then use a menu to "convert" this alien data to the right kind for the track (how well that works, I don't really know, but it's kind of moot -- it would probably be impossible to make all this stuff work automagically, but giving the user some crude way to mangle their data around seems better than nothing).

Just thought it could be worth mentioning as a potential source of inspiration.

Cheers devs for all the hard work, looking forward to a stable release of this!

[vitalker]

There's still lack of color setting...

[musicbynumbers]

Originally Posted by vitalker

There's still lack of color setting...

Or muting which is essential I think if we aren't getting takes for AI. (although I really hope we are getting takes for AI)!

[vitalker]

Originally Posted by musicbynumbers

Or muting which is essential I think if we aren't getting takes for AI. (although I really hope we are getting takes for AI)!

Yeah, you're right. Automation items should works like other items, but with automation. Moreover, gpunk_w have suggested a great idea how it could be implemented.

Originally Posted by gpunk_w

Actually, automation items should not have its own lane, it should just follow reapers 'No track type' paradigm, with an extra send/receive system for automation
So any track can have Audio/MIDI/Automation/Video items
You can send and receive Audio and MIDI already, so why not the same for Automation data track to track.
This is not rocket science, all items in Reaper sit on a no particular type track, except automation items, it is inconsistent UX design.
Using that method you have every feature that tracks already support, its quite confusing to understand why you didn't go that way with the design to be perfectly honest.

Obviously these are closed case now, this is how they are and be happy, The obvious case being having to use pooled items instead of actually implementing real routing, so i have a fade i want to send to 6 synths at the same time, one track and send it to six places, nope, six automation tracks, terrible forethought of design, screen real estate is no unlimited, but as i said, closed case.
I know you are not going to do any of this, but that is how it should have been done (And yes i said that before automation items existed, many years before automation items existed, so did a lot of other users, we had a long long time to discuss, you should have listened)

Either that or we go the whole hog and make Reaper consistent
MIDI tracks, Audio Tracks, Video Tracks, Automation Tracks

[mccrabney]

i admire the existing implementation, and will use it. it is an excellent implementation of
"enhanced automation editing." i admire it, and i appreciate it for reasons on which i don't
expound below.

as mentioned early in this discussion, i'm also afraid that the actual FR for "automation items"
might get lost in the existing development.

"automation items" means items of automation that exist outside of another existent track automation.
at least as option, there should be no envelope outside of the automation item. i don't
want them and can't use them. they inhibit my ability to use my controllers to modulate said
parameters, block them from being midi controlled. you can't have an envelope-enabled parameter
that is also midi-controlled.

this is, literally, a show stopper, if you wanted to use this live while also having it modulated
programmatically at other times.

automation items should only be active within the automation item bounds. elsewhere, no automation
data should exist. as if the envelope was never enabled. midi learns should operate as expected.

i'm becoming increasingly concerned that this very important part of this feature is being
overlooked, and would appreciate a calming of the nerves. this was done earlier, where such
things would be sorted out once larger bugs were TCOB, but .... ya boy worries

if the option for "contain all envelope data within automation item, disable envelope otherwise"
is not included, the FR for "automation items" has not been fulfilled, at least as i understand "AI"

these things are always written from the sweetest of crably intentions. bottomfeeders gonna bottomfeed.

edit: case use gonna case use!
i play live using reaper
want to use vsti live
want existant envelope activity to do its thing via automation envelope cuz what i wrote
is awesome and expected by audience

when the automation envelope releases, i want to use my controller to play my own solo!

[vitalker]

Originally Posted by mccrabney

there should be no envelope outside of the automation item

It makes sense(FL studio has it like this), but this should be optional.