Frustrated with all sequencing software

[battle79]

I find it interesting that the premise of all sequencing/effects being community input is exactly how vixen3 has been written.

Even basic effects like a ramp are actually modules that are added to the main sequencing engine. Wipes, Fades, spins, heck even Nutcracker is just a module (outdated atm, works are in progress to keep in step with sean) inside vixen.

If more people jumped on board and added modules, their is no limit to the effects that could be created.

One glaring hole ATM in vixen is it lacks a way to output to a format that any other sequencer can interpret. An output module to convert to xLights (presumably) is slated for early this year.

Once this is in place, Vixen to xLights to RasbPi. Turn computer off and enjoy lights for the rest of December.

Cheers,
Rowan

 

[Valentinorx]

The more I play with all the offerings I'm finding LSP to be the jack of all trades. Now that my viz is fixed (thanks chat room) it's game on. For a new person diving into rgb the use of macros and transitions through the use of layers is tough to beat. I'm sure lsp isn't perfect but right now it seems to fit the bill for me. The others are too cumbersome or difficult to understand for me.

 

[dkulp]

My thoughts were that the main software packages should be focusing on the complexities of the core, being light/sound control and output, scheduling and most importantly providing a framework for add-ons.

Personally, I disagree with part of that.... I don't see why SEQUENCING software needs to be at all concerned with scheduling and outputs. I really don't understand why all the packages try to cram both of them together. We have some software that is good at scheduling and output (xLights, FPP, others...). Just make sure the sequencing software can provide the sequences in a form they can use. Let the sequencing software concentrate on doing a completely bang up job and being the best software for sequencing the lights.


That's my opinion and I'm sticking to it.


Dan

 

[twooly]

My thoughts were that the main software packages should be focusing on the complexities of the core, being light/sound control and output, scheduling and most importantly providing a framework for add-ons.

Personally, I disagree with part of that.... I don't see why SEQUENCING software needs to be at all concerned with scheduling and outputs. I really don't understand why all the packages try to cram both of them together. We have some software that is good at scheduling and output (xLights, FPP, others...). Just make sure the sequencing software can provide the sequences in a form they can use. Let the sequencing software concentrate on doing a completely bang up job and being the best software for sequencing the lights.


That's my opinion and I'm sticking to it.


Dan

This is exactly how I felt and why I was disappointed when lsp rewrote the scheduler first. If you can't create a good sequence without the user tearing their hair out with bugs what good is a new scheduler if you don't have a sequence. I myself use the dla conductor so I could care less about a fancy scheduler.

 

[Gilrock]

To be honest I had never even heard of Vixen before until this site crashed and I started reading the posts on doityourselfchristmas. I had signed up there a year ago and never read any posts until this site was having trouble. It's funny how each site seems to have a higher concentration of people that use a particular controller or software package. I had never heard of a Renard controller either and I start reading posts over there and everyone has a lovefest with Vixen and Renard.
I thought I read that you couldn't convert Vixen 3 files to run on a FPP so I didn't check it out. I ran into the same issue with HLS. I tried to create a sequence and get it converted in xLights for the Pi player and it didn't work. That's why I kinda don't trust using HLS...even if they get the conversion working who's to say he won't make another change that breaks the conversion.

 

[battle79]

You read right coppercreek,

At this time vixen has no get out of jail/save my ass function. Once they finish the conversion/output module, many more people will be willing to give it a go, as hours put into sequencing could at least be salvaged and converted to another sequencer.

That being said I ran ~9k channels with little to no problems at all. I did manage to corrupt one effect when transferring to show PC. Had to open sequence and redo effect to resolve.

I just enjoy the fact that at least 5 people are working on it, and many more writing modules, so it's not going to go away at any time, and you get a quick response to any problem.

Considering trying LSP, but not sure I could put up with the crashing. Vixen crashed ~5 times in 3 months of sequencing, and ran the entire of December without being turned off.

Regards,
Rowan

 

[dale82]

Well I cannot comment too much on Vixen as I haven't used it, But LSP I have had a lot to do with and I will say one thing, Although it is in no way perfect, Since the 2.8 update of the sequencer I haven't had an issue with the sequencer, Now the Scheduler, That ran rock solid for me for 2 months as I started on the 1st November as this was my first year with LSP and all Pixels. So I made sure that I had ample time to correct any mistakes that I made in the sequencing.

I for one cannot wait to see what LSP Sequencer Rewrite has in store for us, because if it is as good as the scheduler it will by far be the better software. This is just my opinion.

Cheers
Dale

 

[dpitts]

As an LSP user the things that frustrate me the most are ...
1. It takes to long to see the outcome of an applied macro. I think any sequencer in the future that cannot provide real time feedback of effects/macros applied to an element will be at a major disadvantage.

2. I still cannot get copy and paste to work right some of the time.
3. The injection of timing marks I dont what to see. I wish there was a fixed 25 or 50ms grid.

Things I like and would like to see in other sequencers.
1. Location mapping of pixels with preview.

This is main reason for using LSP. Although waiting for rendered effects make me use it less. If other sequencers can do this I will give them a shot. I know Vixen 3 started doing this but I am running 20K+ pixels and I heard they had problems with playback with much less than that. Also no way to export to my favorite player the Falcon Pi Player.

 

[ԆцряєсϮ]

As an LSP user the things that frustrate me the most are ...
1. It takes to long to see the outcome of an applied macro. I think any sequencer in the future that cannot provide real time feedback of effects/macros applied to an element will be at a major disadvantage.

2. I still cannot get copy and paste to work right some of the time.
3. The injection of timing marks I dont what to see. I wish there was a fixed 25 or 50ms grid.

Things I like and would like to see in other sequencers.
1. Location mapping of pixels with preview.

What he said ^^^^

 

[arw01]

I think sequencers will have to move away from keeping more than abstract effects in xml. That is a major advantage nutcracker has over others, in that it keeps the effects themselves in the xml only, and doesn't try to read the actual data of the effect everytime it does something.


LSP, and I suspect many others, have these massive xml files with every channel's effect instead of do a chase spiraling down with these parameters and having them generated on the fly.


Moving to a database to store the sequence I think could massively speed up vs having to read the whole multi-meg xml file, find just the right spot, insert, rewrite the whole file.


With some sort of database (and I think a light and proven sql engine), it's just an insert. A query could return anything you wanted and could dream up. If they got the coordinates, you could make a query that would just return the outmost pixels on a star, or stuff I cannot even fathom yet.


Sure hope LSP can get their 2014 rewrite into our hands early enough to be useful.


On the cut and paste, toggling active mouse mode on or off with timing highlights can tame that down massively. With active mouse mode off, you can get more of an exact grid, and turn it back on to work more between the timing highlights you have active. It can still be a bit picky about exactly where, but I found 96% of the time flipping to the appropriate mode solved the issue. If you had a macro program that you could program a key for, it would help do it more conveniently.

 

[smeighan]

i think vixen 3 also stores their sequences in high level terms in their xml.


LSP and LOR store every byte of your show wrapped with 20-100 bytes of overhead.


DLA Conductor, xLights xseq, pi player fseq files are binary and give you the most compact storage of a sequence.


so matt browns approach was to do both
1) xseq file for wizards in winter 50mbytes. You can compare thsi to teh same sequence in LOR lms is 900mbytes
2) an xml file that has every sequence setting, 20kbytes


you can lose the xseq and recreate it as long as you have the xml. The xml can be shared with people. you never would give them the xseq.


i think vixen 3 has something like 2) and are working to make a version of 1).


It is unfortunate that we cant decide on one common file format.


i expect my 24K channels to be 32-48K channels this year. I think this is a trend that says whatever sequencer you have you better be trying it with use cases of at least 30K channels.


as far as playing the massive shows, i think dave has plans for the master slave pi players for this year. Maybe something like 30-50K channels per pi player.


it will be an interesting year for all of the active sequencers
vixen+, vixen3, hls, lsp,lor,xlights


sean

 

[tjames]

It is unfortunate that we cant decide on one common file format.

Ultimately this would be less of an issue if there was a single app or suite of apps that did everything we wanted them to do without the headaches, issues or otherwise. That said, aside from the bundled xml parsers on most platforms, I don't see why everyone insists on using a markup language for data serialization and storage, when much lighter formats like YAML or JSON can get the job done without the extra overhead.