This version of IVP is now obsolete: please use version 5.1 instead.
I attach the latest version of IVP.
This version now automatically ‘ducks’ (lowers and raises) the levels of song intros and outros to make your voicetracked playlists sound more natural. You can of course change the level used for this, BUT note that the same ‘reduction’ of level is used for song intros and outros.
PLEASE READ THE MANUAL! There are a few small but significant changes.
Please report any bugs, comments, suggestions, etc. as replies in this thread.
Nice work with this except I can’t, err get it up…! I cannot see/hear a restoration of the levels once the VT has finished. This happens with today’s build and the previous. Essentially, the song plays out at “ducked” volume.
Finally got time to play with this. Thanks for doing it.
One thing I noticed is if I run IVP-5.0 script it puts a Play Next marker where I expect, except if I run the script again, it deducts the intro again.
e.g. VT runs 14", Ramp is at 6", so first time I run script it places a PLAY NEXT at 8" on the VT, but if I run the script again, the PLAY NEXT now is at 2", i.e. deducted the 6" from the new place rather than old place.
Also, what build does the Envelope work on? I’m using 3.0.11 b 654 and didn’t hear any ducking?
b662 seems to be ducking rather well.Various tests seem to show the duck is ramping back up under the last part of the voicetrack, which sometimes hides the last syllable or so. Can the ramp be started at the end of VT?
Also, when I run the IVP-5.0 script it usually fails with
VP-5.0 script: FAILED: Could not process "u" code for Playlist 1, Item 6 because it is the last Item in the Playlist.
Do you have the updated bass_fx.dll mentioned by streamer? And a Ramp point defined in the songs? If so, post a (processed) MLP here and I’ll try to help.
Correct. >cough< RTFM! Because each run of IVP uses the then-current markers, you do need to load the unprocessed playlist again. Processing it twice (or more) without re-loading the original MLP will produce the effect you describe.
Can I just check that your VTs don’t have a FadeOut marker in them? If so, remove them because they will fade the VT. If not, I can adjust the ‘un-duck’ point as you suggest.
[quote=“streamer”]when I run the IVP-5.0 script it usually fails with
VP-5.0 script: FAILED: Could not process "u" code for Playlist 1, Item 6 because it is the last Item in the Playlist.
Correct. Think about it: u means ‘play the end of this item UNDER the following item.’ No following item, so the u code can’t be processed. Just remove the u code from your last item and everything will work.
Also, regarding MarkEndings, that’s really just a ‘helper.’ If it’s missing lots of songs, you could amend it very easily: it’s all in the very brief and very readable manual (HINT!).
Cad,
Attached is the sample playlist - looking at it (vs the orignal) - I see that a duck envelope is placed on the 1st song but not a restoration one however it appears to be OK for the 2nd song. I have also experienced the song not starting in sync (despite the cue markers saying otherwise) when a overlay is the 1st item in the playlist.
The song by Alphabeats in my example worked fine - but the Asteroids Galaxy Tour remained at a low volume.
Charlie: overlay in sync (as for your sweeper) is a different ending code: use os instead of o.
Bit baffled by the lack of un-duck, maybe the fadeout at 53" or so in your sweeper is ‘confusing’ the code. I hadn’t counted on a sweeper having a Big Long Tail on it!
53" ?! It’s 5.32 according to the PFL window Pretty-much all of my MMDs were created pre-v3.0, if that helps.
As for the overlay - I appreciate the end-code but I had expected a short VT to be started “in-sync” with the song (minus the 250ms offset). I think it also may have been because I reduced the offset to 200ms but when using your original script it worked OK except the issue of the 2nd item not having it’s volume restored. There is a limitation as your script states, a StartNext of 0 doesn’t work.
Can I just check that your VTs don’t have a FadeOut marker in them? If so, remove them because they will fade the VT. If not, I can adjust the ‘un-duck’ point as you suggest.[/quote]
They’re good old fashioned edited to length WAV files. Originally it did place a fade-out before the Cue Out but I’ve taken care of that because the effect was even worse. I’ll test again when I get a moment. Thanks
Hmm, you’re right, and I see what you mean, if your Ramp points are really tight (mine are deliberately 400mS after the vocal starts, to allow for reaction time). I think I need a V 5.1 which (optionally) moves the StartNext point in an overlay VT ‘forward’ by DUCK_FADE_DURATION.
[later]
I think I’ll also add ‘adjust’ durations for both ramps and outros. All of our music library’s Ramps are marked 400mS ‘early’ of the ‘real’ points, to give our presenters a small ‘cushion’ to help them not ‘crash’ ramps when talking up to them live. In a VT playlist, I’d want (need?) IVP to ‘pretend’ that all my ramps are 300mS ‘later’ than specified when arranging overlays. Other people might want a similar ‘global’ adjustment for outros/fade out points. Adding those ‘tweaks’ should help you to be able to adjust your links to sound as tight (or as ‘loose’) as you want.
I’m still getting funny results with this script… Looking at before+after MLPs, I see the envelope set to -8 but that’s all is written. As a result, the song takes it’s whole duration to restore volume. Putting in 2 envelope points manually (a -8 and a 0 about 100ms later) make it work.
My playlist was SONG,DRY,SONG,DRY,SONG and songs 2+3 both appear as isosceles triangles in Cool Edit
Charlie: Can I check that the ‘song which never un-ducks’ has at least one RAMP set? Also, that you have not marked the preceding VT’s EndType as OB (overlay bed)? Finally, that there are no warnings or other messages in the System Log?
The VT/Dry IDs were tagged as o and the songs with a overlay all had a (single) ramp. No errors - the overlaps were fine but envelopes not so fine! I did experiment with the Clear Envelopes and First Ramp settings but noubt changed.
Now I’ve just tried your v5.0 script straight from the ZIP package and it’s ignoring the 2nd song. Attached is my original playlist and the resulting one created by your original commented script (no mods by me). The first+last songs are short as I’ve moved the CueIn and FadeOut points to make the Mixdown to File a bit quicker (this also has no effect on the result)
I recall having this when I had voice-tracks that were shorter than the intro (to ramp1). I reset those to “os” and all was well. I do remember being puzzled when I had a couple of songs that were as Charlie described “isosceles triangles”.
Ah, OS seems to fix things. After editing the ducking value to -10 (as we’re now using dB) things sound rather good when blasted through a bit of MBL4 I suspect some tinkering is required as a Sweeper/VT won’t always be shorter than the Ramp depending upon what is following it etc.
Yes, as I’m ‘old school,’ IVP is built on the assumption that a VT is longer than the following item’s ramp duration.
As streamer correctly says, if the VT is shorter, you need to mark the VT as os so that the VT and following item start in sync, and the item following the VT will ‘un-duck’ when the VT ends, rather than just before its own Ramp point (which is what an o does).