Automation Tracks

[Junction-Earth]

Hi everyone,

Using splines is a terrific way of creating automation. It gives you ability to manually draw very "exact" automation and also draw triangle, square and also sinewaves on any automation-parameter. But, Richard no doubt understands this.
I'm mean, "he developed Orion". If he thinks it's impractical for reasons that affect overall functionality of automation within Orion. Then, he's right!

I was hoping for that kind of automation for a while in Orion. Before I got a copy. But I realised that Orion doesn't stand or fall by the fact that it's missing it.
But I think it still kind of lacks it. Or something compared to splines.

So...

I myself have also been using another DAW besides Orion for a little while now, that actually uses envelopes or "splines" for automation.

I hope Richard by accident casts an eye on my suggestion and observation here... Because here it is:

The "only" gap (in large perspective) between Orion and "splined" DAW's are these... PS And all can be overcome by adding a few features without in any way changing the way automation is done in Orion.

1.
Better copy-ability on a selected region of automation. There should be a start/end point selection tool to copy a selected piece of automation. Then you select a startpoint for "paste" operation. All overlapping automation should be zero:ed and totally overwritten by the pasted automation info.

2.
Similar to above Orion need a better "sliding tool" to slide a selected region forward or backwards. Using a selected region with a startpoint and endpoint. Sliding should be done by keeping selected region floating until final position is selected. This way the slide can be done outside of a patterns length or beginning. Parts of slided region that didn't fit within pattern or song simply ignored and just deleted.

3.
A spline drawing tool. Yes. But NOT a splined automation!!! But rather a "spline drawing tool" that is drawn and then immediately rendered to automation values native to Orion. The user draws a complex spline and when it's seems ok, accepts the shape and then it's converted to normal automation values according to PPQ.
The spline could be set to have a max value of points. No problem. It's much more powerful to have it than not at all.

..

Always important on all these functions is that the "pasted", "slided" or "rendered" values aren't blended with previous existing values that are overlapping in the region the new ones are pasted or created.

...

These are my opinion and wishes... and the only thing lacking I my mind. Almost everything else is perfect in Orion 8.5... that I know of now.
Orion is excellent!

[Junction-Earth]

The LFO tool is really nice and very "needed" but it somewhat lacks the same feature: The LFO tool can't be added to a "selected region" of song automation or a patternblock automation.

Or can it? If so I'm missing something...

...

Anyway. If "region selection" and operation is made available it would propel Orion automation forwards a great deal.
I hope something like it is added.

...

Edit: Oh... almost missed to point out that my suggestions reside within the same context as "automation tracks" in the sence that if you have the right edit-tools, automation can be handled in a very good way without the need for separate automation tracks.

[HYPNAGOGIA]

Using splines is a terrific way of creating automation. It gives you ability to manually draw very "exact" automation and also draw triangle, square and also sinewaves on any automation-parameter. But, Richard no doubt understands this.

Generally speaking, you can draw all that with the current tools Orion has, say line for example. Drawing them isn't the problem, both current automation and splines are capable of that, it's that "exact" part that is. You can have splines, but if not done right, all you'll get is just another drawing tool. The exactness would come from its other features... snapping comes to mind as one, and multi-selection as another, which aren't currently possible in Orion.

I'm mean, he "developed" Orion

I don't mean to come off as rude or anything, but does that actually sounds as it seems?
Don't get me wrong, but adding it in the quote marks kind of sounds like you're implying he didn't actually developed Orion.

I was hoping for that kind of automation for a while in Orion. Before I got a copy. But I realised that Orion doesn't stand or fall by the fact that it's missing it.
But I think it still kind of lacks it. Or something compared to splines.

Like many of us here, but that's up to Rich. He's been presented with various options, and it's been asked many, many times, so we'll see what and if anything will come out of our constant bugging

1.
Better copy-ability on a selected region of automation. There should be a start/end point selection tool to copy a selected piece of automation. Then you select a startpoint for "paste" operation. All overlapping automation should be zero:ed and totally overwritten by the pasted automation info.

I think it was Bones (and in case it wasn't him, I apologize since I can't really remember who) that once suggested Loop range could serve for the purpose of determining the range as a selection, which wouldn't be bad at all when you think about it. It would still add a feature without making some major changes.

2.
Similar to above Orion need a better "sliding tool" to slide a selected region forward or backwards. Using a selected region with a startpoint and endpoint. Sliding should be done by keeping selected region floating until final position is selected. This way the slide can be done outside of a patterns length or beginning. Parts of slided region that didn't fit within pattern or song simply ignored and just deleted.

Sliding would be nice, agreed.
The song events sliding wouldn't be much of an issue. If you could slide it anywhere in the timeline, it wouldn't matter, because there isn't any boundary or anything to hold the automation from sliding. The pattern events, on the other hand, are a bit of a brain teaser, and deleting what doesn't fit within it - well, that kind of comes on as a "destructive editing". Imagine you had a quite complex automation drawn and you want to slide it just a bit, and all of a sudden parts get deleted.

3.
A spline drawing tool. Yes. But NOT a splined automation!!! But rather a "spline drawing tool" that is drawn and then immediately rendered to automation values native to Orion. The user draws a complex spline and when it's seems ok, accepts the shape and then it's converted to normal automation values according to PPQ.
The spline could be set to have a max value of points. No problem. It's much more powerful to have it than not at all.

That was another Bones' (I think) suggestion. The principle of it is that the splines wouldn't replace current automation system, but like be on top of it, so when you change a point on the spline, it transpires to the automation drawing underneath.

Always important on all these functions is that the "pasted", "slided" or "rendered" values aren't blended with previous existing values that are overlapping in the region the new ones are pasted or created.

You mean like overwrite? I agree with that. Would be even better if undo worked for that

The LFO tool is really nice and very "needed" but it somewhat lacks the same feature: The LFO tool can't be added to a "selected region" of song automation or a patternblock automation.

Or can it? If so I'm missing something...

Set the Loop point and you can apply LFO for song events, and of course be in song mode. Although, you can't apply more than 32 bars at the time. If your question would be why, the answer is simple: performance. It's been tested and verified that applying LFO on anything beyond 32 bars decreases the performance to the point of your computer literally choking, especially during playback. There's been cases (when the limit wasn't still set) where you'd had to wait for several minutes for automation to draw.
So, small solution to that problem was adding the 32 bar limit. The way you'd normally work with it is set the 32 bar region, add LFO, then just move the "Start" point of the Loop in the main toolbar (you don't have to draw the loop selection in the timeline all over again), and it just pushes the Loop range further. Then just re-apply the LFO.
Or in case you have option enable to copy/move song events (cfg in the playlist), then you can copy patterns (select patterns and then holding CTRL key just move them to new position to make copies), and automations copies with it.

Edit: Oh... almost missed to point out that my suggestions reside within the same context as "automation tracks" in the sence that if you have the right edit-tools, automation can be handled in a very good way without the need for separate automation tracks.

I'm not sure I understand what you mean.

[Junction-Earth]

-- HYPNAGOGIA --

Generally speaking, you can draw all that with the current tools Orion has, say line for example. Drawing them isn't the problem, both current automation and splines are capable of that, it's that "exact" part that is. You can have splines, but if not done right, all you'll get is just another drawing tool. The exactness would come from its other features... snapping comes to mind as one, and multi-selection as another, which aren't currently possible in Orion.

Yep. I Agree.
I use line-tool most of the time.
But in total Orion automation feels like it could be done in a slightly better way. I mean the actual "tools" for manipulating automation. I always end up redrawing the same automation curves over and over again in different patterns because I wan't some parts the same but others with totally different automations. And I never get the exact automation across all patterns that I'm after. For example a "region copy tool" and "at position paste" would fix this.

he "developed" Orion

My fault. Welcome to the world of internet filled with bad writing and missinterpretations Changed it slightly.
I meant that if anyone knows anything about the nature of Orions code, VST-standards and what not, its Richard. He wrote Orion.

I haven't read Bones suggestions but he has my vote. My suggestions and observation is that I really miss a kind of "region selection" as a part of "cut/copy/paste" operation.

Edit: Oh... almost missed to point out that my suggestions reside within the same context as "automation tracks" in the sence that if you have the right edit-tools, automation can be handled in a very good way without the need for separate automation tracks.

I'm not sure I understand what you mean.

Just clearifying that even if I didn't mention "automation tracks", the suggestions I and appearently Bones have suggested would have a large impact of how you can edit and manipulate automation in a fast way.
It would "push back" the sence of missing automation tracks within Orion.

Sliding would be nice, agreed.
The song events sliding wouldn't be much of an issue. If you could slide it anywhere in the timeline, it wouldn't matter, because there isn't any boundary or anything to hold the automation from sliding. The pattern events, on the other hand, are a bit of a brain teaser, and deleting what doesn't fit within it - well, that kind of comes on as a "destructive editing". Imagine you had a quite complex automation drawn and you want to slide it just a bit, and all of a sudden parts get deleted.

If all automation-editing can be undone using undo I don't see this as a problem. It wouldn't be destructive editing. It would be "cropping".
Working within tracks/patternblocks this is an excellent way of buildning cool automation.
The scenario is this: You might have created a perfect "automation rise" at the end of a pattern and then deside that you want to slide it to the beginning of the pattern, but don't know the exact position it should go. Then you "have to" be able to slide a part of the "slided selection" outside before the pattern begins.
Another idea is that slide operation could work as "asteriods game", that anything sticking out at the beginning end up at the end of the pattern.

[Junction-Earth]

I'm not quite sure about the conditions surrounding this... but...
Another wild thing on the whishlist of "region copy" and copy operations would be if automation could be copied between different VST(i)-parameters and even between tracks/instruments.

An automatic conversion of data-values or ranges would have to be in place though. I guess... I'm guessing some VST-parameterns answer to 0-127 and other to like 0-8096. Range is defined in the VST(i) itself isn't it?
That would however be destructive editing/conversion

Anyway. On the top of my wishlist is the addition of "region copy" and editing as mentioned earlier. That would make a large difference.

I feel kind of spoiled even suggesting these things. It sounds like I actually think there is a missing piece or a fault in Orion. But that is NOT the case. Suggested features would only strengthen it further. And speed up some things on the user-end.

[El_Capitan]

it's obvious what the main topic of discussion is.
however, in the way El_Capitan words the description of their problems,
there is a strong suggestion that currently only pattern-level automation exists.

I wasn't suggesting that.

However the way it is implemented now for song level is confined. That data should be on the playlist where it belongs. Not in a separate window hiding. The automation is going to alter the course of a song's events. Thus I feel it needs to be where the 'song' is happening; ie the playlist.

[HYPNAGOGIA]

The way I see it, there are two ways to do that.
1. To have it on the track like overlay envelopes, or
2. To put the song event editor within the playlist - kind of like how pattern event editor is integrated into the pattern sequencer. You click the button and it pops up on the bottom.

Both have been requested and suggested, and both have merits and flaws.

Overlay track envelopes are good indicators of what's going on (what's being automated), but have too much of them, and you'll get a very cluttered track. Also, having it overlaid onto the track might bring obstructions with the pattern arrangement, so from the coding side might not be very easy to implement.
Editor integration would be simpler to do, IMO. It would also allow you to track the automation progress within playlist's timeline (ie, it would be synced with the playlist itself, specifically when you zoom). But, just as it is now, it would still be obscured from the plain view.

I'm guessing whatever course is taken, it would still work for some but not the others. The question is which one.

[Junction-Earth]

However the way it is implemented now for song level is confined. That data should be on the playlist where it belongs. Not in a separate window hiding. The automation is going to alter the course of a song's events. Thus I feel it needs to be where the 'song' is happening; ie the playlist.

True...
My own oppinion regarding visibility of automation in playlist/song is that I would be satisfied if only:

1. I could click directly on a pattern or something to reach that specific region of song-automation. Just as with the darkened bottom-part of patternblocks (where you select pattern nr), there should be a colored top-part that "when clicked" takes you to that patterns specific time/region of that instruments/tracks song-automation.
2. That colored top part should by change of color or something indicate whether there is any song-automation present during that patterns position.

This way a minimal clutter is added. Only a "thin colored" line, a few pixels in height, on each pattern would both indicate and give a direct shortcut to requested automation.

I'm guessing whatever course is taken, it would still work for some but not the others. The question is which one.

Also very true.
I'm hoping for more in the line of better edit-tools with "region selection/edit" because it should be much more easy to add these features and wouldn't change appearance for Orion at all. Neither would/should (hopefully) it require any change in how automation is implemented and executed within Orions code.

"The automation is going to alter the course of a song's events."

As El_Capitan writes, or one of the things i'm guessing he's refering too... I have had realworld problems of too in Orion:
Having put together an entire song with a great deal of automation, as common for all projects. I had drawn/recorded a great deal of automation... But to lift a song quality-vise, sometimes requires a total rearrangement of large parts of the song. Sometimes moving parts in the middle to the end or whatever... as all of you probably know already.
In this scenario the problem of editing song-events in Orion really come into focus. It's can be a complete nightmare. Some instruments have pattern-events(automation) some have song-events, some are VST-params some are mixer-params automation. There is no indication if some or any automation is done during present patterns in playlist. Even a simple indication of that automation is present would make it easier.

I usually tend to build an entirely new part after the end of a song. To be safe, without destroying the original parts.
Parts of the new songpart are usually copies of other patterns in the song etc. When i'm satisfied I make room for them and slide them into place.
You always have to be careful because rearranging entire songparts there is always something that gets screwed up, when it comes to automation.

I strongly believe that better "region" edit-tools would help (even when it comes to song events/automation). And even better also some sort of compromise between cluttering and features in the song view as I suggested, the features I suggested wouldn't be as complex as showing actual automation on the playlist but would speed up and simplify.

[Junction-Earth]

A qualified guess is that Richard is tired of some discussions on the forum, and in the wishlist section.
I know "I" would be

He probably has a strong and clear view of what features he likes, and has already thought of most, and whether they are needed/necessary, and in what direction he is taking Orion-development.

All features comes at a cost. The Orion code gets larger, slower, the UI can get cluttered. Sometimes large segments of code has to be completely rewritten to implement and add what one might believe is a "simple feature". And... larger code means more bugs might appear. And have to be fixed.

Money and time is what it always comes down to. And as all knows time is money resulting in a more expensive Orion that is. Perhaps more Coffee and headache pills for Richard

It would be nice to get an indication if Richard still has time to follow these seamingly endless discussions... No need to comment on the actual discussion. Rather avoid that. Only to give a shout... to show you read it

The only reader that matters here is the one and only Richard. Otherwise these discussions can go on til the end of time without ever been taken into consideration