Author Topic: Media name in FSEQ  (Read 3386 times)

Online smeighan

  • Developer
  • ******
  • Join Date: Mar 2013
  • Location: Highlands Ranch, Colorado
  • Posts: 1,033
  • Kudos: 11
    • Nutcracker123
Re: Media name in FSEQ
« Reply #15 on: September 23, 2014, 02:39:36 PM »
There are two metadata elements missing from fseq data. They are what are contained in xlights_rgbeffects.xml (the model layouts) and xlights_networks.xml (the hardware controller layouts). The controller info is needed for every fseq. Currently people have to renter that (and sometimes get it wrong). The model info would be nice to have if you are creating the pixel overlay sequences.
Sean
Littleton, CO
Latest releases http://nutcracker123.com/nutcracker/releases
xLights/Nutcracker Forum http://nutcracker123.com/forum/index.php
Facebook [url=https://www.facebook.com/groups

Online David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,737
  • Kudos: 63
Re: Media name in FSEQ
« Reply #16 on: September 23, 2014, 02:52:02 PM »
The hardware data in Xlights is not held in sequence files. It is held in a hardware file. Maybe a universal hardware file needs to be created or use an existing one in addition to sequence file. I do not think the fseq or xseq or xlights sequence xml is the place for network or hardware information.

The metadata is not missing in fseq it is located in other files just like it is in xlights. Maybe a better way to import this data with a unified file is needed. But not part of the sequence file.
PixelController, LLC
PixelController.com

Offline CaptainMurdoch

  • Administrator
  • *****
  • Join Date: Sep 2013
  • Location: Washington
  • Posts: 8,349
  • Kudos: 157
Re: Media name in FSEQ
« Reply #17 on: September 23, 2014, 03:03:00 PM »
With in the first few days of the Vixen3.1 release, I answered 3 different support requests on the forums and in e-mail which where due to controller setup mismatches between FPP and Vixen3. If V3 embedded this information and FPP could consume it, then it would eliminate some of these issues.

This is another case where having a "sequencer channel output config import" UI in FPP would be good (as long as we don't use that name).    We've already talked about importing the network config xml from xLights, but now that we have the ability to get .fseq files straight from Vixen3, maybe adding the ability to ingest the Vixen3 output config would be beneficial as well.
-
Chris

Offline ebrady

  • Jr. Member
  • **
  • Join Date: Dec 2013
  • Location:
  • Posts: 51
  • Kudos: 0
Re: Media name in FSEQ
« Reply #18 on: September 23, 2014, 03:22:52 PM »
This is another case where having a "sequencer channel output config import" UI in FPP would be good (as long as we don't use that name).

AMEN to not using that name! :P

We've already talked about importing the network config xml from xLights, but now that we have the ability to get .fseq files straight from Vixen3, maybe adding the ability to ingest the Vixen3 output config would be beneficial as well.

I like the idea, if you went forward with this I think it would make life simpler for the FPP dev team to just pick a single format that sequencers must adhere to for compatibility.


Ed

Offline jchuchla

  • Full Member
  • ***
  • Join Date: Jul 2014
  • Location:
  • Posts: 246
  • Kudos: 0
Re: Media name in FSEQ
« Reply #19 on: September 24, 2014, 06:25:54 PM »
In the process of supporting many users who like to use multiple tools in their sequencing workflow the need for some standards so that transfer of work product is as seamless as possible between applications.
It would seem that so long as the actual sequence data is a flat field of values, that it only makes sense for that field to require a declaration to be truly useful. It could be in the file itself, or the sequence contains reference to some sort of header file containing the mapping.
I could see a future of blinky utopia where all of the tools that can ingest sequence data and its support information and automatically transform that data to work best with the current configuration. So if vixen or nutcracker were to provide the file and it contained a reference to which channels are associated with what controllers, then the fpp could either just accept it and switch configurations on the fly. Or it could convert/transform the sequence data so that it could be compatible with the current configuration. (At import, not at run time)

I'm also a fan of extensible formats. It would be nice if the config file were human readable, and had standardized  data structures for common data, but also allows similarly constructed custom structures that may have meaning to the originating app or another app. This would be a place for nutcracker models and such to live.
It could also contain things like the setup info for a hardware controller. Wouldn't it be cool if you could sequence in vixen 3 and define the config there. Then fpp sets itself up, and in turn configures your 683 for you.


--Jon Chuchla--

Sent from my iPhone using Tapatalk

Online David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,737
  • Kudos: 63
Re: Media name in FSEQ
« Reply #20 on: September 24, 2014, 07:00:47 PM »
I am in full agreement and this is something Sean and I have talked about many times before. I am in process of developing a new controller that I think has great potential and willing to collaborate with Vixen, Nutcracker, FPP, Charles, Jim Saint John and others to hammer this out. I find that in order to get the ball rolling someone needs to propose in writing a protocol and then we can all fine tune it.

I like the idea of having the controller information be XML but the data be binary. An offset could be given in the XML portion that indicates where the binary data is at.  It seems the originating software would need to have all the data for each controller (ip addresses included). The one problem I see with this solution is if I change the setting information on my controller to have other features and such how would originating programs know that there are more options. It seems there may have to be some kind of controller setting protocol file that sequencers such as Vixen3 could read to know what settings can be set and there values and ranges. Or the ability for vendors that make controllers to create a Vixen plugin to configure their specific controller. The data sent to controller could be just a buffer that is defined by controller vendor and interpreted at the controller level.

This auto-configuration ability would be in addition to the webpage or software programming that already exists from the vendor.

 

Back to top