Sean Meighan
Software => LOR => Topic started by: jamills6377 on September 21, 2018, 09:13:58 AM
-
I am finally getting hardware hooked up to test xLights talking to LOR controllers. I have one controller (Pixie16) hooded up on Comm3. It does not yet have all of its pixels connected but has 12 strings of 100 folded in hal to give 24 columns o 50 pixels in a matrix mesh. I wrote a simple sequence of 30-seconds of butterfly effect to see if it would play. I hit the light bulb and it seems to accept that all is well as it turns yellow. Then I hit the play button and the program instantly crashes....the debug window opens briefly with nothing displayed in it and then it all simply vanishes. I have done this repeatedly and it always does the same thing - I even tried it with a full blown sequence to see if it was just something in my test one - but it doesn't matter what I try to play it always crashes instantly. As I am running this connected to hardware for the first time - I am now on my Windows machine and do not have any idea how to do a screen capture video on that machine (since I usually use my Mac). If you want to see a video o me hitting play and having it crash, I'll need someone to tell me the best way to do a screen capture video on the Windows machine. I can take screen shots and send them o any configuration screens you might want to see if you tell me what to send (please remember I am very new to xLights so I may not know what you need unless you tell me the screen you want to see). Thanks in advance for anything you can do!
-
I have the identical problem you just described, I was on here looking to figure out what I had done wrong.
I connected mine to LOR's S5 software to test, and it works fine. I am wondering if its a problem with xlights software, or are we not setting it up correctly in xlights. My prop is also a 24x50 Matrix, with 12ea 100 pixel string
folded over. Hope there is a resolution to this issue real soon.
-
http://nutcracker123.com/forum/index.php?topic=2819.0 (http://nutcracker123.com/forum/index.php?topic=2819.0)
-
No crash report can be delivered because as soon as the debug window appears it never fills in with any information and promptly disappears.
It happens on every single sequence I have tried (approximately 6 different ones - of varying lengths and with varying numbers of effects).
Here is what I do.....
STEP 1: open ANY sequence.
STEP 2: click on the Green PLAY Arrow.
STEP 3: watch the debug window appear for a second and then the whole program
(including the debug window) disappears.
-
Here is the .xml of one of the many sequences that crashed.
I am running 2018.33 now - but earlier I had 2018.32 running - it did it in both o them.
I did not do a screen capture because I would think you could imagine my mouse pointer moving to the green play arrow and clicking then a blank debug window appearing and the whole thing disappearing. If you'd like to see that, I'll be glad to capture it for you.
Please remember, too, ALL of my controllers are LOR controllers - at the moment I am only testing with 2-Pixie16 controllers connected which drive my 50hX64w matrix. All of the pixels connected to these 2 Pixie16s are WS2811 type flat pixels (also purchased from LOR).
-
And I did not do anything to troubleshoot the issue because you can probably imagine me sitting here with not a single file to view...
The crash information most likely is still in the log file so when you crash just reopen xLights and do a Tools->Package Log Files.
-
Instead of using a more complicated sequence like I attached yesterday, I created a new one - animation only - a single color wash effect on only my matrix prop - it, as I suspected it would, crashed as soon as I hit play and did not produce a debug screen. So, per your instructions, I reopened xLights and packaged the logs. They are attached here.
I also ran a Sequence check and attach it's results here so you can see that there appear to be no problems with the sequence itself.
I also packaged that test sequence and attach it in case that might include anything which could be of use to you.
-
Further information...
I submitted a bug report to LOR as I also tried to run the xLights Convert process on my sequence and open it in their S5 software to see if I could just run my show from their software since it was their hardware. The file created from the xLights conversion appeared to be an S4 version sequence to S5 - and so it tried to upgrade that sequence to run in S5 - that hung up the program. I sent that same "BabyShark" converted sequence (the xlights created .lms file) and received the following response from them this morning:
"Your sequence has no physical channel information - no device type, unit id or universe, etc. S5 needs this information to upgrade your sequence properly. It matches the physical channels in the S4 sequence with the channels defined in your preview. "
-
I haven't done the LOR Convert in over 2 years so I don't really know the process everyone follows. A lot of people are doing it though so they could chime in any time but you know most people don't want to read other people's issues they ignore everything here until they need help with their own problems. I just did a convert and the LMS file opens up in LOR S4 so it seems like all you need to do is an Edit -> Export/Import Channel Configuration in LOR to import your controller setup from one of your other sequences. That's the method I always used to make sure I had a common setup when I created another sequence.
-
Thanks for that. So,that's why I have no Channel information in it in LOR - because that doesn't come out with it in the convert?
Which really means I need to recreate my whole layout in LOR. I moved to a new house and only used xLights to set up everything here - thinking xLights would just play to the LOR controllers or I could export the sequences and they would just play - not realizing I'd have to do that configuration of channels in both places - thought xLights would have that data and include it. I guess that shows my lack of knowledge on how the back ends of this stuff really works!
Still - I would rather just use xLights and have it run my LOR controllers.
-
Well you are trying to run an ambitious amount of channels using LOR dongles with xLights. We used to only support 96 channels with LOR dongles. My LOR optimised output was an attempt to improve that but I have no idea how many channels it can do.
But from the log it appears to me you don't have all the dongles attached to the COM ports. Do you really have 7 LOR dongles connected to your computer? Each one of those LOR Optimised outputs needs a LOR dongle and its own COM port and it needs to be connected when you try to run the lights. It shouldn't crash but I doubt I'd be able to reproduce and fix that this year.
-
I do have 7 dongles/LOR networks. BUT at the moment I am only running the Matrix and consequently only have those two dongles connected Com 3 & 4 for LOR Networks AuxE and AuxF - which is LOR Unit IDs 50-5F & 60-6F.
I have a total of about 6400 Pixels and a few A//C channels - I think my highest Channel number in xLights is 19241.
-
I guess when I first looked into xLights and asked about LOR support I should have mentioned how large my display was! LOL I just asked i it would drive LOR and was told in the forums and on Facebook that it would! But I ind now that most folks mean A/C when you talk about LOR controllers - not Pixels.
If money was no object I would just keep all of my Pixels and buy Falcon controllers...but I have already blown my whole light show budget for this year. I moved to a new house and had to do a lot of updating of props to make things work! Oh well - there is always next year!!!
-
Problem is you have all the outputs listed as "Active". I would set the ones not connected to inactive. If that doesn't work I'd try to isolate. Maybe copy your show folder and then try reducing it to just one output. That's how I troubleshoot I try to divide and conquer. Figure out what works and what doesn't and try to reduce the number of variables involved.
-
Hmmmm - OK - I thought that by saying "Not Connected" in the setup screen that would imply they weren't active. I guess I'll have to look further or that Active/Inactive stuff.
By "reducing it to one output" do you mean, just have one controller set up?
I did make a simple sequence that only addressed the Matrix itself with a Color Wash - which is what I think I sent to you this morning. But you mean something more simple than that?
-
The sequence may have only had the matrix but when you hit output to lights its going to try to send data to all active controllers. You just caused it to try to send 0's to everything that wasn't the matrix. That didn't really reduce anything.
-
Results of testing...
The only active output was #6; LOR Optimised; Com3; 512000 Baud; Unit/Id 6; 4800 Channels; Channels 9642 to 14441.
I attach the Sequence Check output report, the Packaged Sequence, and The Packaged Logs.
I was watching the pixels closely and did note that there was a VERY BRIEF flash of light just as the debug screen appeared and subsequently went away.
As with the past tests, the debug screen never filled in but rather appeared or a brief moment and then the whole thing, program and all, simply went away.
And, again, I appreciate your time in looking into this for me. As all my sequencing is in xLights for this year, I am sure hoping we can see some simple critical error on my part or on the part of my system that will allow my show to run. I've had no luck whatever in getting any of the sequencing exported to LOR either as a Model Clipboard export into S5 or as an avi file of just the matrix model.
Thanks again for all of your time and energy!
-
Yeah when I said copy your show folder and reduce to one output I meant I wanted you to have only 1 output defined in the show folder. Since you are telling me the channels started at 9642 I know you didn't do that. I was suggesting just start simple and try to use a blank show folder and just setup one controller with one model. I want to see if it can succeed with something simple because it's clear there is something about one of your outputs or models that is a problem.
I'm also having a lot of trouble trying to parse the log because for some reason we are streaming out thousands of lines for the submodels so it makes it hard to scroll down and figure out where the interesting stuff starts. I usually search for the word "crash" but you used that in a sequence name so all I'm finding are those false results.
You might be stuck using LOR. I believe that was the goal Light-O-Rama had when developing those Pixies was to try to force users to be stuck with their software. By the way you are shutting down all LOR processes before you run any of this in xLights right? You can't have those LOR services running that they like to hide in the background.
-
Ah! I missed understanding that single output part in a new show folder! I'll try that now.
If I'm stuck with LOR this year - I will have a pretty sad show since all of my sequencing is nearly done and in xLights - I'll have to start over now. I guess I've learned now that when everyone on the forums says, "No problem! I do it all the time!" I should have gotten into my boxes and hooked something up a couple of months ago so we could have been doing this in mid-summer.
Next year, instead of a budget for lights, I'll have to budget my money towards Falcon controllers. My goal to be seen by the Space Station will just have to wait! LOL
As I understand it, all of my WS2811 Pixels can still work (not sure about those early 5-volt LOR pixels) on Falcon controllers - so I'll just have to replace controllers.
-
OK - so here is my new test data....
An interesting "mistake" led to some odd findings though....initially i mistyped the number o channels as 16 (thinking how many outputs were in the controller) so rather than 4800 channels it had only 256. That did not crash but (as you'd expect) only lit up the first couple rows of pixels. I then corrected my mistake and put in 300 - for a total of 4800. Then it crashed in the same way as before.
Here is the log, sequence, and check sequence files.
All this is is an animation sequence of 30-seconds of butterfly on the matrix prop which is LOR Unit ID 50 (hew - 80 decimal). Only the one controller hooked up.
-
Ok that showed me the function it crashed in so good. I'm at work so I can't really dive into the code till tonight. I'm suspecting it's the number of channels per output of 300. I might have some hard-coded value somewhere that didn't expect the channel numbers to go that on one output. I you have time try reducing that number and find the spot where it breaks. Usually I do that by cutting in half you can quickly find it with less than 10 tries. Just to be safe I would make sure you close xLights and delete the FSEQ file after you change the number of channels just to make sure it doesn't try to snag the old size. Then reopen and try it. Otherwise I will look for a array limit tonight.
-
Several interesting (at least to me) observations...
It played at 250 but not at 260 or higher - I did not go 1 by 1 up from 250 but will if you want me to.
However - I switched from using butteryfly to using pinwheel because the butterfly didn't look quite right to me but is so busy with colors that I couldn't be sure. At 250, when it is playing, of course the last portion of each group of 100 pixels will not be lighting, but the output is random and scattered all over the place with colors that are not selected. I had set 3 blade in the pinwheel and only the colors red and white. I did not see anything remotely looking like a pinwheel - and saw green and blue and occasional yellow pixels lighting along with the red and white I expected to see - but, again, they were not forming a pinwhieel pattern at all. So I switched to the bars effect - again just red and white (and still set at 250 channels) - I did not get bars at all - just random lights all over the place - and included again where green blue and yellow with the red and white.
Also, you commented on deleting the fseq after each crash - there was no fseq in there after it crashed only after it successfully ran.
Let me know if there is anything else you'd like me to try...and i you want me to send any logs, or even a picture o the lit up matrix with the random pixels lit.
-
So it probably works up to 256 channels. Not sure what would be causing that limit. I wouldn't try to evaluate the way an effect looks since you are defining it different from the real hardware I expect it to come out different. If you have no FSEQ file then I guess you never rendered and saved the sequence before you played it.
-
should I have rendered after each test? I did not - only the first time.....didn't think about the fact the fseq was created then - i that's important I'll try it again.
I was just thinking about that 255 or 256 number as I was thinking more about this....that would be logical since thats a power of 2 and often a limit imposed on things in a program from a storage limit standpoint - I know I always limited thing to 255 when I was building new code years ago so it wouldn't spill over into the next byte in storage.
If its important to know, I'll be happy to run the test again with that setting.
-
Just a quick browse of the code and the only limit I can see with a quick scan is I only allocated 1024 bytes for the data packet. So can you try using an effect that would be more efficient like try 300 channels but just use an On effect. An On effect requires less data than a Butterfly so it may tell us if it's a channel number limit or a data packet size limit being overrun.
-
OK - set at 300 - only an ON effect - it lights up for a number of seconds and in only the one color selected but does have random small sections of pixels, especially in the higher numbered channels that do not light up. then it crashes and does not even appear to try to open the debug window.
-
Change the output to a Pixie4. I would expect that to still work on that card but only the first 4 outputs would light up. I'd like to know if that works at 300 because if I test at home I'd be running on a Pixie4 and it could be the amount of data we are trying to pump out the serial port so reducing to 4 outputs would be a good data point.
-
Pixie4 - On worked, Pinwheel worked, Butterfly worked --- no crashes.
Switched it to Pixie 8 - all worked as expected.
-
Ok that's good info. I'll have to look at things tonight. So that was at 300 channels per output right so its not a channels per output issue it seems like it a just the shear amount of data. I'll need to try to calculate how many bytes you can actually push out a COM port at 512,000 baud.
-
Yes - Pixie4 and 8 both were set to 300 and i made certain that my model included all 4 or 8 outputs.
-
Ok I found a constant in the base LOROutput class that has a max channel limit for LOR of 3840. Not sure why its there I think it got copied from code Matt Brown wrote. The note has math of 240 * 16 so it's like they considered there to be a 240 channel per output limit. We are currently only using that value to declare an array that is used to save the last output value for each channel so no reason I can't make that value larger. So any LOR output defined with more than 3840 channels currently will cause a write outside that array boundary which could be stomping on any nearby data. This might be as simple as me fixing this one constant.
-
Well that would be stupendous!!!!!!
I am, of course, happy to do any further testing you might need!
If you need to email me a test pic of code or version of the software to test with you can contact me at jeff (at)jeffreyamills(dot)com if you can't attach it here. Or give me a URL to download something from if needed.
Just let me know!!!!!
I surely do appreciate all of the hard work and time you are putting in to make this work!!!!!
-
Do you know if the Pixie's have a defined limit for number of pixels per output?
-
I do not know that - but I am 99% sure that they cannot support more than 100 pixels per output so that would be 300 channels. I have my manual that came with the Pixie16s right here and don't see anything on a quick look - I'll spend a few minutes going through it inn depth.
-
I could swear that LOR Tech support told me 100 was the limit - but in the documentation I find these maximums for a Pixie 16: Strings=16; Pixels per string=170; LOR Effects Pixels=50;Stings per Bank=8; Amps/Bank=32; Total Amps=64; Voltage DC= 5-12; Max LOR Net Speed= 1MBPS; Operating Temps=-30F to 140F.
It also says: " The Pixies appear in a LOR Network at the unit ID specified...plus1, 3, 7, or 15. … A Pixel string is configured in the Sequence Editor as u to 170 Pixels.
If you configure the Pixie for 50 physical pixels, each string will appear as 160 channels. The first 150 are the RGB channels for the 50 physical pixels. These channels can be combined into Sequence Editor RGB Channels cutting the 150 to 50. The next 10l channels ar eht resolution macro and color effects channels. These are for com-atibility mode with old CCR/CCB/CCP.
It then explains that compatibility.
I honestly believe some of that is holdever wording from before the newer 100 pixel strings were introduced because I LOR S5 I have them defined as 100 pixels and theey work exactly as I would expect - and I believe that tech support, when I asked before purchasing these, told me that the 12-volt pixels (WS2811s) were supported up to 100 pixels per string. In fact when they sell them they are sold in "bundles" of 50 or 100. So I'm not sure what the 170 or that 50 physical limit is all about...but it seems deprecated to me.
Again - at the very introduction to the manual is a paragraph which reads: " The LOR Cosmic Color Pixies are low cost, high density RGB pixel controllers. They ate available in 2, 4, 8, and 16 string versions. The maximum number of pixels on a string is 170. They support a variety of RGB pixels controller ICs.
I believe that the LOR RGB effects that are mentioned are actually older software controlled effects - I recall that from my first CCRs several years ago - whereby you set a certain nit on to make it twinkle, or some such. That is why I believe some of that verbiage is deprecated at this point. Still, it seems to me that the 170 limit should be kept in consideration even though they only sell strings of up to 100 pixels.
-
I'll just reserve enough for 512 per output.
-
Replied to your email.
But - two Pixie 16s running Butterfly played. Upon adjusting the butterfly effect while it was playing (forgot to hit stop) that made it crash.
-
You suggested that I try playing to the LOR controllers using xSchedule instead of from the sequencing GUI - I tired that this morning and it played for a little while - maybe 20-30 seconds or so then xSchedule crashed. Seems to be about the same amount o time that the GUI lasts before it bogs down and begins to stutter.....so perhaps some sort of "output buffe" - or chunk of memory - or something is filling up at that point.
Is there anything I can send you to look at about that?
-
Like I said in one of the emails the only thing that is really useful to us is the stack trace when it crash. So if you don't get a crash report then restart the program and view the log and if it has that "Crash handler called" phrase with what looks like code behind it that's the only thing that points us to where in the code it crashed. Now some crashes end up not showing the trace so if you don't see the code trace after that phrase then it's not going to help. xScheduler has a log similar to xLights.
-
So far I have not had an xSchedule produce a log with that Crash Handler showing in it. I'll keep testing it off and on.
-
Here is the latest Crash Report from xSchedule
-
Ok but the problem there is xSchedule does not have the hot fix I emailed you.
-
In an email you had said, "It would probably have better success if you just created an FSEQ file and played it back using xScheduler. When you are running the xLights GUI the timing is affected by all the GUI updates which normally isn't a problem but with 4800 channels per output for several outputs it might be an issue." So I was testing it with xSchedule rather that using the xLights and GUI interface.
I took your comments to mean that I should not continue trying to make it play from xLights (even with the "fix" in place) and rather to try to play it from xSchedule. I didn't realize that same "fix" would need to be applied to xSchedule, too - thought it was an xLights/GUI issue.
-
Yeah I know what I said so it was an oversight. The statement is true but we need the fix put in. I will email you an exe when I get time.
-
Cool - Thanks! Appreciate it.
-
Installed the new executable ... it played for about 10 or so seconds ... then crashed. Attached is the crash report/log.
-
Yeah that looks exactly the same so I can't tell whether it might not have picked up the changes when I built it.
-
I made certain that I had the version that you emailed to me. Will you be sending me a rebuild?
-
I don't need to Keith issued a new release that has everything I changed. If that doesn't work maybe try creating a 100ms sequence so it won't try to pump data out so fast. We may just not be optimized for trying to pump that much data out but I'm not even sure where you left off. How many channels are defined in the sequence you are trying to play? And I don't mean how many models have effects because what matters is how many channels are defined in setup. I'm also not sure if disabling an output reduced the size of the FSEQ file it may just keep xLights from pumping out the data when you playback in xLights so you can experiment to find out whether the FSEQ file size changes. Cause I can't remember if you actually created a brand new blank show directory when I asked you to just get on output working.
-
I did make the new show directory and only had the one 16-output controller defined in it. But just to be certain, with the .34 version now available. I will test again...and try to be more clear about what exactly is defined. Thanks
-
OK - I erased the old "new show" directory and created a new one. Added only one Pixie16 controller to it and placed that matrix onto my layout. I made a new animation and placed a color wash on the matrix - it lit up but was slightly blinky - like it was bickering ever so slightly.
I changed the color wash to the aces effect and selected a face (which I had set up with all o its appropriate graphics - the mad scientist images you've already seen me use)..... he displayed on the matrix (without me pressing play) for a couple o seconds then the debug screen popped up.
I have attached that debug report for you to see as I noted the Crash Handler had been called in it.
-
Didn't everything work when you pretended it was a Pixie4 and a Pixie8? I'm just not sure I can debug this without having a Pixie16 myself.
-
I don't recall ever trying to put a face on it - just color wash and stuff like that. Ill try the face again on a 4 and 8 to see what it does.
-
I helped someone yesterday with a Pixie8. He was running at 115Kbaud. Simple effects like On and Bars were working fine but when he dropped a Butterfly he got lag but he wasn't crashing. I'm pretty sure if he switched to a 512Kbaud dongle his would have worked. So the point is a Butterfly effect is a pretty good stress test for the LOR protocol because it has so many different colors on different channels that it brings out the inefficiencies of the protocol. So what I'm hearing is you had some lag with ColorWash but no crashing. Then you tried a more complex effect and it couldn't keep up and crashed. You may just be crossing a channel limit that we can't handle.
-
as a Pixie4 - color wash worked until I added a second color then it flickered.
Face effect crashed it.
-
Something else I noted - not really completely related --- when it crashes and I restart xLights I get an error message when I press the white light bulb to turn it yellow that the port is in use - so it would seem to me that the crash handling routines don't free up the com port(s) that are in use.
Before testing again, though, I always clicked on white bulb - got message - clicked on black bulb to free them up - quit xLights - started up xLights and then did not get that error message --- just to be sure I wasn't starting out already compromised.
-
A thought that popped into my head as I wondered about all of this just now ---- I have been doing all of the testing on the Windows machine with the RS485 dongles - but if I am not running the LOR software (which is Windows only) and since xLights itself will run on the Mac - can I plug the RS485 dongles onto my Mac and run from there????? And, if I can, do you think that'd make any difference?
I didn't connect them because I didn't want to let the magic smoke out of anything just in case!
-
as a Pixie4 - color wash worked until I added a second color then it flickered.
Face effect crashed it.
I know running a Pixie4 will not crash my setup so I'm not sure what is going on. There was nothing useful in the file you attached. I also have no idea whether you can hookup those USB dongles to a MAC. I can't believe any hardware damage could occur its probably just either going to work or not work. Depends on whether the MAC has the driver for the serial to USB chip LOR is using.
-
It seems to be crashing in OutputManager::SetManyChannels which is odd ... i would have thought it more likely to crash in the class for the LOR output.
-
So did you give up and just use LOR? I saw you post that you wanted to stick with all LOR software if you could or were you just trying to keep the LOR wolves off your back...lol.
I've been testing and the only time I can get a crash is when I define a ton of channels and then turn off Output to Lights. It appears that if the interface can't handle the amount of data its stacking up in the output buffer of the serial driver and we weren't giving it long enough to transmit all the data when we closed the port. I'm trying to figure out a good way to not let it stack up but that will mean skipping frames when its too much data.
I did some testing and with a Pixie16 defined at 300 channels per port which is 4,800 channels it was averaging 13,250 bytes per frame when I used a Butterfly effect. Then I switched to a Bars effect and it was only 320 bytes and then 3 frames of 0 bytes. So that's what I mean about their protocol its highly depending on the number of different colors on the channels. An effect like Bars with lots of channels having the same color is more efficient than E1.31 protocol but use a Butterfly and its like 3 times worse than E1.31.
So using a 50ms sequence timing 13,250 bytes per frame would take about 5.1 seconds to transmit 1 seconds worth of data at 512Kbaud. So depending on the effect you might be limited to 1000 channels at 512Kbaud but more channels for simple effects with a lot of the same color. Now LOR might be more efficient because they have that new enhanced protocol where they apparently tried to overcome these shortcomings but its not like they want to share their scheme to help us out. They want to lock you into their hardware and software and its working for some people. If they were purely a hardware vendor they would publish that protocol because it would be in their best interest that everyone using their hardware had a good experience no matter which software they use.
-
Perhaps the way I worded it was misleading - I meant that I was happy with what I was doing and accomplishing and was content to stick with LOR but that I recently I couldn't accomplish what I wanted to with their current software and I began looking around - thus coming across xLights which did allow me to accomplish what I had hoped for EXCEPT for this blasted crashing problem!
I can understand that the butterfly effect would be pretty darned intense in terms of data....but you saw the sequence I was testing with - and it was nothing like a butterfly effect. I was testing with a singing face - just the face - no additional effects involved at all....and it crashed almost immediately.
So what do we do next - is there anything I can do to test anything further?
And, what if I had used 4 - Pixie4s instead of one Pixie16? Would that really be any different - they would still be all the same effects on all the same pixels - just multiple controller addresses all on the same network, right? So the end result would have been the same?????
I also take it that you can't tell at all what is going on with their Enhanced protocol - to try to replicate it in any way???
So - because the 11th hour is very nearly upon me with this year's show - do I just give up on using xLights? I currently have all my sequencing done in xLights for my show - and no way to get that show up on the pixels! I can't even get the export of the clipboard of just the matrix to copy into LOR S5 properly (the matrix portion of the sequencing being the part that xLights the really does for me those things I want - I could do the rest with LOR if I had to). I'm afraid there will be no Halloween show at all and my Christmas show will be without all the bells and whistles I had hoped for if I have to now start over again in LOR.
-
I don't know if it will help your crash but I was having a blue screen crash with that LOR output when turning off output to lights with a lot of channels. I implemented a fix that is now preventing that crash. What I do is inspect the serial transmit queue and if its still not empty from the previous frame then I skip the current frame. That keeps it from stacking up a ton of data. I also added log messages that will let us know how many bytes you are transmitting and will record when frames are skipped. Keith might get it released tonight.
-
Ok - cool! I'll watch for that new release and download and test as soon as I can! I do appreciate all of your hard work on this.
I guess the one question I would have about this is - if it's dropping frames isn't that going to make any sort of animation attempt lok jumpy? Of course, jumpy is better than a crash, of course!
-
Jumpy or laggy. They are the only two options when the output can’t keep up.
Sent from my iPhone using Tapatalk
-
Simple stuff worked like before - but as soon as any load was put on the system - used Monster Mash again because it's the same one I"ve tested with in the past - as soon as the Faces effect cam up it crashed...played the initial part of the sequence OK - no obvious jumping or lagging - but as soon as it was time or the face, it crashed.
Attached the sequence and log files.
-
Well I can't get mine to crash like that so I don't know what to look at. It looks like you have 4 of the outputs running and I only have 1 so that's one difference. Those Faces effects may not look that complex but according to the log each output was averaging 4,000 bytes per frame and it was doing the skipping properly. Pretty much every other frame is going to skip at that size because it would take 1.5 seconds to send 20 frames of 4,000 bytes over a 512Kbaud output. So if you are running 20 FPS it can't keep up. It's crashing inside the function that loads the data packet for that output so maybe there is a problem in that code for some outlying condition but its not easy to find unless its happening to me.
-
Is there anything else I can run, or log, or do to try to get you more data to work with. I'm not at all computer illiterate so can do pretty much whatever you need - keeping in mind that I quit programming before learning much o what you guys are programming in - yet if I look at your code or logs I can read it enough to know what is going on - just couldn't begin to write the code rom scratch myself.
Maybe I should look at that language a bit more closely - I understand the principles just haven't even used it -- have done object oriented web based stuff in the last couple o years I worked (now retired)...having started back in the large IBM mainframe days with COBOL then learning Visual Basic and SQL and web design and PHP, etc.....so perhaps if you tell me what to do to help, I could do something more with this problem to help resolve it.
-
Even if we stop the crashing I'm not sure you'll be happy with the lag you're gonna have using that many channels. I can try putting a bunch of log messages inside the function to try to narrow down where in the function it's crashing. It usually takes several iterations and since its during the week you won't get updates from me very often. Why again are you not able to just use LOR for everything this year? If you have your channels matches up can't you just use the Convert Dialog and export to an LMS file?
-
Well - you guys convert to S4 - and because of number of pixels I have basically been forced into S5.....so I can't just export/convert.
When I try just exporting a clipboard it doesn't work, when I try importing an exported avi al o it isn't in there.
That is what I have another thread running here in the forums about the clipboards exporting.
-
So if you had LMS files in S4 they were useless and unable to be opened in S5?
-
When S5 tried to open them they would not convert because there was no exported "configuration" data included in the file so S5 didn't know what to do with any of it....or at least that is what LOR tech support suggested was the problem - the convert process ran for 4-5 hours and I finally forced the program to quit - then asked for tech support help on that issue and that was what I was told - no configuration information included in the file.
-
So no way to also have S4 on your machine? I'm pretty sure S4 would open the file and then you can import a saved channel configuration from another file. Then you would have a file that should work in S5.
I can try to add some log messages and send you a new xlights.exe tonight.
-
You know you don't need to write code but if you were able to get everything setup and building in Visual Studio you could run the code with a debug build and when it crashed hopefully be able to see in the debugger which line its crashing on. Then if we were in Zoom we could inspect where there might be a null pointer or array boundary violation. There are ReadMe's in the code base that have the installation/compiling instructions. First step would be to install GIT for Windows and figure out how clone the xLights GIT repository.
-
I'll try opening in S4 - I haven't tried that because I thought I'd have to set up my whole display all over again in S4 - and S4 doesn't support 100-pixel strings which most o mine are - hence the need to run in S5- and that seemed daunting to me or some reason.
I could try importing it into S4 because i have two Windows machines (one still has S4 on it)...see what happens.
I don't have Visual Studio on my Windows machine, at least it doesn't come up in my "Start Menu" programs listing. I'll have to look at the Microsot site and see what's out there.
Also, not familiar with what GIT is - but I can learn (and typically can learn new things in programming, etc. quickly). I'll google Git and see what comes up.
-
OK - I found GIThub and created an account - searched and found smeighan/xlights.
But have not done anything further yet.
I see the Clone or Download - but am not sure...should I do that on my S5 or my S4 Windows machine? My lights actually run from my S5 machine...so I suspect it would need to be there...but I typically sequence and mess around on my Mac (or the S4 machine) then copy it over to test it.
-
You would want to run the debugger from whatever machine can control the hardware. Visual Studio 2017 Community Edition should be free to install. I use Git For Windows along with TortoiseGit I'm not always sure which one of those programs is providing the features I use. With those installed I can just copy the GitHub link and then right-click inside any folder (I use c:\SoftwareDevelopment\Git) and choose an option like Clone Repository and it automatically has the folder I copied and I just hit OK.
-
OK
I opened GitHub and went to the repository or xLights on the "control" Windows machine.It asked i I wanted a desktop version of Git and I said yes.....so it is on my computer now.
It is currently downloading the clone of xlights onto my machine (my internet isn't the fastest - I'm way out in the country with no access to high bandwidth connections).
After it is done I'll go to Microsoft and download the community version of Visual Studio. I'll let you know here when that is completed and installed.
-
Github finished the clone and I'm able to look at the code, etc.
Microsoft Visual Studio is in the process of downloading and installing now.
Other than the basic Visual Studio download should I download any of the other pieces and parts they have there on that download page. One is an Atom editor, another is some sort of Visual Studio Code (which seems to also be an editor), and there is Azure DevOps (Azure Tools, etc.)..... do I need any of that?
-
No you don't need any of those other Microsoft Tools. You will need to download wxWidgets source code and build it using VS so you need to find the ReadMe.Windows in the top level of the xLights source and follow those instructions. Make sure to follow the Visual Studio sections and not the CodeBlocks sections.
-
Will do.
-
OK - part way through the process - when running the makefile process that the readme suggests may fail a couple o times - it has failed (I think) with this message several times. I must be missing something or doing something in the wrong place.
It says (after warning about no warranty, etc):
reading makefiles...
mingw32-make: makefile.gcc: No such file or directory
Updating make files...
mingw32-make: *** No rule to make target 'makefile.gcc'. Stop
-
Yeah I think you started in the wrong section because I don't believe mingw32 is not used for a Visual Studio build. I said you needed to follow the Visual Studio instructions so skip down to line 204 in the ReadMe. You probably need to blow away the wxWidgets directory and start it over to be safe.
-
Well - i feel stupid - but..I have to ask or help again...I think I made it through the whole wxWidgets build part correctly --- didn't seem to give me any errors. but when I now open xLights and tell it to build it is giving error saying it can't find include wx/______ (various ales). so clearly my wxWidgets didn't go to the right place. Can I copy the folder from where ever it is and put it where it is supposed to be - wherever that is.....it would seem like it wants to be inside the xlights older since it doesn't have any prefix infront o the wx/whatevverile.... and it certainly isn't in there when I look there. I don't see where anything I did ever told it where to put the wx directory - so maybe I"m still in the weeds here.
This is all new to me - so if I sound stupid I simply have never had to set up my own environment like this before - so it's all new to me. The instructions make sense and when I follow them I don't get error messages up until I try the build o xLights itself when it can't ind the includes.
-
To make it work with the Visual Studio project we checkin it expects the wxWidgets folder to be at the same level as the xLights folder not inside it. So I have
C:\SoftwareDevelopment\Git\wxWidgets
C:\SoftwareDevelopment\Git\xLights
My xLights Visual Studio solution file is at:
C:\SoftwareDevelopment\Git\xLights\xLights\xLights.sln
...and all the paths to wxWidgets begin with: ../../wxWidgets which means go up 2 folders from the solution directory.
-
OK - I'll look at it again in the morning - is it OK for me to just copy the wxWidgets folder to that new location without redoing all that build stuff again?
-
Maybe. Where did you put it relative to the xLights folder?
By the way email me again I think I deleted all the other messages. I had a new build with debug messages.
-
You can see in the build instructions where Keith said to have a base directory <basedir> to install all source code and then he references <basedir>/wxWidgets and <basedir>/xLights
-
I just delete it and do it again - it wasn't that big of a deal.
I misread it and put only xLights in the <basedir> with wxWidgets beside that - so it's up one to high.
jeff(at)jeffreyamills(dot)com is my email.
-
Ok I added a bunch of messages that will spam the log file to hopefully let me know where it's crashing in that function but I can't email it till much later this evening. If you want to work on compiling I can check here during the day to see if I can offer any help.
-
It finished the build with a FAILED message --- says "Xlights.vcxproj - - FAILED
above that line is one that reads:
"C:\jamills\Documents\GitHub\lights\xlights\x64\Release\Xlights.exe : fatal error LNK1120 : 2 unresolved externals"
above that are a number of lines that include for various module: "unresolved external symbol _imp_CrtDbgReportW"
or "unresolved external symbol _imp_invalid_parameter"
-
OK - in debug format the build completed.
-
OK - it crashed in the same spot in Monster Mash that it always does.
on line 1733 in std::vector<_Ty,_Alloc>
1732 #if _ITERATOR_DEBUG_LEVEL !=0
1733 _STL_VERIFY(_Pos < size(), "vector subscript out of range");
1734 #endif /* _ITERATOR_DEBUG_LEVEL !=0 */
at the end of 1733 is the red stop sign X with a message: "Unhandled exception at 0x00007FFAA6F897DC (ucrtbased.dll) in xLights.exe: An invalid parameter was passed to a function that considers invalid parameters fatal."
In the Call Stack window: > Xlights.exe!std::vector<LORDataPair,std::allocator<LORDataPair> >::operator[](const unsigned __int64 _Pos) Line 1733 C++
-
FYI - the next line after what I posted above is the call to the SetManyChannels function.
So the crash occurred in setting up for that call, I would say.
-
Yeah you might need to backup a couple lines in the call stack. Try to double-click each line until it opens up the LOREnhancedOutput.cpp file because inside the SetManyChannels function is where it probably started. We might need to wait till I get home and could jump in a Zoom session and see it.
It looks like it crashed on a variable named lorBankData so if you get to that line where it crashed hover over the shift_offset and the "i" index variables and see what the values are. One of them is outside the allocated size of the array.
This is good. If we can cause a reliable crash in the debugger we can prevent it.
-
only 2 line above it in the call stack and they are:
uccrtbased.dll!00007ffaa6f897dc()
ucrtbased.dll!00007ffaa6f89727()
But the line below is the call to:
Xlights.exe!OutputManager::SetManyChannels(long channel, unsigned char * data long size) line 211
on 211 is a for loop where i is 0 to < num_bankrecords
i is 9
in the next set of statements is an if statement - I wonder about it though - the comment above the if says that it is to send betweeen 0 and FF - but the if reads:
if(lorBankData[bank].value !0) && (lorBankData[bank].value !=0xFF)...
weel that is just saying its not 0 or not FF isn't really checking if it's between the two is it?
Anyway --- at that point i=9 and bank=0
in the call stack the next line is Line 953 in OutputManager::SetManyChannels ---and on that line variable sth get set to 1, then it goes on to:
stch = 1;
left -= send;
o = GetOutput(o->GetOutputNumber());
-
forgot to say - num_BankRecords was = 10 so 9 was a valid number in that loop
-
It's that line 211 where it crashed. Which doesn't make sense because if "bank" or "i" were out of range it should have crashed when iterating through the same array on line 201 using the same variables. The comment is correct. First I gather up all the channels that need to be set to 0 and build that part of the packet, second I gather all the channels being set to 0xFF, and third its processing all the channels that were not covered in the first 2 sections.
-
Ah - I just knew that wasn't checking to see if it was in-between 0 and 0xFF - that's why I asked.
Well then - at this point it's OK to wipe out what I have on screen now and run it again and see if I get the same results???????
-
If you can hover over the bank variable on line 211 see what it's value is. Also hover over lorBankData and see if it shows anything valuable.
Yes that line is actually making sure the value is between 0 and FF because if its not 0 and its not FF it has to be in-between.
-
Thought I mentioned those variables above but in case I didn't ... i=9, bank =0 and nothing happens when i hover over the .value part...the actual lorBankData part shows: lorBankData {size=23}
-
Just out of curiosity - so that number that is not 0 and not 0xFF --- have you somewhere earlier verified that it is not out of that range - or do you create it and therefore know it must be between those if it not one or the other?
-
Ok yes I missed the line where you showed bank = 0. Not easy to tell what's wrong because reviewing the code it should not be possible for either of those values to be out of range because they are set based on the sizes read directly from that array object.
-
Just out of curiosity - so that number that is not 0 and not 0xFF --- have you somewhere earlier verified that it is not out of that range - or do you create it and therefore know it must be between those if it not one or the other?
Its a wxByte so its only an 8 bit number. It can't be greater than 0xFF and even if it was a larger integer that wouldn't cause that line to crash.
-
Ok - that makes sense.
So should I go ahead and rerun it again to see if it fails at the same point again?
-
Sure it won't hurt anything to try it again. We might have to get on Zoom together so I can browse around and see if anything makes sense.
-
No problem - I"ll run it and see what happens!
-
Crash appeared to be in the same place watching the matrix - but it was a different bit of code - same variable involved...
CALL STACK:
xlights.exe!LOROptimizedOutput::SetManyChannels(long channel, unsigned char * data, longs size) Line 177
175 wxabyte lsb = lorBankData[bank].bits & 0xF;
176 wxabyte msb = lorBankData[bank].bits >> 8;
177 d[idx++]=0;
in 175 and 176 - bank=0, i=2
in 177 idx++ is 1046
hover on 175 on lorBankData[bank] shows {value=0 '\0\ bits=22308}
-
Ok that looks like the problem is the data buffer size. Can you change the number inside line 103 from 1024 to something larger like 2048 and try again? That value where is blew up had the index set to 1047 so it blew past the 1024 size. I thought I had calculated that a packet couldn't go larger than 1024 but I obviously messed up.
-
One other thing to change. I believe I designed it only expecting 512 channels per unit id but a Pixie can have up to 300 nodes? That's could mean 900 channels per unit ID. With 16 channels per bank that means I need at least 56 banks but I only allocated 32.
For LOROptimisedOutput.h and .cpp:
Change line 22 in the header from 32 to 64.
And lines 32 and 109 in the cpp file from 32 to 64.
-
Ran it before seeing your second post --- here's what happened...
the entire sequence played completely without crashing - it was VERY jumpy. the singing face never showed up at all, pictures showed up when they were supposed to, the marquee border looked like blinking lights - not a marquee, many of the effects (like shapes>circles acting as bubbles in the scientist's lab only appeared sporadically.
BUT at least it didn't crash!
So here's a question - and maybe the processing of this would be so time consuming it would negate any benefit it would produce...but is it possible to know from frame to frame only those pixels which have changed from the previous frame and only output those specific pixels?
I'll go make those other changes and run it again.
-
OK - made those few changes - it ran again to completion - no crash - BUT still pretty much unusable output - but moving in the right direction!
I also noticed that the Face doesn't show up on the house preview screen either --- so it's not displaying --- yet near the end of the song I do use one of the face images in a Picture effect and it shows up - so the pictures are there.
Another thing I noted in watching it - as things appear on the matrix you can visibly see the matrix redraw from left to right - I mean the image or effect actually is visible appearing column by column in a sweep across the matrix.
-
It should already be skipping channels that don't change but it does it in banks of 16 so if any channel in each block of 16 changes it sends the command for all 16. See line 135 for where it looks at what was sent out the previous frame to detect changes.
-
Can you define "bank of 16"? Is that 16 pixels, 16 channels as defined in xLights channel counts (ie: 300 per string of 100 pixels), or 16 what???
Sounds like you mean bank of 16 channels (as in 300 per 100 pixel string) from the way you say it so that would imply that in a string of 100 pixels there would be 18.75 banks of channels--- is that right?
And they go lowest to highest channel so that accounts or the slow paint of the images/effects from left to right across the matrix.
-
I know this RS8485 protocol is not speedy by any stretch o the imagination - but even before adding the Enhanced Protocol this year I was able to send this kind of data out across the LOR networks last year and previous years - so somehow it is being done. I just wish we could figure out what the trick to enhanced protocol is so that we could get the output up to a higher speed.
I mean really - seeing what you guys have done with xLights compared to what I see in LOR S5 - I know you have the programming talent --- there is just some little tweak that needs to be done to get the data moving faster.
-
Well it is probably running slow because you are in the debugger so it could improve once we put the increased values into a release build. By bank of 16 I mean channels not pixels. All of LOR's stuff originally used to be 16 channel AC controllers so their protocol is heavily geared towards setting banks of 16 channels. They use 2 bytes as a 16 channel bitfield to indicate which channels in that bank are going to receive the value of that command.
-
Good point about it bogging down in the debugger.
I understand about the 16 channel banks now, too.
So any thoughts why the singing face isn't showing up at all???
-
Well the fact that I'm dropping frames when the output buffer is not empty combined with only sending changes might not go together. If you comment out lines 135 and 138 it would force it to send all channels every frame. Then at least when it drops frames it would at least set all channels for the frames it does send.
So you are saying you ran the same amount of data last year using LOR even without their Enhanced Protocol?
-
Well actually looking at the code it won't update the last sent buffer if it skips the frame so it should still work fine looking to only send differences.
-
So look at the log and see how big are the packets averaging or what max value are they hitting.
-
I'll do more testing in the morning - but, to answer your question - yes - I had a very similarly sized display using CCRs (50-pixel ribbons) instead of the CCBs (pixel bulbs). I did run it on 7 LOR networks to spread the load - but here in this test I'm only running the matrix connected - and it's on 2 networks so the load is spread across two. I, of course, have no idea what the data rate was in previous years...but if you want to see some of my show it's on Youtube in my account there as "706 Lights" - you can see it had a pretty active matrix and lots of lighting effects going on.
Those videos did not have anything running in the enhanced protocol as I only needed that when I upped to 100-pixel strings.
-
Commented out lines 135 & 138 as you suggested.....ran several tests....
ALL sequences played to completion with no crash.
NO sequences displayed a face when a Faces effect was there.
The jerkiness was much improved - still some there - but that may well improve when a compiled release is run instead of the debug version.
Seems to be moving in the right direction - that's for sure!!!
-
Instead of playing full sequences can you just create a short animation and try to just get a Faces effect working from the grid. It doesn't make sense for those effects to play nothing at all its not like the data is any different.
-
Made a short animation - added in a face effect - rendered it and played it - NO ace appeared. Tried several different faces (different sets of images) - none worked. They do show up if I put them on as an image.
So to be sure it wan't a data transmission error - I moved the face over to start at 5-seconds in and place a 5-second butterfly effect ahead of the face. It played the butterfly (of course in debug it was not smooth - but it played it all).
Just as an aside - you might recall in the other thread about the exporting of clipboards and avis - it was the faces sect that was missing from my avi exports, too. Makes me wonder if there is some correlation between the two events.
-
Email reply with logs on it's way to you.
-
But you see the faces in the whole house preview after doing a Render all and playing it on the grid?
-
Create a 5 second animation with just a Faces effect that works in preview then render and save it. I'd like to see the FSEQ file. If nothing is showing up then it will be all zeros in the FSEQ file after the header.
-
No - it does not play it - or show it on the House Preview.
Attached that FSEQ and it's associated XML
-
No - it does not play it - or show it on the House Preview.
Attached that FSEQ and it's associated XML
Something is wrong in the sequence if it doesn't show on the House Preview. xLights just sends the same data to the network that is used to show the House Preview so you got to get that working first.
-
Not a single one of my singing aces shows in any sequence.
-
I looked at the MonsterMash file you gave me and the very first Face effect appears to be using a Color palette that only has box #6 checked and the color in that box is black. Might want check what colors you have selected for your Faces effects. They must match the string type if you have single color models also.
-
Yep it appears that every Faces effect in that sequence is using the same color palette entry. So it's all rendering just fine if you like black.
-
Now you have me confused! The aces are images - so why do they care what color is selected? The colors come from the actual image files.
-
Well I'm just staring at a text file so maybe I got it wrong....lol. Bottom line is if they don't show up in preview they will not show up on the real thing. Is the path still good they look like they come from here.
/Applications/xLights/shows/MyFaces/Scientist/Scientist_rest_eo.png
-
Yes - good path - because I can put on a Picture effect and point to one of them and have it show up.
[Just sent an email with USBlyzer info]
-
Yeah I hope USBlyzer will let me open the file since my trial expired. I guess I could install on a different PC since I don't really need to capture anything.
I thought our effects only stored non-default values in the xml file to save space. The faces effects have some type of transparent setting that I'm not familiar with. I'd just make sure the effect is using defaults. Click a different effect then drag a new Faces effect down and look at its defaults.
-
I added in another Face effect on a different layer in a different sequence - my Grinch song. He doesn't show up either when I play it. The new face settings are the same as the existing one. and it, as you might expect, does not show either.
This is sort of a new problem with the faces for me, too. They were showing back when it made the sequence crash as long as I had lights not controlled the sequence played and the face showed on the matrix in the preview. And, yes, I turned of Control Lights and tried it again - no ace.
I also went to that older on my PC to verify that those images really do still exist there in case somehow they got deleted during all of my installing and installing of things. They are all there.
-
Ok try this.
Ensure the reset settings on colour buffer and layer panels are all checked.
Drop a butterfly
Now immediately drop a face effect.
Set the settings for the face effect. Does that work.
I am concerned you have a setting on one of the other panels screwing it up.
Sent from my iPhone using Tapatalk
-
Well there you go!!!
I made a new sequence - animation - dropped in a butterly then dropped a face on to replace the butterfly and the ace appeared and played after a render.
in my non-working sequence those there check boxes were, in fact, already checked. And they were checked in my new sequence.
So - I guess I need to ask, what might have changed that would affect this in the past couple of releases? I have not made any changes to these sequences in a while since I've been working with Gil to see i I can even drive my show with xLights - so I didn't put any more sort into the sequences I've already worked on -- so definitely didn't suddenly turn on or o something that would affect this...and certainly not is ALL of my sequences. If it was one sequence I could think I might have changed something without recognizing it....but since it's all of my sequences it must be some combination of my configuration and the newer versions of the software that have conspired to make my faces go wonky.
-
To work that out bring up an effect that doesn’t work and one that does and panel by panel compare the settings. Alternatively.
Copy a fave effect that doesn’t work and paste it into notepad. Clearly mark that as not working
Do the same on one that does work and clearly mark that one.
Then post it all here and we will tell you why one works and one doesn’t.
Sent from my iPhone using Tapatalk
-
Will do - but note the only one that isn't working is the aces effect - everything else works as expected.
-
OK - I must be losing my mind! I did nothing - changed nothing --- all I have done is that bit you suggested to drop in a butterfly then switch it to a face......all my faces have begun working now! This makes no sense whatsoever!!!!!!!
I didn't re-render the sequence.
Ah...but....after Gil suggested I try the USBlyzer I had to restart the computer to finish that install --- and did not run anything with a face after that restart. So perhaps something was locked up in memory somewhere from one of the earlier crashes we were working on and that restart cleared it.
I don't know - but I'm completely surprised now!!!!!!!
And, Gil, my Monster Mash sequence played through to completion and didn't crash and the face sang along just fine! Now, granted it is still ever so slightly jerky - but tolerable. This is running from the exe you sent me this morning not from the one you had me modify on my own machine....so maybe commenting out those two lines like you had me do, might get rid of the rest of that slight flicker.
I notice the flicker especially in the marquee effect because it doesn't smoothly move around the edge - but hops skips and jumps around the edge. On the face, because most of it doesn't change, I don't see it as much - though he has a slight flicker.
-
Ok maybe I'll see about having an option for whether to try to only send channel data that changes. I can also see if there is anything I can do with the Enhanced Protocol. The exe I gave you this morning is basically just a Codeblocks release build of everything up to my last checkin yesterday. Now that you have GitHub working you could actually pull code and rebuild if you wanted to do any experiments.
-
But in pulling and modifying I'd still be running in Debug mode, right? And that would still be dead slow and laggy?
-
Yeah unless we can figure out why VS release won't build. I tried last night and got an "out of space" error for some .ipmd file it was trying to create even though I had like 35 gig available.
-
I've not tried to build an actual release from it - just let it build the pieces and parts I've changed as needed to run in debug.
-
My Image Faces are not working again. I restarted the computer, still no.
I found a couple that worked, but discovered that after a rrender they no longer appear in the preview (or on the matrix). You or Keith suggested copying the effect to Notepad showing a working one and a not working one...attached is that notepad file showing two faces before the render and after/working/not working. I don't see anything different between the two - but perhaps you will.
-
Have you checked your master view render order to make sure you don't have effects on model groups that contain the matrix that render after the matrix? That issue is most likely something in your sequence or model order and not a bug.
-
I will look but the weird thing is they both appeared in the preview window (and actually played) but were off/out of alignment because I had modified my Layout - so I rendered them and that's when they disappeared.And, along with the ace - the whole sequence disappears from the preview - no effects show at all. I'm really confused by this as it only started very recently.
-
You've used the word "ace" many times in this thread. I assume you are trying to type "face". I was starting to thing your key was broken but it seems to work in all the other words. :)
-
I notice that it doesn't type the "F" about half the time, too - not sure why - maybe it's just my finger!!!! LOL
I sometimes try to remember to go back and proofread the messages - but, as you see, don't always!