Feature Request: Batch NFC Settings Push

When setting addresses and menu options on a large amount of fixtures, a batch push menu is really needed.  I'll call it batch set mode.  An idea of the functionality we're looking for is:

On enter Batch Set, select the fixture and ALL possible configuration settings ( I know expanding this is in the works).  The settings should probably be in a popup window so they can hide when set.

The main screen would have a calculator style number pad for direct number entry, as well as selection of offset options similar what is available in the existing Create Device screen.

When in this mode, NFC should be always active, and each push should increment the address as configured above, as well as being able to directly key in a new address.

It would also also be nice to have an optional ding or buzz sound effect option on success/fail of the push.

The current approach in SetLight of creating a "device" and selecting then pushing that device isn't really workable when addressing on the order of hundreds (or even many tens) of fixtures.  Especially when start addresses and spacing may vary.

  • Hey C.Osborne, that's right we have this on the backlog. The current train of thought on our approach to this is:

    1. Create multiple devices via the Device Wizard using the addressing/offset functionality.

    2. Select those devices just created (Select the group if you also created that with the devices in the Device Wizard).

    3. Tap on NFC -> "Push Configuration" and present a new "Batch Push Configuration" page. The idea here is that we would provide the following options:

    - Sorting e.g. So that you can specify the order in which the NFC taps would need to go in.

    - Disabling specific properties e.g Allowing you to only change the DMX Start Address, rather than push all the configuration options (Personality, Device Label etc.).

    4. From this view create "Manual" or "Automatic Push" option:

    - Manual would mean you would need to go to each fixture (paginated view) press "Push" and on success it would potentially move to the next device but ultimately you would need to press "Push" each time.

    - Automatic Push would probably allow you to set a time and then after pressing something like "Automatic Push" on the first "Push", on success it would automatically move to the next device along the batch of devices and be ready for the next tap. The idea here is that you would press "Push" once at the start of tapping all your fixtures and then "Tap", Tap", "Tap" along your line of fixtures.

    We could also perhaps omit the actual creating the devices and just put a "Push" on the final page of the Device Wizard. At some point though in this whole workflow you need to specify the model, personality, amount, start address, offset etc, which is what the Device Wizard does.

    Are you part of our beta testing group? It would be amazing if we could get you included and push beta build to you for you try.

    Thanks so much.

  • Thanks Sammy.

    I like the enhancement of adding batch push to extant devices, and the workflow there you describe seems reasonable at first glance.  Especially the addition of adding toggles for pushing specific properties.  I can certainly see the benefit of being able to push address/mode/pwm but not multiverse, for example.

    The "Manual Mode" vs "Automatic Mode" sounds workable here as well, for the case where you have existing devices defined.

    The specific challenge I'm trying to solve for here is a large number of fixtures with arbitrary start addresses.  Which is to say If I hang 200 fixtures and use 2 different modes depending upon purpose,  I potentially need to create 200 Devices in the app (or at least one device per start address per mode).  Then I need to somehow navigate the menu structure in some way to find the correct device.

    We could also perhaps omit the actual creating the devices and just put a "Push" on the final page of the Device Wizard. At some point though in this whole workflow you need to specify the model, personality, amount, start address, offset etc, which is what the Device Wizard does.

    I'm perfectly happy with this approach.  I want to define a device, but I don't want to go shopping for a *specific* device every time I hit one.  It would be perfectly fine to create one device, touch "Batch Push" or whatever we call it and move on to pushing the addresses.  

    What about the idea of creating template devices?  I could create a device to match each fixture configuration on a show, then select it as the template for a batch push, changing only the address as we go.  It would be nice to be able to isolate this so that only address settings are changeable on the batch push screen.

    The important thing is quick easy address incrementing.  I'd imagine the batch push mode changing to a different screen with various auto increment and direct entry tools as I loosely described in the initial post.  Mostly things like +/- footprint, +/- offset, +/-, 1, 5, 10, and a quick way to enter a completely new address.  Doesn't necessarily need to have all of these, but you get the idea.  Navigating the spinner alone to set addresses is tedious.  Any widget that is touch-to-enter and touch-to-exit adds at minimum 2 extra touches to each push action, which adds up.

    Managing Multiverse settings becomes a problem at this point.  Maybe that is solved by adding an optional step to also configure multiverse during this process.  I think it could be a separate screen.  Or maybe this goes back to the template device and we make one template per multiverse universe.  I'm comforted by the fact that multiverse settings will change much less frequently than addresses.

    I'd be happy to join the beta for the app.  I've been away for the last week, but will have a chance to take a look at these things again very soon.

  • This has given us a lot to think about.

    I think you're onto something with using a single device as a template for a batch push. I imagine then that when selecting a single device we would have two options in the NFC menu, "Push Configuration" and "Batch Push Configuration".

    One thing we want to do is sync up NFC pushes/pulls to devices within Set Light. So when you pull a configuration via NFC it creates a device or updates a device if we have one already within Set Light. This allows us to build a history when devices were configured either via NFC or RDM, which in turn could allow us to create paperwork to say "At 3pm these lights were configured via NFC/RDM at these settings". We also have thought about a Lightwright/Excel import to make the devices... Still lots to plan out.

    I can see your point regarding direct entry of values, personally I enjoy the spinners (they also took some programming too!). The main point I took with them is that they validate entry really nicely. We strive with Set Light to not allow the user to enter invalid input. It's very hard to put in something that isn't valid and with something like the device wizard where different amounts, footprints and addressing effect how many devices can fit within a universe, it becomes incredibly cumbersome to show validation rules as data is being entered. Everything starts to become a clunky web form if you do textfields and keyboard entry for everything... That said I do think there may be something in a double tap of a value which allows keyboard entry of values for the advanced users who know how many channels are in a universe.

    Would you be able to email me your Apple ID to sam.smallman@etcconnect.com I will have you added to our beta pool. I can't promise we will get to batch push in the forthcoming 1.4.0 as we're mainly tackling all things RDM but it's certainly high on the list for whats next.

  • Interesting idea about the device history.  Would that configuration history be stored locally on the fixture and the sent to SetLight on each push/pull?  Would it be accessible via RDM as well?  Would it also sent manual configuration changes at the fixture control panel?  I admit I can't immediately think of a use for this information other than perhaps a service record.  

    Lightwright/Excel Import/Export would be of tremendous help here as well.  That opens up a more reasonable workflow for device creation.  Creating 200 devices with irregular Channel and Address assignments would begin to be reasonable.  This leads directly into a question about saving and loading "show configurations" on the app, and sharing them via airdrop. 

    This would help in a couple ways.  1. Those of us in the freelance life could easily manage configurations for our various jobs.  Both concurrent one-offs and different venue house plots.  2. Segmenting the complete show into sub-categories (say, by position) to reduce the search space.  3. As a production electrician I could build the show configuration and then air drop to multiple techs to go do the actual address/mode setting work.

    With the data analytics and potential for data import export from SetLight, is the fixture name field planned to be one of the available fields?  What about also adding a Fixture ID field?  Then I could include channel and purpose/position/other metadata in the device.  And, of course, I'd then ask for a firmware update to display this info on the fixture display.

    Re: the spinners, I definitely take your point about data validation at the user input point.  And also the desire to avoid a clunky web form look and feel.  It's important to consider all these things. And indeed I don't really have much issue with the spinners for other menus, my slight rant below not withstanding.  It's only the address selection (and other number fields like gap) that I take issue with.  I have similar feelings about the arrow for choosing the number of fixtures to create, as tapping the > button 30 times to add a block of devices also gets old.

    I know spinners a fairly ubiquitous modern UI design pattern at this point.  Much of this is personal opinion, and full disclosure I've NEVER seen a spinner UI element in any app or web form that I liked or felt was an appropriate choice over any other option.  Maybe I'm old fashioned that way.

    My beefs with that particular UI pattern are:

    -the previously mentioned extra clicks to enter/exit,

    -it is slightly un-intuitive exactly where to touch to close the spinner,

    -it is easy to slightly miss the spinner touch area and scroll the screen instead,

    -it is always in a different physical location on the screen because it it drops down on an already scrolling screen,

    -and, most of all,  I have to watch the screen 100% of the interaction to see what number is centered on the indicator, but the indicator is under my finger, so I have to guess the position and then move my finger to check - for each digit in the number.

    I wouldn't mind so much if it was a one-off or relatively low frequency form, but going back to my original starting point on the thread, doing that for hundreds (or even tens) of fixtures, it just doesn't scale well.  Compare to a simple calculator style number pad where the buttons are always in the same place it it takes three muscle-memory taps to choose a new address.  

    In typing out the above, one thing I see repeated with regard to data validation and the less experienced user is managing the number of fixtures that fit in a universe.  In general, especially when thinking about the Lightwright / csv import development process, I'm not in a single-universe situation.  One reason for my beef with the spinners trying to help.  Circling back to my thought about storing "shows" as well as the data validation concerns, what about having user-configurable Universes?  This would help with data validation, make it so I don't learn to ignore the issues warning that pops up when two fixtures have overlapping addresses, and would be a convenient bucket for storing multi-verse settings in as well.


  • There's a lot to digest there. Let me try and comment on each point.

    Configuration History: It would only be possible to store this on Set Light as fixtures do not have the space or really the inclination to store this data. Essentially it's about recording when a configuration was set or retrieved and could be useful for a hire technician when they're NFC tapping their fixtures or configuring them through RDM. The idea being that a technician has 10 lights, configures them each, and could produce some paperwork to say, these 10 lights were configured this way at this time. With Set Light there are currently two different ways to configure a device, NFC or RDM via Multiverse. When connecting to a device via RDM it's easy to say. "That light is configured to these settings" because Set Light keeps in sync with the current state of the rig, even if someone changes the address at the back of the fixture. If though the device is unplugged and goes offline, or someone taps that device via NFC after you did, there's no way to say what you have in Set Light is the current state of the real world device, and so really its about adding a timestamp onto state. The key point and useful thing really for the user is "I configured these lights at 3pm before they went on the truck, here's the paperwork".

    Saving and Loading "Show Configurations" is definitely on the list. If I understand your second point relating to saving, you would like to save a segment of devices into a configuration file? That will certainly be possible. It will probably be a select one or multiple devices and export and then an Import option somewhere to take one of those "Show Configuration" files. Point three regarding air dropping to multiple techs could easily loop back to configuration history. You could segment out your config to your techs, they could do the configuration, export the work they've done, you import all of them into your Set Light and you'll have timestamps of the configurations they've done, hell you could even have user data attached if you wanted to know who did what.

    Fixture Name and Fixture ID: I'm not entirely sure what you're asking for here but... Set Light uses the RDM Device Label as a way for a user to uniquely identify one device from another in a human readable way. We could use the RDM UID but it probably wouldn't make much sense to the average user. RDM Device Label is a slightly tricky subject as technically speaking the RDM Device Label is not a required parameter for all devices that implement RDM, but on the whole and realistically almost every fixture implements it, which is why we use that. It is also the only standardised way across multiple fixtures of different makes and models to hold "meta data" on the fixture. So I guess my response is: Use the RDM Device Label, you have 32 ASCII characters e.g. "Ch 1 : DSL". Your point regarding asking for firmware updates is also an interesting point. The majority of ETC fixtures do show the RDM Device Label, but it is typically hidden in some diagnostic menu. Whilst I believe it would be nice for the display to show the label in bold somewhere on the home screen there is also the problem of how manufacturers default the RDM Device Label to typically be the model name. We do currently have a conversation within ETC to try and at least have those RDM Device Labels default to the model and serial number so they're not all the same... Which would certainly reduce the amount of "Label Issues" a user would experience as soon as they connect Set Light to their brand new fixtures.

    Let's table the discussion on spinners for another day. I'm sure people have strong opinions on one way or the other. The reality is we wont be tackling this any time soon for the device wizard, certainly not for "Start Address" and the "Offset" and "Gap" options, I will write up a ticket for "Amount" to receive keyboard entry and we'll certainly bare all of your comments in mind for new workflows.

    Universes is a tricky subject. Technically speaking standard devices receiving DMX512 have no idea what universe they are on. That said we do need to tackle Multiverse universes and when we do should certainly take that parameter value into account when showing a DMX Address warning. This also opens up the question of meta data fields and do we begin to have a "universe" meta data field... I don't necessarily have any strong feelings at the moment towards this other than that Set Light currently represents only the real parameters and values of a device. Meta data would only ever be saved/viewable in Set Light and would only ever be transferable to another user by an export of a "Show Configuration". I guess this might have been what you were asking for with Fixture Name and Fixture ID...?

  • For sure this has become a giant thread.  Going for a little brevity this time.
    Re data storage, 

    Good point about the rental house work auditing application.  I was definitely coming at it from a what is the current real world state point of view.

    Your comments on the save/load show configuration are spot on.  Some additional local metadata fields based on Lightwright or Excel fields (position, purpose, Universe, etc) and the ability to filter on those fields would make managing large quantities easier.

    Fixture Name & Fixture ID.  I'm exactly suggesting mapping the "Name" Field in SetLight to the RDM Device Label field in the fixture.  

    The FIxture ID suggestion is an additional field, not part of the standard RDM paramaters.  This something that some moving light manufacturers have been doing for a while.  A local fixture id field, configurable at the user interface.  When set, this field can be shown on the menu screen in big, friendly letters.  The idea is you can set the fixture ID to match the show "Channel" or "Fixture" ID (language depending on console choice), and then when I need to go focus channel (113), I simply walk the pipe looking for the light that says "113" on the menu in giant letters.  No looking for sticker labels or gaff tape on the yoke or body or fallen off onto the floor.  Label is built in.

    I've certainly said all I need about spinners for a while.  Thanks for listening!

    Multi-verse aside, I think there are two big arguments for tracking universe as a local metadata field, and for SetLight becoming Universe-aware in general.  

    1. SetLight flags as an issue any address collision it detects, but is not universe-aware.  This means that the minute I use more than 1 universe, the Issues flag is expected and will be ignored.  This makes what is a great idea, letting the user know when there is an address conflict, nearly useless in practice

    2. In considering one SetLight device corresponding to one real-world fixture, it is highly likely that I'll have multiple fixtures with identical settings, save perhaps the Name.  In my Batch-push identical settings scenario, this is no big deal*.  And of course, SetLight already allows for multiple fixtures with identical start addresses.  Now let's say I want to change the mode or some other setting on one of the otherwise identical devices.  I currently can only use the Name field to locate the fixture (only 6 chars in tile mode on iphone 6s!).

    Yes one aspect of what I was getting at with Fixture Name and Fixture ID (tied in with Excel/Lightwright import/export) is that once we're talking sharing data with other applications I need more metadata than is currently available in SetLight to match a SetLight device to a Lightwright fixture.

    * If the goal is to have 1:1 SetLight device to real-world device correspondence to support this additional data tracking, is there a reasonable way to have set-light create a device every time a Push action is taken from a template device?  Putting the cart before the horse on purpose, so to speak.

  • The name or "Device Label" field in Set Light does directly map to the RDM Device Label field in the fixture... Are you seeing it not somewhere?

    I don't suppose you know of a fixture from memory that implements Fixture ID. I can then look into how we might add that. If it's not a standard RDM parameter this might be tricky to implement as there is no library of RDM Manufacturer Specific Parameters, we sometimes get given a few by other manufacturers (city theatrical etc.) but on the whole we don't know about other peoples pids... So to begin with we'd have to start making one, and then we'd have to build some kind of mapping system to say, ETC's Fixture ID parameter should be considered the same as Clay Pakys Fixture ID... Lets do some more research on that.

    We certainly want to make Set Light universe aware, there are a couple of things to consider, most notably whether we consider the multiverse universe RDM parameter, the E1.37 Endpoint ID/Universe and a metadata universe number all the same thing... Bare with us while we figure that one out.

    I think in point two you're advocating for the universe to be displayed on the tile as well as the start address? I think thats a great idea. I imagine we'll probably do a similar "Universe / Address" thing our consoles do. You also clearly point out the reason why in Set Light it gives label issues. The device label is the only way to uniquely identify one device from another in a human readable form that is standardised across manufacturers/models. It's not a good idea to have them the same... The only other way would be to present RDMUIDs and generate temporary ones for devices made through the device wizard... Those numbers would look pretty confusing and would be uneditable. I also thought the device label presents as 8 characters in tile view... I'll have to check! The very general idea would be that the Device Label would be set to "Ch 1" or just "1" corresponding to a consoles channel number and so 8 digits seemed enough. I feel like I also took the number of characters from Cobalt and what they display on their tiles...

    In regards to your final point, we certainly do intend to have each NFC Pull configuration to at least give a choice or perhaps an opt out to make a device. This wasn't possible in the first version of fos/4 which is why it doesn't at the moment but everything forward of that including all the other family of fixtures that have NFC tags on them allow us to clearly identify a device uniquely and be able to make a device from it. NFC Pulls would also update a device if it already exists in Set Light.

  • Adding on to the Name/Device Label conversation... Uniquely identifying one device from another in a fast, easy, reliable (saved on the fixture) way strangely has been one of those oddly harder things to do. This really is the big difference between patching a light on a console and a configuration tool like Set Light. The ultimate solution is the RDM Device Label, but as spoken about above is difficult because models by default typically come from the factory with a really long name typically "<model>_<serial number>".

    To the point I actually wanted to make: There is a "Identify Mode" for this very reason, which was built because we knew labels would need to be set first and easily. "Identify Mode" can be set from the options (hamburger) menu and when set it puts the devices view into single selection mode and more prominently shows you the online devices. Each selection will toggle on/off the RDM identify parameter on devices accordingly so that only the singular selected device should be identifying. A double tap of the tile allows you to then relabel it.

  • The name or "Device Label" field in Set Light does directly map to the RDM Device Label field in the fixture... Are you seeing it not somewhere?

    That's great.  I probably should have phrased my comment differently, as I simply haven't yet connected to the fixtures through RDM yet, so I haven't seen in practice.  I'll have to set up a small test rig at some point.

    Re the Fixture ID, The Martin Mac III and Viper lines implement this.  I should be clear that as far as I'm aware (and I'm going by memory here, the User Guide does not list PIDs), they implement it as a LOCAL setting only.  It's not viewable or settable via RDM.  It's just there to help a tech locate a light in the field.  I think making the setting accessible via RDM would be an excellent enhancement to the idea.

    We certainly want to make Set Light universe aware, there are a couple of things to consider, most notably whether we consider the multiverse universe RDM parameter, the E1.37 Endpoint ID/Universe and a metadata universe number all the same thing... Bare with us while we figure that one out.

    Yeah the integration there looks like it will be a bit complicated.  I don't have any multiverse gear at present anyway, though will probably acquire some in the next few months.

    I think in point two you're advocating for the universe to be displayed on the tile as well as the start address?

    This is a yes-and kind of thing.  Yes to displaying the Universe in the tiles.  In addition, filtering the view and the address collision detection by universe.  So we can view just one universe worth of fixtures, and we eliminate the nuisance Issue warnings.

    I agree displaying the RDM UIDs isn't helpful at all.  I think just having the universe added on the tile, so i can look for Device 31/001 neatly solves the problem.  Especially if you add sort and filter options.  

    Your suggestion to use the RDM Device Label field is a good one, and one I intend to use for the time being.  It's simply not practical at the moment with large numbers of fixtures, as I'd have to manually set each label one by one.  Lightwright/Excel import will be a game changer.

    Great to hear re pull actions creating or updating devices in the future!

  • Am I correct in thinking that Identify is only available when connected via Bluetooth to a DMXcat or Multiverse Transmitter?

    That's a useful tool for sure.  

    Looking WAY down the road, is there a hope to make SetLight able to act as an RDMnet controller in the future?  

  • Yes you are correct, at the moment RDM is only available when connecting to a City Theatrical Multiverse Transmitter/Node or DMXcat.

    RDMnet is very much on the cards...

Reply Children
No Data