Recording fader movements to automation problem

Submit any bugs here. Please check existing posts before submitting a new one.
User avatar
El Nino
Posts: 14
Joined: Sun Dec 27, 2015 1:02 pm

Recording fader movements to automation problem

Postby El Nino » Thu Jul 28, 2016 7:46 pm

I have noticed that when recording fader movements to automation, the movements are recorded alright on the first pass (albeit with some latency, which is to be expected on android). However, on the second third etc. passes the movements do not "overdub" properly, that is to say the movements from the second or third pass of recording will be mixed with the movements from the first pass rather than overwrite them.
This results in the fader jumping all over the place.

Its not just a problem in GStomper, Ive noticed that renoise also has this problem..

Ive been using LFOs more these days because the results sounds smoother than the live fader movements recordings.
Maybe it would be good for GSTOMPER VABeast to have a graphical automation lane than could be opened for each fader, various curves, liner, points, cubic interpolation available etc.
User avatar
planet-h
Posts: 1258
Joined: Wed Jun 19, 2013 4:46 pm

Re: Recording fader movements to automation problem

Postby planet-h » Fri Jul 29, 2016 6:29 pm

El Nino wrote:I have noticed that when recording fader movements to automation, the movements are recorded alright on the first pass (albeit with some latency, which is to be expected on android). However, on the second third etc. passes the movements do not "overdub" properly, that is to say the movements from the second or third pass of recording will be mixed with the movements from the first pass rather than overwrite them.
This results in the fader jumping all over the place.

Its not just a problem in GStomper, Ive noticed that renoise also has this problem..

Ive been using LFOs more these days because the results sounds smoother than the live fader movements recordings.
Maybe it would be good for GSTOMPER VABeast to have a graphical automation lane than could be opened for each fader, various curves, liner, points, cubic interpolation available etc.


Thanks for your message, El Nino.
I'm aware of that problem. It is caused by the fact, that even if you move the fader, it might happen that no movement occurs at a particular step. If that is the case then the previously recorded value of the step is kept. I agree, that it'd be better to overwrite all the steps in that case.

Regarding the graphical automation lane:
I'll see what I can do.
User avatar
El Nino
Posts: 14
Joined: Sun Dec 27, 2015 1:02 pm

Re: Recording fader movements to automation problem

Postby El Nino » Sun Jul 31, 2016 11:34 pm

awesome.

when recording, whilst the fader is being moved (or held still in place) for any amount of steps, always overwrite previously recorded stuff on those steps.
User avatar
planet-h
Posts: 1258
Joined: Wed Jun 19, 2013 4:46 pm

Re: Recording fader movements to automation problem

Postby planet-h » Mon Aug 01, 2016 7:35 am

El Nino wrote:awesome.

when recording, whilst the fader is being moved (or held still in place) for any amount of steps, always overwrite previously recorded stuff on those steps.


I cannot guarantee yet, if this is really possible.
It will work for sliders (when using the touch interface), since these have a clear touch/move/release cycle.
But using a MIDI controller for example it's completely different. In the MIDI case only the real movement events are fired towards the G-Stomper app. And while nothing is fired and nothing is touched on the touch interface, overwriting all the steps would simply result in resetting the motion sequence in every moment when the recording is enabled.
You know what I mean?

However, I'll definitely look into the touch interface.

Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 1 guest