Maybe I am not sensible enough 
With this setting in the 1st 2 rackspaces I can not hear a difference in volume when switching between the 2 rackspace which do not have a script
1 Like
Yeah. Under 1 second it is not noticable. Tried it also.
So fixed without scripting?
1 Like
I think so. Scripting is a cool thing. But I prefer the easier stuff I think. A bit of trial is better than none!
Scripting is very cool and sometimes the devs include things in standard because of people doing cool scripting
1 Like
You would be if you were a guitarist 
Same for me: my pianist in a former band used to tell me: “can’t you hear the difference in the attack of my note?” and I said I did not…
Look at this waveform of a rhythm guitar with a steady attack, you can clearly see the rackspaces changes without script but not the scripted .
I forgot to tell you that in your rackspace example, there is no level difference because Input Muting is not used, so the sound can not keep on playing while the new rackspace starts.
My aim is to keep on playing during rackspaces changes without levels differences.
The waveform picture has been done with Input Fading set to 5s while the next rackspace fades in during 2s. The peaks show the crossfades with no script.
Ok, but what is wrong with input muting set to 0 seconds?
As soon as you activate a new rackpspace, it stops playing sound from the previous rackspace, so the change is abrupt.
This is good, i.e., for a fuzz guitar solo starting suddenly, but for my part I often play with atmospheric ambiances where guitar notes or chords played must smoothly crossfade from one rackspace to another.
It is more elegant 
Ok so you should think about using variations within a rackspace, maybe that helps.
Wouldn’t it be possible to operate a cross fade using the On Deactivate and On Activate callbacks? I don’t know if scripting is possible during transition phases…
Yes he did that already with scripting.
I was searching for a solution right out of the box.
As I see, we have a fade out of the previous rackspace, but not a fade in of the new one. So, I don’t see how we could have a perfect x-fade without scripting…
Aah, maybe a good idea for the devs
1 Like
This is why I have adapted the script above. It works perfectly, adjusting the time values as necessary.
I have already integrated it into all the rackspaces I need and it is really nice to use.
I do not know if many people would find this useful, but in this case it would be interesting in the future to add a Input Fade-in time in the Maximum audio tail lenght window.
Or maybe creating a scriptlet?
I talked nonsense, scriptlet is only for MIDI 
I am trying to create a kind of “shortcut” to insert easily this feature in a rackspace when needed.
Sure but you can still control widgets which can then control audio gain
1 Like
Yes, this is what I do right now in the gig file uploaded above.
But as I intend to use this rather often, I am looking for a faster way to insert it in a rackspace.
Currently I need to insert a gain control in the wiring window, copy the widget from another rackspace (as it already contains part of parameters) in the panels window, map it to the gain block and insert the script in the rackspace.
But even if I must do it like this, it is a wonderful trick offered by GP 
In addition, I use now inside a rackspace the x-fader scriptlet available here that advantageously replaces Melda MRatio.
I do not know if such a scriplet could be feasable for crossfade of an audio block between two rackspaces.
Wonderful Scriptlet 
1 Like