Author Topic: Any work being done to 'stitch together' sequences?  (Read 1286 times)

Offline Steve Gase

  • Sr. Member
  • ****
  • Posts: 2915
    • WinterLightShow in Georgetown, TX
I've seen the past discussions that recommended breaking up sophisticated sequences into smaller pieces so that they can be more manageable... not overwhelming LSP2 with memory and complexity issues by doing 15 seconds in each piece.

I'm wondering what has been done to date to aid in stitching these together.

Two options that I think would be equally viable:

  • A script that reads the file format and combines all of the input files into a larger output file
  • An xLights feature that can take the first sequence with a long audio track... and after playing the shortened sequence data in the first file goes on to process the sequence data in the second file -- continuing to play the audio in the first track the whole time...  then the third file's sequence, etc.
You are not allowed to view links. Register or Login  |  110K channels, 50K lights  |  Nutcracker, Falcon, DLA, HolidayCoro

Offline frankr

  • Sr. Member
  • ****
  • Posts: 347
    • Rocklin Lights
Re: Any work being done to 'stitch together' sequences?
« Reply #1 on: January 16, 2012, »
Hi Steve,

Alan and I stitched sequences together with a script.  Are approaches were different but the results were the same.

For me I broke the audio file into 30 second segments and sequenced them with LSP. Then I converted all of the sequences into xseq format and finally stitched them together with a python script that I wrote.  The script is pretty primitive but it can handle whatever lengths of sequences you throw at it and stitch them back together.  I thought I had published that code, or that Alan had but I could be wrong.

Frank

Offline Steve Gase

  • Sr. Member
  • ****
  • Posts: 2915
    • WinterLightShow in Georgetown, TX
Re: Any work being done to 'stitch together' sequences?
« Reply #2 on: January 16, 2012, »
I found the thread where it was discussed, and dpitts asked for a copy of the script.  But I did not find a place where the script was aactually shared.

You are not allowed to view links. Register or Login
You are not allowed to view links. Register or Login  |  110K channels, 50K lights  |  Nutcracker, Falcon, DLA, HolidayCoro

Offline dpitts

  • Restrictive
  • Sr. Member
  • *
  • Posts: 466
Re: Any work being done to 'stitch together' sequences?
« Reply #3 on: January 16, 2012, »
I am still interested in the script also.

You are not allowed to view links. Register or Login
I found the thread where it was discussed, and dpitts asked for a copy of the script.  But I did not find a place where the script was aactually shared.

You are not allowed to view links. Register or Login

Offline frankr

  • Sr. Member
  • ****
  • Posts: 347
    • Rocklin Lights
Re: Any work being done to 'stitch together' sequences?
« Reply #4 on: January 17, 2012, »
My apologies. still slowly recovering from my Christmas light hangover...

It is pretty simplistic right now as it is expecting the file names hard coded and you have to manual update the script to have the right audio file name.

Here is how the xseq file format works:

the first 512 bytes are a header that contains the following:
file type              (8bytes hard coded to 'xLights')
file version          (2bytes set to 1 Today)
number channels (8 bytes total number of channels in the sequence)
number periods   (8 bytes total number of periods, this is 20*num seconds in song Today)
Padding              (4 bytes)
Audio file name   (remaining bytes to 512 boundary)

After the header the file consists of 1 byte per period per channel.  so channel 1 starts at 512 bytes, if there are 1024 periods in the file then channel 2 starts at 1536, channel three at 2560, etc...

Notes on the script:
'\' is a special character in python and has be escaped in a string.  You will see where I build the audio file name:
    out.write(b'\x00\x00\x00\x00C:\\xLights\\emanuel.wav')
    out.write(b'\x00'*458)
how that works.  The second line of code is to pad out the 512 bytes to all 0 and the 458 must be adjusted to the proper value based on the length of the filename.

There are a lot of improvements I could make to this and I could even make a graphical front end to it.  I am willing to make these changes but would like to hear what Matt is working on so that we are not duplicating any efforts.

Good luck,

Frank