Jump to content

MrTemplate

Member
  • Posts

    320
  • Joined

Everything posted by MrTemplate

  1. Hi Mauro; thanks for your screen shots. 1] are the "containers" in the container folder? and, if i'm not out of touch, the size of the containers are finite, right? that is, they can't expand their size, if the data inside the container is larger than the edge of the container? also, 2] are the data fields aligned? it would seem like the "DMX Address" data field needs to be aligned to the right edge of its container, while the "Universe" data field needs to be aligned to the left edge of its container, so the two would not overlap?
  2. Hi Mauro; I'm a bit confused by your screen shots, i'm not sure what portion of the label legend is appearing properly, and which part is "corrupted." in the top screen shot it looks like the "channel" data text needs to be "widened," so that the number doesn't potentially word-wrap? and the "universe" data text needs to be both "wider" and a larger font size to equal the font size of the DMX address and the channel texts? can you add a third shot showing the same [or similar] label legend appearing correctly?
  3. yes, multiple emitters is a good starting point. but if you're dealing with old-school three-circuit striplights do your homework, especially if you want to view the colored gel in the rendered striplight.
  4. Is it possible to edit the ETC Source4 LEDLS 26deg resource, and change the device type there?
  5. Ah! the opacity button! Broomhill for the Win! [my opacity setting looked like it was just text, no slider.] Last shot, with white fill, full opacity. thank goodness this is so well hidden... maybe it should just be a preference? rather than an interactive-buried-way-down-there setting? Thanks, Andy!
  6. hmph. that didn't work for me. the ruler [on my doc here] stubbornly refused to *not* be translucent. i can change it to different colors, but it appears to not be able to be a solid color, rather than allowing the drawing to show through from below. pictured is the rulers, using your interactive suggestion, in a lovely lavender. [and still somewhat see-through!]
  7. Hi folks; i just discovered/got tripped up by the fact that the rulers on the left and top of every vw drawing window are translucent. that is, they allow the viewer to partially see what's in the drawing, under the ruler. [i thought they were called "scale rulers," but Kevin Lee Allen tells me they're just called "rulers". whatever.] anyway, i have been looking for a preference setting to make the rulers opaque. as is, if there is a lot of shading in the drawing under the ruler, i can no longer read the text and the the numbers in the ruler due to the shading in the drawing underneath it. Kevin says it's "Vw preferences > Display > show rulers [or not]," but that just toggles the rulers on or off. i'm looking to retain the rulers, but to change their fill to an opaque while background, and *not* allow the drawing surface below to be seen. Does this already exist, and it's merely beyond my understanding? Any advice cheerfully accepted! [in the screen shot, i drew a red rectangle around the vertical ruler on the left side, showing how the shaded boom groundplan view makes it impossible to read the 10'-0" measurement.]
  8. Hi mjm; I only see the movie of Josh's Savvy Sequencer?
  9. i draw two fixtures; both are the same 2D - with "pancake" lighting devices, i draw with the lens facing straight up, [like a big circle.] for 3D, one of the fixtures is "hang", with c-clamps @ 0,0 and the body "underneath." the second version has suffix "FLR", or Floor; fixture flipped, the bottom Z of the base is at 0, but body still has lens pointed down. simpler for me; the 2D doesn't change, the 3D is aligned properly.
  10. I don't get out much. Last week i noticed a colleague announcing she had achieved a Vectorworks Certification, and i had no idea what she was talking about. She provided me with this link: https://university.vectorworks.net/local/certifications/info.php?fbclid=IwAR0TIHprpvJBdeCX6tzYCcocm_zYzwMgJmecN2S3ouJu8v5_zOtPCrj-Wrw While i initially poo-poo'ed the effort, i'm now about half-way through the tools, and find myself applauding explanations provided with visual demonstrations, allowing me to grasp tools and purposes like i had never understood before. So, congrats to all who were involved in this massive task! Last thought; it might be worth considering linking some of these topics to the help file, so that folks struggling to understand all the written words and diagrams might have an alternative explanation. just my .02 Congrats again!
  11. or any number of striplights [regardless of source] that need a clamp at either end?
  12. Excellent thought, Kevin Lee Allen. There's all sorts of clamps and stands and sidearms and stuff that aren't hanging positions, but they're not lighting device add-on's, such as gobos or irises, or scrollers. The list could go on and on. it could be said that they should be segmented away from "accessories" and placed in their own category?
  13. whoops; here's the file. if you look at the unit number in the label legend, you will do a Kneau Reeves "whoa...."x-sample multi-strip vw2022-2.vwx
  14. Hi folks: Just catching up. I'm behind in my vw2022 builds, but i just ran an experiment on a 3-cell striplight. while the current OIP method of handling 2D label legends on multi-circuit are byzantine, confusing, time-consuming, and work-flow interrupting - again, this may have gotten streamlined in later builds - i was able to produce a 3-circuit striplight, with three separate label legends - one for each circuit. Each label legend accurately displayed the correct data color, channel, and purpose, and i presume if i added more information into the label legend it would have displayed that data as well. When i was testing this last spring, i was so agog by the reverse engineering on multicircuit data entry in the OIP, I sadly didn't even experiment with label legends. Back to the present: i've now edited the label legend three times, and the resulting "unit number" data field is *still* not graphically reflected in the drawing, where i placed it in the label legend layout. Jeroen, while i think you may not be totally accurate in your criticism of label legends, i agree that your general assessment regarding multicircuit data and label legends workflow needs a *lot* of help.
  15. Hi LenLindhout; Glad to hear you've got a solid process for your research workflow. I remember when comparing two fixtures from the same manufacturer or different manufacturers was as simple as pulling out two different hard-copy catalogs. But in today's world those simple comparisons are in the past. Older friends of mine have often lamented that manufacturers websites are byzantine affairs, and parsing through and comparing attributes between fixtures can take hours of time. While double-checking information for minute details makes perfect sense, it's always seemed to me that conducting general selections between two different fixtures from two different manufacturers would be better served with accurate information provided in the LIR [or possibly an alternate LIR, but hopefully still accessible.] This thread has shown me that there is more than one possible solution to this challenge.
  16. Excellent. thanks for the confirmation that i'm just not missing something basic. cheers, Steve
  17. Hi folks; This is probably so fundamental it's embarrassing but what the heck. I'm working on an object library that, for whatever reason, now has five different shades of red in the color palette. [probably where i created notes that i wanted to easily see, in several different iterations in the past versions of this document.] i'm now trying to polish the final version of this document, and eliminate all of the different reds - there is no longer any red-colored anythings in the document. i tried a resource import, followed by a copy and paste into a fresh document, but no good. the old reds are still sticking in there. Is it possible to somehow get "under the hood" in the color palette manager, and delete colors that are no longer active? or colors that were once created, but now no longer have any reason to exist? i'm just trying to clean up the document and get rid of the unneeded reds. any ideas or tactics gratefully accepted. all the best, Steve
  18. Hi Mark Aceto: don’t worry about the dumb-dumb questions, i ask them all the time. Yes, the original default LIR [for conventional fixtures] was viewed as complete; its default data had all the “must-haves.” As long as you used that LIR without editing the record itself [by editing it in the Resource Manager], you could include any information that you wished in any of the data cells. If you want to change any of the information attached to any symbol, so that it would appear every time that symbol was inserted in a drawing, you merely select the symbol in the Resource Manager, contextual right-click while it’s selected, and select “Edit 2D [or 3D] Component” and release. the resource is revealed, as as long as nothing is selected in the window, the OIP data tab will reveal all the default data. Change any data in the LIR and “exit symbol” and the default information for that resource will be locked in. If you change any element of the LIR itself, however - by changing the spelling of a data cell name, rearrange how the cells are ordered, or add another data cell, for example, while *maintaining the same LIR name* - the LIR is now *different*, and any time a symbol with the original LIR is imported into that drawing you’ll be presented with the dreaded “Resource Name Conflict” window. So the only way to add your “nice-to-haves” and not get tripped up by the “Resource Name Conflict” is to fit in your “nice-to-haves” within the confines of the current LIR. With the massive expansion of moving lights and LEDs over the last 30-40 years, the number of attributes has extensively expanded, but the LIR didn’t really add any fields until vw2022. and as you mention, the main field name additions was in regards to GDTF. So even now, when I import a pre-vw2022 lighting device into a vw2022 spotlight workspace, i get the “Resource Name Conflict” window. In my rough tests, choosing to “Keep and use the existing format” [i.e., the new Vw2022 LIR] has translated in the loss of weight and GDTF information in the LIR for that imported symbol. [The jury is still out on this; there may be other implications I’m not yet aware of.] While I’m all for assigning the responsibility of data information on the GDTF format, in two experiments of importing GDTF downloads from Ayrton and then importing either of them into vw2021, results in two 2D symbols that contain no data information whatsoever. So if I’m looking for data information from a GDTF, it seems like that’s not yet regulated or scrutinized for accuracy?
  19. Hi folks: I've been constructing a Vectorworks resource for the Perseo Profile, an Ayrton moving light symbol, that will be included in one of my SoftSymbol libraries. As usual, when it came to filling out data information about the lighting device, I ran out of data cells in the current Light Info Record [LIR.] In this case, i wanted to mention at least some of the specific features about the Perseo Profile that sets it apart; 4 shutter blades, 7 rotating and 11 static gobos, 2 rotating prisms, CMY color mix, CTO color correct, 6 complementary colors, an IP65 rating, along with many more. There are *no* data fields in the current Vectorworks LIR for any of this. Attached is my workaround to fit as much of this info into the current LIR as I can, and it's not pretty. The nice folks at Vectorworks tell me: "why do you need this data? The way the LIR is designed it¹s a fixed length for all lighting devices where as the GDTF is a variable length and contains a lot more data in a standard format that is useable by everyone." When i'm drawing a plot, I typically compare fixtures between one another to make sure I'm making the best selection. Beam spread and photon output are certainly two considerations, but when it comes to moving lights [or many other lighting devices,] knowledge of other attributes can also quickly become necessary in order to select the proper lighting instrument for the job. After a quick review, it seems GDTF is not yet ready for primetime; it is still a work in progress. [I still haven’t included it in my workflow.] So with that in mind, here¹s a quick survey: If you were given the choice, would you like an expanded Light Info Record listing more comparative attributes for different light devices? YES i'd be thrilled to know more about the different attributes of each moving light [or other lighting devices] while i'm drawing a Vectorworks light plot, *before* entering GDTF, MVR, or Vision environment. NO I don¹t need to see that information until *after* Ilve left the Vectorworks environment. Please respond to this survey. Yea or nay, rant or rave, I’d like to know your thoughts. I’ve been struggling to fill in additional information in the current LIR, and if no one cares about seeing this additional data, I’ll stop doing it and save myself some time. Thanks! All the best, Steve Shelley
  20. As i was responding to Josh Benghiat's post, i remembered a wish i had made while constructing a custom OIP palette. I was working on my seminar that discussed combining three light plots in a repertory situation, and I wanted something that would visually separate groups of text about Show 1 from groups for Show 2 or Show 3. i ended up using the "Edit," "Replace with Active Symbol," and "Refresh Labels" custom control buttons as separators between the three groups of text, because they stuck out more, all the way across the palette [Rep OIP for LDI-parameters.jpg attached.] This resulted in the OIP where the group of text for Show 1 was clearly separated from Show 2 or Show 3. Would it be possible to instead have an alternate visual layout tool like the Separator line from the Workspace Editor dialogue box? That too could extend the full width of the palette and be used to separate groups of text, instead of relying on Custom Control buttons - i think the "Refresh Labels" button was more of a visual separator than a function i used often.
  21. sure, but i believe it would be most helpful to single out exactly which settings were potentially going to be saved. "Do you want to save "My Default-Kevin Allen?" rather than merely "do you want to change the changes made to "LightingDeviceParamsSavedSet.xml". It would also be helpful if any or all of these settings could be saved in a more findable folder? I *think* i found one of my saved OIP parameters in Home > Library > Application Support > Vectorwor> 2020 > Plug-ins > Data? How about the Settings folder?
  22. Well, that sounds sort of helpful. If the data sheet doesn't include buttons or menus, that wouldn't be a complete solution for my use. I use the Custom Control buttons as "headers" in the OIP to shape the layout of the palette and make it simpler to read through the groups of data that i've sorted for my use. and sadly, once you say "code" my eyes glaze over. in that regard, i'm just a dumb end user.
  23. Much more elegant that my reaction, Kevin. I would presume the same-named file would be identified as "My Default-1". I like your proposal much better. It would also seem, in this scenario, that unless i used "My Default-Kevin Allen" [aka "My Default-1" that the incoming customized OIP would only be temporary, and would disappear once the document was closed, unless the incoming OIP was used?
  24. Would it be possible to place this setting in both locations? My instinct would be to see it in both places, if possible?
×
×
  • Create New...