willofmaine

I made a door. I made a plug-in style out of it. Then, for the life of me, I couldn't get it to install in the center of the wall... only on one edge or the other. I converted it to an un-styled door, and then I could install it in the center of the wall. So I called Tech Support. Turns out there are "Insert" (Left, Center, Right) and "Break" (With or Without Caps) options in the OIP for doors. How long have those been there?? Maybe I'm more out-to-lunch than I thought. As far as I can tell, these options can only be set after a door is inserted? I pretty much always want my doors in the center of the wall. I'd recently set a regular symbol to insert "On Edge" with "No Breaks." Hmm. Suspicious. Sure enough, it seems the default setting for these PIO settings are controlled by the last setting used to create a regular symbol??? Settings that, as far as I can tell, are entirely inaccessible both when creating a plug-in style from a door, and subsequently when trying to edit said plug-in style in the resource manager. So, Vectorworks Workaround No. 6,793,425: "Before creating a plug-in style from a Door, remember to first create a symbol using the desired Insert and Break options in order to control the OIP defaults for that plug-in style." Or am I really really missing something??? Hopefully this isn't what makes Vectorworks so intuitive... VWIS136

I really wish that surface hatches could be coordinated with their textures (I mean in actuality, not just in the texture editing dialogue box). I also wish Vectorworks wouldn't grind to a halt after I update a few section viewports. The combination of these two has cost me a ridiculous 1/2 hour trying to align vertical siding across two design layers. VWIS134 I also with that surface hatches, at least optionally, were NOT snappable! Why are they? Regular hatches aren't. VWIS135

I really, really, really wish when editing a camera via a viewport, that the camera would automatically be activated upon reaching its design layer. How often (like just now...) have I adjusted the camera, returned to the viewport, updated the viewport and... voila... no change whatsoever?! It seems very counter-intuitive to right-click on a viewport, select "Edit Camera," edit the camera, and, well, not actually edit the camera...

If you're running Safari, try closing that. That pretty much always resolves this issue for me, which has plagued me for a few years now, regardless of hardware, Vectorworks version, OS version, or Safari version.

Have you tried closing Safari when this happens? For me, doing so usually resolves this problem.

Okay, tonight I was a bit more intrepid and did a (very) little OpenGL rendering in conjunction with the Flyover ("Orbit") tool. A while later, out of the blue, Vectorworks crashed without warning. Is Vectorworks still not compatible with the iMac Pro?

Hmm... that didn't help. I've compressed the original video at least ten times at this point. Regardless of how I change the settings, the compressed video is always the same four seconds longer, with the audio always out of sync by the same amount. I finally gave up and uploaded my entire 1.8 Gb file to YouTube. Maybe next time I'll try using iShowU Instant right from the get go. In the meantime, thanks!

Ha. I just tried a quick experiment recording my Quicktime video with Quicktime, but of course the audio is then the result of my computer's microphone recording sound from my computer's speakers and, as expected, that's super lousy... And of course it would be no different if I similarly used iShowU Instant to re-record my video. Any other suggestions as to how to convince Handbrake to keep the video and audio synchronized?...

@ColinW Thanks. Unfortunately, changing the frame rate to "constant" didn't seem to make a difference. @mike m oz I'm looking at the shinywhitebox website, and just realized that for this particular project, because I've already done the recordings and assembled the final video with Quicktime, ishowU Instant won't really help me at this point? Unless maybe I play my Quicktime movie and record that... which I guess would be an effective way to introduce an "analog" step into an otherwise digital process...

So... over the course of a 15 minute video, after compression with Handbrake, the video and the audio did not remain synchronized. The compressed video is about 4 seconds longer than the original, which is about how much the audio trails the video by (at the end). I'm not sure why the audio and video wouldn't stay together in the first place, but, is there a solution?...

So far, a couple of quick experiments, and this is Fantastic!! Just a couple of short .mov files were reduced to 28% & 19% of their original sizes. Image quality not quite as good as the originals, but, just as good as Quicktime 1080 exports, and, only half the file size! I've recently discovered uploading to YouTube, where I was getting bogged down in all their recommendations, but it looks like Handbrake takes care of all that MP4 container and H.264 codec stuff, especially with its "Vimeo YouTube" presets! So... thanks again for this!

Excellent, thanks Jim!! I'll install it and take it for a spin.

Okay, thanks. I assume that if I just click on Jim's link, and download whatever's there, I'll be both downloading from the correct website and that it'll be the most current version. Why would anyone download from any but the handbrake.fr website anyway, if doing so can avoid the additional steps of checksums and whatnot?...

Okay! So I'm finally getting around to checking out Handbrake, but after clicking on the link and going to the Handbrake website, there are all kinds of warnings about verifying the authenticity and integrity of Handbrake with checksums and whosums and whatsitsums, and even GPG... whatever any of all that is... I went to the Handbrake Installation Guide and got as far as opening Terminal and typing in "shasum" (huh?), but nothing happened. And I'm pretty sure I don't want to be messing around with Terminal. So, I'm afraid to double-click on the dmg file, and generally not sure how to proceed...

Great, thanks! I wonder why nodes like this aren't part of the default set of nodes? It seems Marionette would be yet again more intuitive if all of the "Marionetteable" tools, commands, etc. of Vectorworks were represented by nodes, ideally nodes named the same as their Vectorworks counterparts... In the meantime, thanks for this!