This version of IVP is now obsolete: please use version 4.1 instead.
To all IVP users:
This version of IVP (V4.0) has been corrected to work with mAirList V3.x.
The ZIPfile contains the IVP and IVP-MarkEndings scripts (standard and fully-commented versions of each), plus a new PDF manual for IVP and IVP-MarkEndings.
If you use mAirList V3.x, please download this version and use it instead of IVP V3.0.
You may like to know that a planned future enhancement to IVP will add volume envelopes, which will fade songs in and out ‘under’ your voicetracks.
This version runs, but does not seem to work. All the files I want as voiceovers have been tagged with the ending o. When I run the script, nothing has changed. If I tag the songs in the playlist with the ending u, the script says it made changes but the files tagged with o still do not play over the song ramp.
Here’s the system log with voiceovers tagged o, song endings unmodified:
11/17/2009 8:55:35 AM Information IVP-4.0 script: Playlist 1: 6 items processed, 0 items amended (0 failed). NO warnings were issued.
Here’s the system log with voiceovers tagged o and songs tagged u.
11/17/2009 8:48:35 AM Information IVP-4.0 script: Processing Playlist 1 (6 items).
11/17/2009 8:48:35 AM Information IVP-4.0 script: FAILED: Cannot process Playlist 1, Item 6 because it is the last Item in the Playlist.
11/17/2009 8:48:35 AM Information IVP-4.0 script: Playlist 1: 6 items processed, 2 items amended (1 failed). WARNINGS were issued.
Can I ask what are the durations of your songs and voicetracks?
There are settings in the script for the durations of each. Any voicetrack longer than 90 seconds will be ‘ignored’ as being too long, and conversely any song less than 90 seconds EFFECTIVE DURATION (this takes cue in, fade out, etc. into account) will be ‘ignored’ as a song.
You might need to adjust the max. voicetrack length and/or the min. song length CONSTants near the top of the script. If you open the Fully Commented version in a text editor (or better still, a programmer’s editor which ‘recognises’ PASCAL language), you will see many more comments which should help explain how it all works.
Actually, when I’m testing the scripts, I invariably have to change the min. length of songs, because I use some music tracks which are <90 seconds long!
If that doesn’t help, please let me know and I’ll have another think, which mught include asking you to post some relevant files (but don’t do that yet!).
PS: I’d also recommend adding a DUMMY item to the end of the Playlist before you run the script. That will get rid of the ‘cannot process last item’ message. Make sure you leave the DUMMY item’s Ending Type BLANK.
The voicetracks are fairly quick 5 to 7 seconds. The songs are the usual 3 or 4 minutes.
I really haven’t taken a peek at the script yet. Maybe tomorrow.
Maybe the voicetracks are too short—if they are very much shorter than the ramps, it’s possible that no processing will get done; try changing the voicetrack endings to os, which means 'start the voicetrack and the following song ‘in sync.’ I think the manual suggests that you should do that, for cases where the voicetracks are shorter than the ramps.
There is a basic premiss at the heart of IVP, which is that a voicetrack is usually longer than the ramp of the song following it.
Oh, and it also helps if you have your outro points tagged. If there’s no Outro point, IVP defaults to the StartNext or FadeOut point. To sound ‘live,’ you’d usually want to ‘hit the outro’ as well as ‘hitting the ramp.’
Hope that helps: and please do take a squizz at the IVP manual. It’s very brief, but very informative. (IMHO!)
I’ve tried your suggestions and read the manual to no avail. Even though it says x items were amended, no item marked as a voiceover will play over any song ramp.
Please don’t be insulted by this question, but I do have to ask it: you mean that the items don’t overlap in AUTO mode, right? Because ‘overlapping’ items won’t work in ASSIST mode (it might do, if you Link all the items as well—I’ll need to check that and let you know later).
OK, apologies again for having to ask that! If that is the answer, then great! But if not:
This one might also seem patronising, but I have to check one Really Obvious thing at a time!
— Can you please check that all the ‘song’ items have at least one Ramp cue point, and preferably an Outro (or if no Outro, a StartNext or FadeOut) cue point set?
— Can you also please tell me which cue points (if any) are set in your voicetracks? Ideally, they would have NO cue points set, but a CueIn and/or CueOut is OK; I would advise removing any existing FadeOut or StartNext points in the voicetracks.
If, after all those checks, it still doesn’t work, could you please do the following:
Load the ‘problem’ Playlist, make sure the EndingTypes are all set, then Save that playlist (please name this one BEFORE.mlp).
Run the IVP-4.0 script.
Save the playlist as AFTER.mlp.
Psot both playlist file in this thread.
The BEFORE and AFTER playlists should (I hope!) help me diagnose the problem.
Apologies again that IVP isn’t working for you. :-[ Yet!
OK, I 've had a look at your MLPs and they look like they should work fine with IVP.
In fact, I took your BEFORE playlist, loaded it into mAirList here, then ran IVP-4.0 on it. I then saved the resulting playlist as the attached AFTER (Cad) playlist file. If you run that mlp file on YOUR mAirList, the voicetracks should all start in sync with the songs following them (give or take 100mS ;)).
(BTW: I think it’s a HUGE tribute to Torben’s data file design that it’s even POSSIBLE to do this: Open an mlp file on a different PC without ANY of the tracks present there, mess with the mlp using a script and Save the result, ‘return to sender’ to Open and play the amended mlp file, and voila! But I digress …)
I can presume that you run IVP-4.0 on your machine in ASSIST mode, otherwise your System Log would not have contained any messages (other than ‘please put the playlist into ASSIST and try again’!). So I can eliminate that as a cause.
Can I check that your mAirList is a) v3.0.10 and b) an up-to-date build? Ideally it should be build 649 (you can download this build from the SNAPSHOT directory on the mAirList 3 download page if your mAirList.exe is older than that), but I’d still like to to confirm which build you have there. What I’m thinking is that if yours is older, then ‘something’ in the script isn’t working (like GetEffectivePlaybackDuration for example: which is a recent change within mAirListScript itself).
So, once you’ve confirmed you’re up to build 649, and if IVP still doesn’t work properly on your PC, I can try some other ideas.
Same result with the latest release, build 649. However, I think the issue may lie with a limitation of mAirList. It seems the minimum StartNext time that works is 2000000. So if your script tweaks the playlist like this
mAirList does not start the next item until the CueOut. However, if I manually tweak the StartNext as follows
it will work. I will tweak the script to use a minimum StartNext time and see how that goes.
Edit: After further experimentation the script does work IF the voiceover is longer than the ramp. I just have this issue if the voiceover is shorter than the ramp.
Well, all I can say is that on my (now infamous) 1GHz PC with 1GB of RAM, onboard video, and a Terratec EWX24/96 sound card, the original StartNext value (=10mS) does work. So, it’s definitely not a limitation of mAirList, and must be something specific to your PC: possibly slow response from the video card.
[quote=“davect”]if I manually tweak the StartNext as follows
it will work.[/quote]
I’m surprised it needs as much as 200mS to be able to work! Does your mAirList layout contain a large number of progress bars or other objects which update frequently? That could ‘tie up’ the video card (especially if it’s an on-motherboard video chip set) and slow everything else down.
Change the START_NEXT_IN_SYNC value, near the top of scirpt, in the const section.
Yes, because IVP is setting cue point markers differently when that is the case. We already discussed this previously in this thread.
Yes: again as discussed previously. Let me know if tweaking START_NEXT_IN_SYNC does the trick (it should do). I would try changing it upwards from its original 100000 in steps of 100000 (= +10mS each time) until you find a value which works reliably. Smaller is better, because that minimises the ‘latency’ of the following track starting.
When you have the value which works for you, please let us all know, then I will add a note to the manual to help others. ;D
Important notice: When the Start Next time is modified [b|when the item is already loaded into a player[/b], and you set it to a value very close to the beginning of the song (or a Cue In point is set), the cue point might be ignored. This happens when the section of the file into which the point is set is already in the playout buffer. This is a limitation of BASS.
To work around this, you can either decrease the BASS playout buffer length, or you can re-load the players after you run the script, e.g. by switching automation on and back off (or off and back on, whatever applies).
Dave:
Thanks for the info. I’ll double check that a value of 100000 (=10mS) works here: I do have one ‘unusual’ config setting here for BASS, which I can’t remember right now, so I’ll need to check later today (that PC isn’t switched on at present).
Torben:
I understand what you say. IVP does insist that the user puts the Playlist into ASSIST mode before running the script. Personally, after I have run IVP, I (again manually) put the Playlist back into AUTO to test the newly-created segues. Would that series of actions re-load the Players as you describe?
Oh: and I also usually Save the amended playlist immediately after IVP has changed it. Sometimes, I clear the Playlist and then load the Saved playlist into it.
On a slightly different topic: I wonder if the BASS buffer issue you mentioned could be related in any way to my problem with Envelope points on items seeming not to be processed until roughly two seconds ‘later’ than they should do?
Yes, enabling or disabling automation re-loads all inactive players.
On a slightly different topic: I wonder if the BASS buffer issue you mentioned could be related in any way to my problem with Envelope points on items seeming not to be processed until roughly two seconds 'later' than they should do?
Does this happen consistently or only with some points?
(The problem was that, inside the envelope processing function, BASS reports the end of the buffer as the current position, while I assumed that it was the start.)
Make sure you leave the DUMMY item’s Ending Type BLANK.
