Author Topic: A follow up on the distributed architecture discussion at diychristmas.org  (Read 1569 times)

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
I thought I would post the reply over here as well, in case there was a thought to collaborate.

Yes.  What i realized a year or so ago (I am slow), that even with E1.31, there would be a pixel count issue.  Bottom line, transporting the data all over the network wasn't going to scale well.  So instead, I went after distribution points, that have the binary sequence data, and from there can output to just the local points it was in charge of.  This distributor could easy output in any format needed (directly to lights, DMX, PIXELNET, E1.31, etc).  But it was still a manage size.  The amount of data to "control" the distribution point, is small and finite.  It has to preform only five functions: 1.open outputs (if applicable)
2. load a sequence file
3. Output a frame index
4. Close a sequence file
5 Close outputs (if applicable)
The largest packet is only 40 bytes. Regardless of how many channels one expands to.

Now the media player, is what plays the media, and sends out the packets to the distributor.  It can again be whatever device one likes.  It has a few more packets that it has to handle from the "controller", but they happen very infrequently.  Again, the largest packet is 40 bytes.

What I like, it allows one to choose the correct hardware for any function they want, and collapse the functions together if they desire.  I would be more then happy to publish my packet definitions if one has an interest in making comparable devices.

The packets are all sent udp, directly.
One is never too old to learn

Offline arw01

  • Hero Member
  • *****
  • Join Date: Oct 2013
  • Location:
  • Posts: 836
  • Kudos: 0
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #1 on: December 29, 2013, 11:14:05 AM »
Maybe some more background, diychristmas.org is not one I am subscribed too and I already spend too many hours reading forums and not enough time doing   ;D

Offline Steve Gase

  • Supporting Member
  • ******
  • Join Date: Mar 2013
  • Location: Georgetown, TX (near Austin)
  • Posts: 1,037
  • Kudos: 5
    • WinterLightShow in Georgetown, TX
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #2 on: December 29, 2013, 03:26:32 PM »
Charles, this sounds like the Conductor/Slave facility implemented in RJ's DLA kits.

David has said that he planned to implement something similar to allow multiple Falcon Pi Players to synchronize -- each FPP carrying the sequence data for their part of the show.

Are you suggesting something different?
http://WinterLightShow.com  |  110K channels, 50K lights  |  Nutcracker, Falcon, DLA, HolidayCoro

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #3 on: December 29, 2013, 05:27:00 PM »
Yes, it is different. It is a distributes system.  I have attached a file of the architecture. 

I have the concept of a "media player".  This is the process that plays the media, and sends out frame indexes to "listeners".  It has no concept of the the actual data, and does not very based on channel count.  This process only needs access to the media files.  It sends no sequence data, nor needs access to any sequences.

The media player is controlled by a "controller".  This is a process that controls the media player.  This has no access to any files. It can control things like volume, play rate, muted, loading a media file, unload a media file, directly indicate a frame index to go to,  play, stop.  This can be on the same device as the media player, or not.  Given its small foot print, it is ideally suited to be a mobile device, allowing one control of the media player from a phone/tablet while outside.  The "show player" can be larger process, monitors the calendar, and then controls the media player and says when to load files, etc.  the device this process resides on, can be the same device as the media player, or another computer (or across the internet). The rate of packet communication is very low and small between the controller and the media player.

Finally, one has listeners.  These devices have sequence data (binary format preferred).  They load the proper sequence, and then output the frame data based on the listeners configuration when a frame output commend with the frame index is received from media player.  This allows a variety of devices to be connected, and not have to have the complete channel data (just the channel data that it is responsible for outputting).  Although this frame packet is received at the sample rate, it is a very small packet (less then 40 bytes), and is fixed regardless of channel count.

the listener is relatively simple c++ code (at least a template, the only thing that changes is the output class).  It can easily be adapted to various platforms (beagle bone, raspberry pi, mac, etc).

This is what I am transitioning our software over to.  As y'all know, i work on native mac stuff, so my media player, and controller/scheduler  probably isn't much interest to many.  however, the listener template is pure C++, so fairly transportable.  And of course, I am willing to publish the packet information, so once can write their own replacements for any process (to run on the platform they choose).

I have successfully tested this across the internet (media player in VA, listener in TX) and it worked well (prototype). 

anyway, just thought I would share.  Not taking away from the falcon team. They have done a fantastic job.  Based on the feedback I have seen, it has been nothing short of fantastic.



[attachment deleted by admin]

Online David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,737
  • Kudos: 63
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #4 on: December 29, 2013, 06:04:42 PM »
It is very similar to the Conductor/Slave and our future master/client modes. The terminology is different but the system is very similar. Using the same terminology the Conduct/fpp masters are like a Media Player combined with a listener. The slaves are just listeners. The sync (frame information) sent from Conductor/Maters is about only 40 bytes also. The slaves only have sequence data and no media.
PixelController, LLC
PixelController.com

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #5 on: December 29, 2013, 07:03:39 PM »
I agree it is similar in concept.  I guess I wasn't focusing on the channel data.  What I was focusing on, was not a two level system (player, pixel controller) but a larger distributed system.

For instance, the conducer for the most part, works with an etherdongle, and puts out E1.31 data. It can sync with other conductors slaves.  That is at least my understanding.  The only thing that puts out channel data of any kind the listeners.  However, I agree, that the terminology of what makes up a listener/conductor is subject to discussion.  What I haven't seen done, si the concept of breaking out the other pieces, in a network centric standard way of doing it (so they can interface with each other).

For instance, If you don't like the "controller", you can replace it, and it operates with the other components.  Each piece has a very simple, focussed function.  I didn't see the Conductor/etherdongle do that well.  It also is dependent on having "E1.31 or pixel net) for the entire item to work.  This, one can replace the listener (which is very single focused) and the rest still works.  One never buys into the entire infrastructure.

I guess to me it is different, but perhaps because of the areas of my focus.  I want a swappable standard of small, defined functions, without standard interfaces (packets). 

Probably just how I look at it, and my explanation is lacking.

Offline charleskerr

  • Jr. Member
  • **
  • Join Date: Jun 2013
  • Location: Oak Hill, VA
  • Posts: 87
  • Kudos: 0
Perhaps I don't understand, I normally don't
« Reply #6 on: December 29, 2013, 07:36:42 PM »
Ok, perhaps I haven't understood the FALCON Pi well enough to say they are similar.

Let me see by asking a few questions.

Say I want to have a single computer, that I want to use to have all the schedules for shows on (and change). Lets say I do this for my family, across the country. I like the mac integration with Calendar,so say that is what I want to use.  I am ready to write my own code, to do this.  Can I use the rest of the software system provided as is, to interface to without modifications? My understanding, is FALCON, and DLA are both scheduled directly on the boards resident at the location.  Remember, I still want to play the music/video and lights at the local locations.

Or say, I want to add a "listener" at a location across town/block.  Id not want to change any of the rest of the code, and want to build a small device that will interface with the minimal additional cost (I only want to invest in this device of my design, not duplicate other hardware). 

I want to do these with out changing any of the software of the rest of the system that I am not replacing.

If the answer is yes, then I would concur, they systems are very similar.  However, it was my understanding, they don't do this.

I think where the similarity is, the concept of sequence files at the listeners.  I agree, that is similar (and a logical evolution given the data explosion).  But I don't think the others address the distributed needs or swap outs (which, being on a MAC and liking to change user facing stuff without messing wight the rest of the system is important to me) of software components without disruption.

If they do address this, then I have to concur, they are similar and addressing the same issue.  I haven't seen any packet documentation for the distribution so one can interface at the different points, but I haven't looked hard either (I readily admit that!)

Anyway, I am not trying to indicate one is better then the other.  I was addressing a discussion so if one did go this distribution breakout, and wanted to standardize on packets for interoperability, I would be more then happy to enter into that discussion.


Online David Pitts

  • Administrator
  • *****
  • Join Date: Mar 2013
  • Location: Falcon, CO
  • Posts: 3,737
  • Kudos: 63
Re: A follow up on the distributed architecture discussion at diychristmas.org
« Reply #7 on: December 29, 2013, 08:11:02 PM »
With your explanation I would have to agree they are only similar at the listener level. 

 

Back to top