fade in and out function for sustained sounds script

Leftyloopy

Disclaimer first: We still use mobius 2.5. Haven't been able to transtion yet.

For years in our setup sometimes we had the need to record pads or stuff that morphs slightly and found out that the way it works best to record a silent loop and then overdub fading in manually on our mixer send to mobius and then fading out after reaching the restart of the loop at a somewaht similar rate. That way what comes out "morphed naturally" with a constant volume and without noticeable jumps on the timbre of the sound.
It's good to clarify that we dont monitor input through mobius and all of this is done on our mixers' monitor channels, and then bring up the mobius track output up.
This method brings a flaw: we have to use one hand for mixer faders and even if we used a stereo volume pedal, the timing is far from perfect as it is human made.
It's good to clarify that most of the time we get out of recording with overdub, but helps only with delay or reverb tails and does not prevent the abrupt beginning of the recording.

Now the question: Has anybody ever scripted something like this to do automatic fade in on the input level and then after reaching end of loop, automaticly fade out? And when it'sma;; said and done, bring up the track's input level up for future recordings?
Ha! I know it's a long shot, ut my limited scripting knowledge pleas for finding somebody that had ran into this problem and could throw some scripting techniques to help out.
Cheers!

jeff

I know this was done a few times in 2.5 but I can't find any of the old examples. The script basically does a (programming) loop setting the levels up or down by one then pausing for a few milliseconds in between.

Another way to do this is to use parameter automation in the host but it requires you use Mobius as a plugin inside a host that supports automation. You expose the Input Level or Output Level Mobius parameters to the host, then draw an automation curve however the host does that. It's more moving parts because now you have to trigger the "playing" of that automation in the host in coordination with sending commands to Mobius, but for people that already do a lot of parameter automation it may be more natural than writing Mobius scripts.

Leftyloopy

Right, we do use two scripts for fading in and out automatically on the output level that I was able to frankenstein from another script from the old forum. Problem is that we are talking about almost a decade ago and, like I mentioned I'm completely useless a scripter, I have a hard time understanding what I found and how I modified back in the day. So it's hard for me to figure how to script what I need for this new use.
That's why I was hoping somebody has ran into the same need 😅

Here's my fade in OR out that we currently use:

`!autoload
!name GroupSlowFade
Variable track lastLevel
Variable track fading false

Message Fade In Or Out
if (output == 0) && (!fading)
set fading true
while output < lastLevel
set output output + 1
Wait msec 1000
next
set fading false
else if !fading
set lastLevel output
set fading true
while output > 0
set output output - 1
Wait msec 1000
next
set fading false
endif
endif`

Thanks for the response, Jeff👍 . I'll see if I look at it hard enough and start trying a way to do this.

alexs1

Leftyloopy @jeff

I'm looking for a decent fade in/out MSL script. The idea in my case is to set it up so that it works with #repeat, where each rapid press increases the time it takes to fade in/out depending on where the output feedback is at. If it's
<63, pressing should fade it up until it's at a full 127, and pressing quickly a few times should fade at a slower rate.. If it's >63, same thing, but the increments go down until 0.

Alternatively, it could work by there being a FadeOut/FadeIn toggle variable, and then #sustain sets the fade rate. For example, Track starts at 127, I press the script, it begins to fade, and if I hold 1-2 seconds, the fade takes longer. If the track is then already in mode==FadeOut, pressing the trigger will begin the ascent back up to 127, again with the #sustain governing how long it should take to FadeIn.

I am absolutely no idea how I could do this in MSL. I know Jeff set up a while statement in b47, so that might help, but as for the variables and logic I'm not sure.

Alternatively ALTERNATIVELY, the simplest option might just be a dedicated Fade function. Fade In and Fade Out, or just Fade (toggles either/or), that takes an argument for how long to execute the fade (in time or by quantization) and maybe a threshold parameter for feedback.

alexs1

jeff

Rad! I love the prospect of adding automatic fading to the flow. Can already imagine there being a bunch of cool variations (one idea was combining my instant retrigger script with a short fade-in.)

alexs1 Alternatively ALTERNATIVELY, the simplest option might just be a dedicated Fade function. Fade In and Fade Out, or just Fade (toggles either/or), that takes an argument for how long to execute the fade (in time or by quantization) and maybe a threshold parameter for feedback.

I was curious what you thought about Fade as a native function? There are some hardware loopers with it built in already (i.e. 'Rang III), and it could null the need for a script in most cases if there is an argument field for the rate/threshhold. If not, scripts can suffice!

Luca

yes, this script was an important part of my setup back at the days. I would love to have it available in 3.x
:-)

jeff

Yes, I added the while statement mostly for this use case. Here is the basic fixed fade out.

#name FadeOut
while output > 0 {
   output = output - 1
   wait msec 100
}

From there we an add other options to control the rate of fade, a fade cancel action, etc. Those are a little more involved and I'll spend some time on an example.

alexs1

jeff #name FadeOut
while output > 0 {
output = output - 1
wait msec 100
}

The script works, and I wrote an inverse one for FadeIn, but I haven't found any way to toggle the two without issues. If you toggle FadeIn while FadeOut is still going on, they start competing for who gets to be Father Fade. I tried using the break statement, but to no avail. Maybe there's another way of writing it so that the while statements don't overlap?

jeff

Yes, a built-in Fade function that automatically deals with overlapping requests is on the list. As you found, it's easy to get into situations where while scripts can fight each other for control, and for FadeIn/FadeOut can go on forever as one bumps it up, the other bumps it down, lather, rinse, repeat.

It's possible to have FadeIn/FadeOut scripts be aware of each other using variables. I'll work on some examples, but it's more complicated than it should be for this common operation.