[VWX 2022>2023 fixtures seen as Static Accessory]

nice find, Josh!

[VWX 2022>2023 fixtures seen as Static Accessory]

Is it possible to edit the ETC Source4 LEDLS 26deg resource, and change the device type there?

[Translucent Rulers? They're not opaque?]

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!

[Translucent Rulers? They're not opaque?]

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!]

 

[Translucent Rulers? They're not opaque?]

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.]

[Auto-Numbering by position…how effective is it?]

Hi mjm;

I only see the movie of Josh's Savvy Sequencer?

[Floor Fixture Workflow]

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.

[Congrats to the Vectorworks Certification!]

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!

[2021 'Find and Modify' Lighting Accessories]

or any number of striplights [regardless of source] that need a clamp at either end?

[2021 'Find and Modify' Lighting Accessories]

5 minutes ago, Kevin Allen said:

 I wonder if there needs to be some other donation, what do we do with various type of clamps, trunions, bases and the like? How about a side arm with three T mounts?

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?

[Multicell fixtures in worksheets and datatags]

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

[Multicell fixtures in worksheets and datatags]

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.

[Survey regarding the current Spotlight LIR [Light Info Record]]

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.

[Delete unused [or used?] colors from the Color Palette?]

5 hours ago, markdd said:

This is an old one and is definitely a feature request.

Excellent. thanks for the confirmation that i'm just not missing something basic. cheers, Steve

[Delete unused [or used?] colors from the Color Palette?]

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

[Survey regarding the current Spotlight LIR [Light Info Record]]

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?

[Survey regarding the current Spotlight LIR [Light Info Record]]

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

[Spotlight Parameters: Creating Custom OIP 1]

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.

[Spotlight Parameters: Share custom OIP 1]

3 minutes ago, Kevin Allen said:

I would suggest that the default action would be for the prefs to save the settings, or at least have a pop-up ask me if I want to save the settings. 

 

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?

[Spotlight Parameters: Share custom OIP 3]

40 minutes ago, JBenghiat said:

You can already do this to some extent via data sheets. The only thing you can’t add are things like buttons or menus that populate via code. 

 

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.

[Spotlight Parameters: Share custom OIP 1]

20 minutes ago, Kevin Allen said:

 

I see this as a bug or a VE. The program identifies me in a user folder, so I assume, and I haven't dug into this, but if I ave settings "My Default," and I send a file to u=you and and you have used the same name, I would like the program to send that information to you as "My Default-Kevin Allen."

 

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?

[Spotlight Parameters: Share custom OIP 3]

Would it be possible to place this setting in both locations? My instinct would be to see it in both places, if possible?

[Spotlight Parameters: Share custom OIP 3]

While working on a Spotlight vw drawing, interrupting the workflow to change to a different customized Spotlight lighting device parameter setting can take some time.

 

Would it be possible to add an additional drop down menu item in the Spotlight OIP labeled "OIP Setting" or such? clicking on that dropdown button would reveal all custom OIP settings, allowing for a custom OIP to be selected on the fly, allowing the different custom OIP to be selected, and workflow to continue.

 

It would even be more terrific if the drop down menu included "default" and "current", allowing direct access to the Spotlight Preferences Lighting Device: Parameters dialogue box. Getting directly to the Spotlight Preferences window to either create a new customized OIP from scratch, or one modified from the current OIP, would also speed overall workflow and continuity while drafting.

 

Thanks.

[Spotlight Parameters: Share custom OIP 2]

When a customized Spotlight Lighting Device parameters setting has been saved, it would be helpful to have the options of sending multiple settings, or duplicating settings, much like workspaces.

 

It would be very helpful if all of the customized Spotlight lighting device parameter settings could be found in a single location, much like the Workspaces folder.

 

Thanks.

[Spotlight Parameters: Share custom OIP 1]

C. Andrew Dunning just sent me a vw2020 file containing a custom Spotlight OIP, or so we thought. While inside the Spotlight preferences > Lighting devices: Parameters dialogue box, i clicked on Settings: Default, and the Manage... buttons, and could not find his custom OIP Light Device Palette. Not in his document, not in Applications > Vw2020 > Plug-ins folder. Also not in Home > Library > Application Support > Vectorworks > 2020 > Plug-ins > Data folder

 

If someone creates and names a custom Spotlight OIP within a document, it appears that custom setting doesn't "stay" with a document. Presuming i've not missed an obvious clue:

 

Please make it possible for a customized saved Lighting Device parameter [OIP] setting to be transported with the rest of the document actively using that customized OIP.

 

If this is already possible, please tell me how i've missed the obvious. thanks.