LSP and Conductor timings

[peteandvanessa]

So I've been doing some testing with the conductor and LSP exports.

I'm running the latest version of LSP and have been exporting my sequences to the latest Conductor firmware that also uses the OGG music format.

During everything was rock solid from a timing perspective (having had a lot of Light lag last year using the LSP scheduler)

I have  a lot of singers for my Halloween sequences, and I spend a lot of time making the mouth sync exactly to the music. But during testing today I noticed that the singer was very slightly late with his singing. So I remembered that LSP has a function to increase or delay the timing of every timing mark to get it all back in time. So I opened the sequence, and if you right click in the timing grid and select interval toolbox and select shift sequence intervals, you can select to delay the timings, or make them earlier in  0.05 sec increments. I adjusted mine to 150 milliseconds earlier and then re-exported the sequence to conductor.

Now when the sequence plays back in the conductor, the singers are precisely in time now with the music.

Just wanted to pass this on if anyone else is planning to export to conductor format in LSP and sees the timing shift.

[keitha43]

I haven't had to shift mine but I had the recommended mp3 settings before converting to ogg.

[peteandvanessa]

I haven't had to shift mine but I had the recommended mp3 settings before converting to ogg.

I also used the correct mp3 settings in LSP. I used the mp3 file with the correct settings in LSP for the sequencing part, then I export the file to conductor. I then copy the exported sequence to the Conductor and I then take the original mp3 file, and use Audacity to convert it to OGG format and then copy the exported OGG file over to the Conductor flash card. It's then where I get the lights being about 150milli seconds (it's always a little late).

I then have to go back into LSP and adjust the timing by 150 milliseconds earlier and re-export from LSP to Conductor format to get it to line up again.

I wonder whether it's a timing difference between the MP3 and OGG format that cause the timing issue. I might try to pull the OGG audio file into LSP and see it that makes a difference.

[keitha43]

Interesting. We are using the same procedure but I have no shifting of 150ms. I wonder if your little audio board in the conductor has an issue? Anyway it sounds like you have a workaround. I never noticed before but LSP does work with Ogg as well as mp3. I may just sequence with that instead of mp3 on my next sequence.

[twooly]

Are the correct settings in lsp 128k constant stereo 16 bit?

[peteandvanessa]

Are the correct settings in lsp 128k constant stereo 16 bit?

That is correct, it's set for 128K constant, stereo and 16 bit.

The 150 millisecond delay is consistent with all the sequences, every one has a linear delay. I worked around it by just shifting all the timing marks to "fire" 150 milliseconds earlier. I see the delay on my singers, which are attached to two Lynx controllers which are connected to a 16 Port Active Hub via the DMX Out from the Hub.
Now the Smart Strings MIGHT also show a delay (haven't looked at them closely yet), but with the singers, it is obvious there is a slight delay (it's like a singer who is lip synching slightly late).

As far as I'm aware, there's no issue with the Audio (I have the little audio add on PCB fix, since it's going to a radio transmitter that some had issues with), unless the Audio transmitter introduced the 150 millisecond delay, I might try pulling the radio transmitter out tonight.

The other thing I'll try is loading up the OGG file into LSP and see if it re-aligns the audio with the singers.

Like I say, I can work around it by just doing a 150ms shift in the timings but I'd like to understand whether its the OGG file compared to the MP3 audio file, or something else.

[RJ]

We have not seen this type of timing issues since the change to OGG. The file format would not create an issue since the timing marks are in an OGG file and are down to 1 ms. So I wonder if when seqening the software is lagging so when you set the mark it look to match in the software but when played back with out the delay you see this?

We had a number of beta testers and no one had run across it so I will curious to see what you find.

RJ

[keitha43]

Are the correct settings in lsp 128k constant stereo 16 bit?

And rate of 44100hz

[peteandvanessa]

We have not seen this type of timing issues since the change to OGG. The file format would not create an issue since the timing marks are in an OGG file and are down to 1 ms. So I wonder if when seqening the software is lagging so when you set the mark it look to match in the software but when played back with out the delay you see this?

We had a number of beta testers and no one had run across it so I will curious to see what you find.

RJ

If I use the MP3 file in the correct LSP format (and at Project rate of 44100Hz), the timing is perfect in the LSP visualizer screen (both in the main visualizer screen and also in the small visualizer on the left hand channels, the smaller channel visualizer tends to be the most accurate when sequencing). If I remember correctly, when I outputted to the lights in LSP in the Sequencing S/W using the Etherdongle Firmware, all worked correctly, no timing issues or delays at all.

Then if I flashed the firmware with the latest Conductor file and then exported from LSP to conductor, and switch to the converted MP3 to OGG format, then I see the slight delay (150 miliseconds), the commands are always just a little late on the DMX channels from the Lynx Expresses (I'm running two expresses, which control three singers, each singer has six channels for the eye, and mouth movements, plus a few others for Spotlights and strobes)

I have the Lynx Expresses wired up correctly (with the correct terminate jumpers, DMX addresses etc). I'm going to try and bring in the Audio file into LSP in OGG format, and then look at the Visualizer again, to see if it changes the timing in LSP.

After doing that, I'll export to conductor format using the timings set for the OGG audio file and see if anything changes timing wise.

On the RGB light strings connected to the 16 port active hub, I haven't looked at these really closely, since 150mS delay would be easily noticible. But on the singers it is, because if they are out slightly you can see it easily.

I'll run some tests later today and report back here on what I find.

[peteandvanessa]

So I did some further testing.

Firstly, I opened up the original file that was about 150mS out of time and swapped out the MP3 file for the OGG Music file.

I let LPS do it stuff bringing in the audio. Then I looked at the timing grid after the swap (note LSP won't change the timings I laid down in the MP3 version of the sequence, I was only interested if the OGG file moved relative to the timing marks)

The timing marks at the begining of the sequence, did not change, so I scrolled to the end of the sequence and the timing marks relative to the new audio file did not change either (see screen captures below).

One pic is the Sequence with the MP3 audio, the other is the same sequence just with OGG audio replace.

But see the very slightly longer audio length in the OGG version.

Anyway, I also checked the sequence playback of the OGG version, and the timing was exactly the same as the MP3 version, but audio scrubbing doesn't work well with the OGG version (so it seems that LSP doesn't like OGG audio files).

Then I exported the OGG version of the sequence to conductor format and tested the sequence, it plays back fine, but has the same delay on the singers of about 150mS. So I'm back to the solution of shifting the timings manually in LSP to get it back to the right timing.

I'll have to do even more digging.

[peteandvanessa]

I captured the timing on a couple of video clips.

This first video clip is a direct export to conductor format with no adjustments in timing:
You are not allowed to view links. Register or Login

The second clip below is where I adjusted the timing and made the commands start 150mS earlier (look closely at the mouth of the second singer on the far left hand side)
You are not allowed to view links. Register or Login

[keitha43]

One difference I noticed is you are using the 64 bit and I am using 32 bit. Don't know if it makes a difference but I have seen more complaints about the 64 bit version for other issues. However I did not test with my Halloween face as it is buried behind most of my Christmas display and is too large to bring inside my house. I tested with some strands from my pixel megatree and a few led strands from a LOR unit running DMX mode. I did notice it was hard to tell from your white lights in the background that there was a delay. If this shows up for me next Halloween I will do your workaround.

[peteandvanessa]

Yeah, I'm running the 64 bit version. For the most part LSP is working well this year, had a hard time with the scheduler last year, and hence why I'm testing really early with the conductor this year.

Yeah, it is a little hard to see the delay, but if I turn everything off apart from the singers, it becomes more obvious. Most folks who come to see the lights, won't be able to tell, but having worked hard to get the timing just right, I can see it for sure.

[peteandvanessa]

So I did some further testing today, since I assumed that all my sequences needed to be time shifted by about 150mS.

Well it turns out, that some sequences do not need to be time shifted and can be left at the default timings from the Export from LSP, and others will need to be time shifted so that the commands come on earlier.

So I'm a bit stumped. I also looked at the complexity of the sequence (in terms of file size) and I have two relatively simple sequences, one needs to be re-timed to line up with the singer and the other sequence does not.

Both sequences are about 4Meg in size. I want to try and nail down what the issue is, since I'm sure folks who do Halloween singers are going to see this.

I've always got the workaround, but I'm confused at what is causing this.

[rrowan]

Can you recreate the delay issue with a brand new seq using the mp3 or ogg file?

Is there any LSP configuration difference between the seq that has a delay issue and the ones that don't?

Just throwing out some ideas for the needle in the haystack

Rick R.