Very basic question about mini tree setup...

[Stormyblade]

First year I have been able to actually set these up in a show, but the actual playback outside isn't matching the xLights sequencer look. If I have the Boscoyo mini-trees with 70 nodes, and I have run them in a "up one column, down the next"( a vetical zig-zag) all the way around, how do I define the tree in xLights Setup tab for model definition? 1 string of 70 nodes? 7 strings of 10? 10 strings of 7? They are physically on 1 string tied to 1 output from rhe controller if that helps.

FYI, they look perfect in the sequencer preview and perform all the effects as advertised.. However, a spiral, for instance, when actually played in a sequence is all jumbled on the actual mini tree.

[keithsw1111]

http://videos.xlights.org/xlights-primer-on-defining-tree-models_8caf23d94.html


Sent from my iPhone using Tapatalk

[Stormyblade]

D'oh! How did I not think of checking the video area first?    I guess I figured it was just too basic, lol...

Thanks Keith!! 

[Stormyblade]

Okay, it's been a week since I went back and checked out that video but things are still not right. The mega tree isn't performing correctly either, but that's a slightly different animal. For example, let's say I'm doing the Fire effect on both the mini trees and the mega tree - the mini tree does *not* show the ring of fire moving upwards and the mega tree acts as if there are 2 bottoms: one at the bottom of the tree and one at the top. Another example is that if I'm doing the Meteor effect, or even something like Snow Flakes, the actual trails and pixels go in both an upwards and downwards motion.

I've included a screen grab of the setup within xLights for both type of trees - on the E682 controller the outputs are listed as 70 pixels for the mini trees and 100 pixels for the mega tree strings. However, the mega tree strings start at the bottom, go up to the topper, then run back down, so I have 12 100-pixel strings that are actually 24 50-pixel strings connected together. Oh, and there are 12 outputs from the E682 controller. I originally had mistakenly put in a "Zig" on the E682 outputs, but I removed that so the E682 should treat each output like a 100-pixel string.

Any thoughts why the effects look perfect in the Sequencer preview/playback but don't look right on the actual model? (I've uploaded the models and configurations to my Rasp Pi playing FPP so I don't think that's the problem.)

[Centauri61032]

If it looks good in xLights, then you probably have an issues with the setup in your controller.
Not having your controller, I can't help specifically. I have the Falcon controllers.
Say in the falcon controllers...  You have one string of 100 PHYSICALLY connected to one port. But that is actually 2 strings of 50 on the tree. One up, and one down.
In the Falcon, that is exactly how you you would configure it.
I'm attaching a screen shot of my controller for reference. Ports 1-4 are my config. Each port has 100 nodes connected, but it is configured as 2 separate 50 node strings on the same port. With the first 50 being 'forward', and the second being 'reverse'.
Maybe this helps?

[Stormyblade]

I appreciate that screenshot and I also appreciate the thoughts.

I had my controller set to do a "Zig" at 50 pixels on each string previously and that didn't change anything. After setting it that way, saving the layout, uploading the models, and even going back and re-rendering (and re-saving) all models the sequence still looked the same on the actual lights. Then I thought I recalled reading somewhere that you can't do a setup like that on both your controller and in xLights because you'll confuse your setup...perhaps I'm wrong on that but that memory does seem to stick in my mind for some reason.

[keithsw1111]

Yeah you zig zag in xlights or in the controller. Not both.


Sent from my iPhone using Tapatalk

[Stormyblade]

Yeah you zig zag in xlights or in the controller. Not both.


Sent from my iPhone using Tapatalk

That's what I thought I read, but I wanted to be sure. Now I'm scratching my head as to why I am experiencing the issue I listed above. Short of deleting every mini-tree and mega tree model and associated effects, then re-inserting them, I'm at a loss to explain why the two types of trees are acting the way they are. I wish I had some video to post showing what they look like, but I don't have that available.

If I set up the mega tree model as 12 strings, 100 pixels, 2 strands per string (with the intention of having a 24-string, 50 pixels per string 360 degree tree), where does xLights split that string of 100 into 2 strings of 50? You'd think this is supposed to be the case, right? I ask this because the output I was explaining a couple posts up has the Meteor effect going in an upwards and downwards direction from THE MIDDLE of the mega tree, not at the ends of the string. The same thing happens with Snowflake - single snowflakes are starting at the middle of the tree and some are "falling" up while others are falling down. The Morph effect does the same thing - if I say I'm going to do a Full Sweep Up on the tree, it starts at the middle and morphs both upwards and downwards at the same time.

[keithsw1111]

Your fastest way to find an answer is to jump into zoom and ask. There are guys in there right now who will help you get it going. Much faster than text and image exchanges.


Sent from my iPhone using Tapatalk

[Centauri61032]

Maybe this will help you out....

I always try to visualize these things in two different ways. The physical (how they are actually wired and built), and the logical (how things 'appear' to be). AND most importantly, I always try to break things down to the channel level.

Using my previous example again...  My trees 'appear' to be 16 strings of 50 pixel each. So in xLights, this is how I configured them. I simply tell xLights that the tree has 16 strings, 50 pixels each, starting at the lower left, and the first channel is 512. Then xLights will create the sequences as if the first string start at 512 at the bottom, and goes to 662 at the top. Then string #2 starts 663 AT THE BOTTOM, and goes to 812 at the top. And so on....   (It helps A LOT to draw this out on paper, and include where these channels start and end.)

BUT since my PHYSICAL layout is actually different, this is where the controller comes into play. I don't actually have 16 strings of 50. I have 8 strings of 100, in a zig-zag. String #1 (part 1) is fine, with 512-662 from bottom to top. But string #1 (part 2) is physically incorrect, since channel 663 is actually at the top of the tree instead of the bottom. So I tell the controller to reverse the signals for channels 663-812.  That makes the physical channel layout appear to match the logical layout that is defined in xLights.

I hope this isn't more confusing? Basically, I found it was best to configure it the simplest way possible in xLights, and then draw it out on paper, INCLUDING the channels, to visualize what xLights thinks it is supposed to be doing. Then I made another drawing of the way things are physically connected. This will make clear what strings don't match exactly, which also tells you what config changes you need to make on the controller to make things match up.

Does this help any?

[keithsw1111]

Maybe this will help you out....

I always try to visualize these things in two different ways. The physical (how they are actually wired and built), and the logical (how things 'appear' to be). AND most importantly, I always try to break things down to the channel level.

Using my previous example again...  My trees 'appear' to be 16 strings of 50 pixel each. So in xLights, this is how I configured them. I simply tell xLights that the tree has 16 strings, 50 pixels each, starting at the lower left, and the first channel is 512. Then xLights will create the sequences as if the first string start at 512 at the bottom, and goes to 662 at the top. Then string #2 starts 663 AT THE BOTTOM, and goes to 812 at the top. And so on....   (It helps A LOT to draw this out on paper, and include where these channels start and end.)

BUT since my PHYSICAL layout is actually different, this is where the controller comes into play. I don't actually have 16 strings of 50. I have 8 strings of 100, in a zig-zag. String #1 (part 1) is fine, with 512-662 from bottom to top. But string #1 (part 2) is physically incorrect, since channel 663 is actually at the top of the tree instead of the bottom. So I tell the controller to reverse the signals for channels 663-812.  That makes the physical channel layout appear to match the logical layout that is defined in xLights.

I hope this isn't more confusing? Basically, I found it was best to configure it the simplest way possible in xLights, and then draw it out on paper, INCLUDING the channels, to visualize what xLights thinks it is supposed to be doing. Then I made another drawing of the way things are physically connected. This will make clear what strings don't match exactly, which also tells you what config changes you need to make on the controller to make things match up.

Does this help any?

I generally disagree with this approach. Mainly because it distributes concerns between xlights and the controller and introduces two ways you have to think about tryout prop instead of just one ... how it is actually built.

Doing it in one place and have the configuration pushed to the controller is much easier to understand.

Under that approach you configure it in xlights the way it is wired and thus you don’t end up with levels of abstraction.

The down side of this is xlights does not have the same flexibility the controller has so every now and then you are forced to tweak it at the controller ... and that sucks ... but we continue to work to reduce the times when this needs to happen.


Sent from my iPhone using Tapatalk

[Stormyblade]

I truly appreciate all the responses. I will look at my setups again and try for a Zoom meeting soon after Turkey Day. 

[Stormyblade]

Turns out I don't need a Zoom meeting - it's fixed.

So...after I upgraded to v2.3 on my Pi, I was using the FPP Connect function under Tools in xLights to upload all the sequences and songs, along with the controller config and the models. I noticed that xLights had changed slightly during this function in that it was compressing, transferring, and decompressing all the .fseq files. At least, that's what it *said* it was doing, but it apparently wasn't.

Long story short, my daughter finished sequencing 2 more songs in the past couple of days, so this afternoon I wiped the Pi clean of all the .fseq files and uploaded them back to the Pi through FPP, selecting one at a time and waiting until they were fully loaded before loading the next one. Deleted the playlist, created it again so that FPP would point to the newest/most recent files, and hit Play -- all the trees work exactly as advertised, with the effects running the in the right direction (as described in the xLights effects Sequencer).

It would appear that xLights, although it says it was uploading the most recent .fseq files and controller configs and models, wasn't doing so. I don't want to say that it's a bug because it's more than likely a failure to understand how a possible recent change to the way xLights does the FPP Connect and upload works as I don't recall seeing the text "Compressing xxx.fseq" "Transferring xxx.fseq" and "De-Compressing xxx.fseq". I will say that the transfer went much faster than in past xLights versions from even a month ago, but if it isn't actually updating the Pi with the more recent files so FPP can play those, then I will stick with the method of going to FPP and uploading them that way.

Anyhooo...daughter and I are up to 13 songs with 45 minutes of display time. Not too bad for our first year of a full display. 

[allknowing2012]

That was an issue in FPP 1.x and Xlights prior to something like .45. Is that your config?

[Stormyblade]

That was an issue in FPP 1.x and Xlights prior to something like .45. Is that your config?

I've been running FPP 2.x since before Halloween and only recently updated xLights to .46 -- I felt I didn't need the bug fixes so was ignoring the updates to xLights. However, it's not as if I was running .30 or something...I know I was in the .4x version range.

That still doesn't explain why FPP Connect under Tools is *not* actually uploading the selected files (fseq and mp3) to my Pi that is connected. Why is xLights reporting that the .fseq is being compressed, transferred, and de-compressed when that's obviously not happening? In the past versions of xLights, when I used FPP Connect it would report that the .fseq file was being transferred and then the .mp3 would follow - it didn't say compressing then de-compressing as it does now... I figured that was a recent fix for some things and that would make the files load faster or something.

Oh, and I'm not complaining at all -- this season has been very rewarding because I've already had lots of neighbors tell me how incredible everything looks so I am extremely grateful to everything that the developers do here and how helpful the community is.