Messages

1

Enhancement Requests / Add cycles option to shockwave effect

« on: November 07, 2018, 11:00:42 AM »

Pretty self explanatory from the title. I'm currently working on a sequence where having the ability to add cycles, like on many of the other effects would be a welcome addition to the shockwave effect.

2

The Water Cooler / Re: xLights dark mode Mojave

« on: October 19, 2018, 09:18:24 AM »

For those that have been running xlights on mojave over the last several months, how has the performance been since Dan's updates? Are there any issues still lingering? I'm wanting to try out the dark side, but so close to Christmas I'll hold off if there are any problems.

3

Enhancement Requests / Enhancement to display elements window

« on: August 22, 2018, 10:39:57 AM »

It would be great if it were possible to change the order of views within the display elements window. I currently work with more than a dozen different views and I would like the ability to sort them. As it currently stands if I add a new view it just staples it to the bottom of the list.

4

Enhancement Requests / Re: Alignment

« on: July 12, 2018, 09:07:56 AM »

Here's a quick video to show I'm not imagining things. 

https://youtu.be/SZUqmr0_JG4

5

Enhancement Requests / Re: Alignment

« on: July 12, 2018, 08:46:15 AM »

That makes complete sense since visibility shouldn't matter, but that is not what I'm experiencing. It's been that way ever since I started using xlights in 2016. I can package a test sequence if you'd like.

6

Enhancement Requests / Alignment

« on: July 12, 2018, 07:49:14 AM »

When I use the alignment tools they only work if the effects I'm trying to align are within the viewable screen or just outside the viewable screen. It would be helpful if the alignment tools worked regardless of where the effect is laid out on my screen real estate.

7

Bugs in xLights/Nutcracker / Re: 2018.13 (Mac) change of subfolders

« on: May 14, 2018, 01:15:59 PM »

I'm using 13b now and noticed that whenever I create a new sequence the xml file saves to the selected fseq directory and not the main directory that it shows when I'm naming the file. If I'm working with an existing sequence then it works as expected. I have not yet had the chance to see if this problem occurs on my PC as well. 

8

Bugs in xLights/Nutcracker / Re: Incorrect rendering with image models

« on: May 13, 2018, 09:01:13 AM »

They are set for single color. I replaced roughly 1/3 of my existing single color AC models to image models and discovered the issue anytime I had an effect on the group that wasn't a simple on / off.

9

Bugs in xLights/Nutcracker / Re: Incorrect rendering with image models

« on: May 13, 2018, 06:16:01 AM »

I'll create an example and send it. What's interesting is that if I take a sequence from last year pre image model and open it now after I've switched those models to image models, the initial play done with rendering from the fseq file plays perfectly on the image model. However if I rerender or click on the effect then it does the incorrect rendering. That all makes sense based on how the software works and certainly made it easy for me to spot the issue.

10

Bugs in xLights/Nutcracker / Incorrect rendering with image models

« on: May 12, 2018, 06:22:47 PM »

I have 9 yard decorations AC lights that are in my display that I changed over to image models this year for a more accurate visual representation. I was working on some existing sequences as well as a new one and any effect that is applied to the group, excluding on / off, renders incorrectly on the image models. Basically all models in the group turn on at the same time when they should not. For example I use twinkle to randomly turn on and off models in the group or pinwheel to progressively turn models on and off. On my non image model AC lights they work as expected, but the image models do a simultaneous quick flash instead.

11

Bugs in xLights/Nutcracker / Re: Upload to controller w/ mega tree

« on: April 29, 2018, 02:20:49 PM »

Keith pretty much summed up how my setup works. The pi's are wirelessly on the same network and each has a wired connection to one controller. Sync packets travel over the common wifi network via master / remote and plays the show. I would think this is typical of anyone using master and remotes.

Last year I originally had my configuration for the full channel count as Jim suggested, but it slowed the show network to a standstill. When I attempted to play a 4 minute sequence it literally took over an hour to play out. It was moving just a few frames at a time and would completely lock up frequently. 

I certainly don't mind manually configuring my pi's, but if there was a way to incorporate it into xlights I think it would benefit those who use master and remotes with high channel counts. 

12

Bugs in xLights/Nutcracker / Re: Upload to controller w/ mega tree

« on: April 29, 2018, 10:08:09 AM »

Thanks for clarifying.

I would think the possibility is there for xlights to know which universes to send if FPP connect worked similar to the upload to controller feature. Hypothetically the user could from the setup tab select the block of universes that are associated with each pi and then have FPP connect only send the data for the highlighted universes. If no universes are highlighted then the entire universe data would be sent.

13

Bugs in xLights/Nutcracker / Re: Upload to controller w/ mega tree

« on: April 28, 2018, 04:51:53 PM »

I'm just trying to figure out what FPP connect can or cannot do and how that relates to my display. I presume my setup is typical to that of most people who utilize the master / remote(s) feature with pi's where each remote is paired with one controller. If this goes beyond the scope of what this feature was meant for, then I apologize for this back and forth. I just haven't come across anything from the xlights videos, both from the Vegas seminar or posted to the site, that mention this was not possible.

If you are uploading to multiple pi’s aren’t you using them as remotes and pulling data from the fseq file on. Each. In that case you don’t need to upload the config.

The pi's are used as remotes and only have the fseq file on them. How would the remote pi's know what to listen to if the universe range and FPP start channels aren't defined in each remote's e131 channel outputs tab? If I get rid of that data the remotes just stop working.

14

Bugs in xLights/Nutcracker / Re: Upload to controller w/ mega tree

« on: April 28, 2018, 07:53:51 AM »

Not true. You should have just turned off e131. One checkbox on each pi. In fact I don’t think you even needed to upload it at all.

I'm using the Pi as a show player so I need e131 enabled to be outputting to lights. The upload would be necessary to define the universes and ip addresses for the various controllers. Am I missing something here? I thought this was the basic setup for using FPP as a show player and I've been using this setup for years trouble free. The only issue came this past year with the new FPP connect feature which was sending and enabling e131 outputs for all Pi's.

15

Bugs in xLights/Nutcracker / Re: Upload to controller w/ mega tree

« on: April 27, 2018, 09:44:04 PM »

There is one other thing I encountered last year and it still appears to be present. I have 6 FPP's in my display that I use the FPP connect to upload the configuration. When I use FPP connect and send the configuration to the individual Pi's, the E131 channel outputs on the FPPs show every universe across all 6 Pi's and they are all checked as active. Only the universes locally associated with that specific Pi need to be active and having them all active grinds the network to a halt, even with unicast. So last year after FPP connect uploaded my 130 total universes to all my FPPs as active, it was necessary to go back into each Pi and uncheck all the universes that were not local to that Pi.