Ritsmer, you're using VP13, right? And by "wondrous", do you mean "mysterious"?

Right: I have VP12, VP13 and VP14 installed - but mostly I use VP13 because it is so super stable here (not like VP14 is not - just like I mostly tend to start VP13 knowing it works so well)

Wondrous? - well not quite "mysterious" - that would be too strong - more like "I wonder what..." - but again: maybe it is not the proper usage of "wondrous" in daily english language.

That said I'm looking forward to learn what the VP14 HFR support really is - and hope that someone from the Vegas staff will give a good answer to your original question.

In VP14 this is for a simplified use of HFR media as slomo clips.

Say you use a 200 fps clip in VP13. If you add it to the timeline you've got the option of adapting the project properties to the file properties which will then make the project have a fps rate of 200. You cannot enter a value of 200 fps manually as project property, 120 fps is the limit. But with adapting the HFR clips it is possible, even in VP13. If you don't use this choice you'll end up having a 200 fps clip in whatever framerate your project is. 
In both cases, if you want to use the HFR clip for a slomo, you need to make the slomo manually.

In VP14 you've got an additional choice for using HFR clips by right-clicking them in Project Media and selecting "Add Project Frame Rate" (or in the timeline using the clip properties and clicking "Adapt to Project Frame Rate") . Doing this while not adapting the project properties to the clip, it will automatically time stretch the clip by altering the playback rate (and, if necessary, also using a velocity envelope) and all the additional frames will make a perfect slomo according to your project settings. 

If you use a project setting of 25 fps while using a HFR clip with 200 fps, in VP14 this option will automatically make it a 12.5 % slomo.

BTW – If you manually type in the frame rate value in the project properties, it is still limited to 120 fps in VP14, while – same as in VP13 – adapting the project properties to the clip properties will use higher frame rates.

Thank you Marco for the explanation. I should have read the manual as there are references to this. I am using VP14 build 189.

Event Properties > Confirm to Project Frame Rate

For an event on the timeline, "Conform to Project Frame Rate" in the event properties is working correctly for me. It firstly reduces the playback rate until it reaches the permitted minimum of 0.250, then it adds a velocity envelope.

Observations/Suggestions:

1. This mix of playback-rate + velocity-envelope to achieve the desired speed seems clumsy and confusing to me. I would prefer to see the two directly linked, or a much wider range of permitted playback speed (beyond the current 0.25 to 4 range).
2. I would like to see another button in Event Properties that does "Conform to Project Frame Rate and proportionally elongate event". e.g. If there is a 1000-frame/100fps/10-sec-long event on a 25fps timeline, that button would make the event 1000-frame/25% playback rate (25fps)/40-sec-long.
3. The manual on "Conform to Project Frame Rate" says "Click to adjust the playback rate of a high-frame-rate clip to play using the project frame rate". I think it should not just reference "high-frame-rate". This command can conform "regular frame rate" 25fps, 30fps etc. to slower frame rates, and it can even be used to increase the playback rate.
4. We should be able to manually set project properties to a much wider range of frame rates, up to and including 1000fps. Why not? Why should that only be possible by matching an existing clip?
5. More frame rates should be offered in the drop-down list.

Project Media Window > Add At Project Frame Rate

This just isn't working for me. When I click it, media does not get added to the timeline. Please others confirm or otherwise before I submit a support request.

And again, the manual says "Add a high-frame-rate clip to the timeline and adjust its playback rate", which unfortunately implies that this only applies to "HFR" clips (whatever those are), whereas it can be used for media of pretty much any frame rate.

Also, in both sections of the manual it says "For more information, see "Working with high-frame-rate (HFR) clips.", but the link is broken ("This page can’t be displayed. Make sure that the web address //ieframe.dll/dnserrordiagoff.htm# is correct"). Please others confirm.

Strange, here it works fine using "Add at Project Frame Rate" from Project Media and actually this puts the slomo version of the media in full length into the timeline. A 200 fps 10 second clip in a 25 fps project is added as 80 second slomo then.

Thanks Marco. It just doesn't work for me. The file doesn't get put on the timeline at all, and I've tried lots of different files and frame rates. Could some other people test this please?

If this worked, I would like to see it also added to the menu that appears when media is dragged to the timeline from either the Project Media or (Vegas) Explorer window.

Works here too (except broken link in Vegas help)

Thanks for the testing. It appears to be a bug when the project media view is set to "Details", which is what I nearly always have set.

Please test and confirm as follows:

1. Start new project
2. Add multiple video files to "Project Media"
3. Set Project Media to "Details" view
4. Right click a file > Add at project frame rate
5. Result = fails
6. Set Project Media to "Thumbnail" or "List" view
7. Right click a file > Add at project frame rate
8. Result = succeeds
9. Set Project Media back to "Details" view
10. Right click a different file > Add at project frame rate
11. Result = adds the previous (incorrect) file to the timeline

I confirm, there is a bug in Details view. All steps the same , but

5. Result = adds all files to the timeline

Thanks guys. I will log the bug. Your input on the Playback rate limit is timely too because we've just been discussing that. There reason for the limit is that the Playback Rate setting (unlike event velocity envelopes) also stretches the audio. The current limits are as far as we can go and still maintain somewhat usable audio. I've been arguing to increase the limits in both directions, but the question then becomes "what do we do with the audio?" If we go beyond the current limits, what would you like to see us do to the audio? I think we should just silence the audio, but that might be a jarring thing to do that will confuse users. The other thing I'm contemplating is to add the conform operation to the velocity envelope where there is no audio-induced limit. I'm interested in your thoughts on this.

The missing help topic bug is known and fixed for the next update.

... but the question then becomes "what do we do with the audio?" If we go beyond the current limits, what would you like to see us do to the audio? I think we should just silence the audio, but that might be a jarring thing to do that will confuse users. The other thing I'm contemplating is to add the conform operation to the velocity envelope where there is no audio-induced limit. I'm interested in your thoughts on this.

How about 'temporary-ungrouped' operation of them. So both video and audio can be 'stretched' together until the 'audio limit'. After reaching the limit, the audio is no longer stretched, but the video part can be kept stretched. There will be different length of them, but they are still grouped.

I've never used slomo audio to a slomo video clip but a replacement audio instead. So I wouldn't mind muted audio in this case.

How about 'temporary-ungrouped' operation of them. So both video and audio can be 'stretched' together until the 'audio limit'. After reaching the limit, the audio is no longer stretched, but the video part can be kept stretched. There will be different length of them, but they are still grouped.

+1

Thanks for the explanation Gary. Personally I would just allow the audio to go "unusable". Nobody is going to be too surprised that happens, and I bet the vast majority of users who want to do slower than 25% slomo will just dump the audio or not really care about the quality. But Set's idea, or just muting the audio, would be acceptable options too.

I don't see a compelling reason to change to conform using the velocity envelope rather than the playback rate. I think it's OK to continue using the playback rate until it maxes out. Of much more interest to me would be a way to automatically, proportionally extend (or contract) the event to show the same number of frames after it's conformed (#3 in my suggestions above).

Beyond the 50% slower or faster I also did never use the audio, so muted is no problem for me as long as it is possible to edit the original audiofile.

+1