Topic: Something about automation.

This topic has 13 replies, 4 voices, and was last updated 17 years, 1 month ago by Zynewave.

Viewing 14 posts - 1 through 14 (of 14 total)

September 22, 2007 at 09:46 #1432

Igr0
Participant

I noticed one thing in automation.When automation track finished and the last value of some parameter was not zero, why it after finishing this track become to zero anyway?Maybe it should stay on this position?

Next picture show a liitle-little bug with the graphic.This bug disappear, if some other window pop-up. version 1.94.

At this moment its all.But i have some idea about automation,i will tell you about it after.Thnx

September 22, 2007 at 11:27 #10881

acousmod
Participant

I noticed one thing in automation.When automation track finished and the last value of some parameter was not zero, why it after finishing this track become to zero anyway?Maybe it should stay on this position?

Yes, it has been discussed and I hope also that Frits will add a Preferences option to keep the last value…
To avoid this I often use MIDI events, but the plugin must of course support MIDI controllers.
Note that you can define another default value than 0 if it can help.

September 22, 2007 at 12:28 #10882

Igr0
Participant

I think it’s better, if automation tracks(both) never had the edges.So, when you create the automation track, you will see endless clip by default.In this case you will never do any mistake with crossfading(by accident) automation parts.

September 22, 2007 at 19:38 #10883

pernst
Participant

I hope nothing is changed to affect the timing and usability of automation in Podium. The reason I use Podium for my work is I used JamStix, and now use JamStix 2, for drums. JamStix allows automation of most every control, allowing for very “life-like” performances without the need to “hard” program the parmeters into multiple parts. Changing the parameters with automation provides great visibility in the sequencer to changes in drum parts and style, and easy manipulation as changes are required.

With the advent of JamStix 2, I no longer use FL Studio, Reaper, nor Traction as either the automation is recognized as a constant change triggering recomp in JamStix even though values remain steady, or the timing of the automation is variable leading parameters to change to early or late in JamStix to allow accurate control of changes.

Bottom line, I have come to greatly appreciate how Podium handles automation, and would be wary of change. For instances, if the program holds the last value after the clip finishes, when I stop and move the play cursor to a position prior to the automation clip, it would be problematic for me to have the parameter still set to what it was at the end of the clip. Or, for that matter, if I stop playback in the middle of the clip, and rewind prior to the clip, I don’t want the parameter set to what it was when I left the clip.

I appreciate options, allowing users to set the app to behave one way or another. But if this leads to timing issues or change recognition issues, I would be greatly disapointed.

September 22, 2007 at 22:49 #10885

Zynewave
Keymaster

@Igr0 wrote:

I think it’s better, if automation tracks(both) never had the edges.So, when you create the automation track, you will see endless clip by default.In this case you will never do any mistake with crossfading(by accident) automation parts.

I’m considering adding a new “auto-size event to arrangement length” track option. This was mainly intended for bounce tracks, but it can equally be applied to parameter tracks. You would then only have one curve sequence on the parameter track, and it will automatically be resized whenever the arrangement length changes.

September 23, 2007 at 11:26 #10887

Igr0
Participant

@pernst wrote:

I hope nothing is changed to affect the timing and usability of automation in Podium. The reason I use Podium for my work is I used JamStix, and now use JamStix 2, for drums. JamStix allows automation of most every control, allowing for very “life-like” performances without the need to “hard” program the parmeters into multiple parts. Changing the parameters with automation provides great visibility in the sequencer to changes in drum parts and style, and easy manipulation as changes are required.

With the advent of JamStix 2, I no longer use FL Studio, Reaper, nor Traction as either the automation is recognized as a constant change triggering recomp in JamStix even though values remain steady, or the timing of the automation is variable leading parameters to change to early or late in JamStix to allow accurate control of changes.

Bottom line, I have come to greatly appreciate how Podium handles automation, and would be wary of change. For instances, if the program holds the last value after the clip finishes, when I stop and move the play cursor to a position prior to the automation clip, it would be problematic for me to have the parameter still set to what it was at the end of the clip. Or, for that matter, if I stop playback in the middle of the clip, and rewind prior to the clip, I don’t want the parameter set to what it was when I left the clip.

I appreciate options, allowing users to set the app to behave one way or another. But if this leads to timing issues or change recognition issues, I would be greatly disapointed.

I think pernst, you don’ have to worry about it, cause Frits always offer to switch between two option-old or new.;)

September 23, 2007 at 12:00 #10888

Igr0
Participant

@Zynewave wrote:

@Igr0 wrote:

I think it’s better, if automation tracks(both) never had the edges.So, when you create the automation track, you will see endless clip by default.In this case you will never do any mistake with crossfading(by accident) automation parts.

I’m considering adding a new “auto-size event to arrangement length” track option. This was mainly intended for bounce tracks, but it can equally be applied to parameter tracks. You would then only have one curve sequence on the parameter track, and it will automatically be resized whenever the arrangement length changes.

Ooh yeah.It’s cool.But for the present automation situation i can give one advice- Deny to automation clip(part) to be over other automation clip(part).Exclude it.Anyway nobody use it.No automation mistakes anymore.

September 28, 2007 at 18:23 #10921

Igr0
Participant

Hi Frits. So what you think about my last post? Im sure,that its not so important now,but just want to hear your idea about it.thnx.

September 29, 2007 at 13:55 #10923

Zynewave
Keymaster

I agree that there is no practical use for overlapping curve sequences. It will in fact create conflicts when playing back the automation. Later on I’ll probably implement automatic cutting of overlapping curve sequences when you drag or resize a curve sequence.

September 29, 2007 at 15:00 #10924

acousmod
Participant

Together with “snap to edges” it will be perfect 🙂
(I spend a lot of time to put audio and automations events together, side to side and to avoid that there is a gap and they don’t overlap…)

September 30, 2007 at 09:00 #10927

Igr0
Participant

Thnx, Frits!

November 20, 2007 at 08:18 #11286

Igr0
Participant

Bump:)

November 24, 2007 at 19:37 #11305

Igr0
Participant

Hi Frits, about fixing the automation. Just trying to notice things above this post. 🙄

November 25, 2007 at 14:34 #11307

Zynewave
Keymaster

I haven’t forgotten about this. Currently I’m focusing on getting the compact mode finished. Eventually I’ll look at the issues discussed here.

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.