Loosing time

[travailen]

I have been running my conductor for about 2 weeks with zero problems. I started with Vixen sequences from last year, I set the interval on my Vixen sequences to 50mS because I knew that was the conductor interval and imported them into LSP. I set the sequence interval in LSP to 50mS, added the RGB components using LSP and then I exported the sequences from LSP to seq files. I ran the 4 MP3 files through Audacity. My seq files are between 37 to 86 meg. My first 512 channels are for DMX single light control. Channels 520 to 4096 are RGB channels.

After getting much help from this group learing how to set up the conductor files I got my conductor running the 4 sequences. It has been smooth since then.  I no longer look out the window every few minutes to see if the show is still running.

Rick S

[RJ]

I have been running my conductor for about 2 weeks with zero problems. I started with Vixen sequences from last year, I set the interval on my Vixen sequences to 50mS because I knew that was the conductor interval and imported them into LSP. I set the sequence interval in LSP to 50mS, added the RGB components using LSP and then I exported the sequences from LSP to seq files. I ran the 4 MP3 files through Audacity. My seq files are between 37 to 86 meg. My first 512 channels are for DMX single light control. Channels 520 to 4096 are RGB channels.

After getting much help from this group learing how to set up the conductor files I got my conductor running the 4 sequences. It has been smooth since then.  I no longer look out the window every few minutes to see if the show is still running.

Rick S

The timing on a conductor is always 50ms. Is this part of the issue. are you ising odd timings other than 50ms and this is why we are seeing sync issues? just a thought, the convertors were suppost to handle this and give me the status at each 50ms but maybe there is an issue with this.


RJ

[dandyman]

Mine has been running perfectly since Dec 1... When I started the season... Running about 6000 channels... Pixelnet and LOR boxes running  DMX thru active hubs... Using LSP to sequence and output to conductor format...

[rdebolt]

I have been using my Conductor exclusively this year. I do get extra flickers now and then, but timing has been rock solid, I had many issues to begin with, but right now I seem to have a good process that works for me. For those having issues I would suggest trying another conversion to the .seq files. Early on I had some bad conversions that really messed things up. If using LSP try Franks "Light Elf" conversion. All others I would use Xlights. I sequence with LSP and have used both LSP conversion and Light Elf with good luck on both. Just my $.01 worth.

BTW I am pushing 15,000 channels this year. Need slave firmware to do much more! 

[lonewolf41]

I have been running my conductor for about 2 weeks with zero problems. I started with Vixen sequences from last year, I set the interval on my Vixen sequences to 50mS because I knew that was the conductor interval and imported them into LSP. I set the sequence interval in LSP to 50mS, added the RGB components using LSP and then I exported the sequences from LSP to seq files. I ran the 4 MP3 files through Audacity. My seq files are between 37 to 86 meg. My first 512 channels are for DMX single light control. Channels 520 to 4096 are RGB channels.

After getting much help from this group learing how to set up the conductor files I got my conductor running the 4 sequences. It has been smooth since then.  I no longer look out the window every few minutes to see if the show is still running.

Rick S

The timing on a conductor is always 50ms. Is this part of the issue. are you ising odd timings other than 50ms and this is why we are seeing sync issues? just a thought, the convertors were suppost to handle this and give me the status at each 50ms but maybe there is an issue with this.


RJ

I used xlights 2012d to convert my sequences.  They are originally done at 50ms timing.  Should have some time this week to try some different things to try and narrow down the issue.

Thanks,
-Keith

[johno123]

I'm using LSP 64 bit on win 7, with my conductor outside secured under a porch and in a waterproof container. 

5 out of my 7 songs sync perfectly, but two definitely drift.  I assumed all along that it was an LSP problem and the thought never crossed my mind that it could be the conductor.   All my music is 128kps 44.1 MP3's - and I haven't found any differences between the music that would cause the lag on some but not others.

-John

[twooly]

Have you tried directly from lsp to the etherdongle on those 2 songs to see if they do it there?

[einstein2883]

I am also seeing this drift on just Jingle Bell Rock.  It only drifts off by 0.5-1sec.  I sequenced in LOR and converted all them with xLights 2012b. Not sure if this help but here is my playlist of songs and the bit rates:
TSO-Wizards in Winter - 128k
Jingle Bell Rock - 192k
TSO-Sarajevo - 160k
Carol of the bells - 128k
I do also remember that I had to covert Jingle Bell Rock in Audacity from 282k to get LOR to read it in.

[duane.mosley]

i had a chance to mess with the conductor tonight. i have 6 songs this year and i have noticed that the songs that i built from scratch all play fine and spot on. i have 3 songs that were given to me to help me get started, they were originally LOR sequences that i converted to vixen. they play just fine when running the usb dongle or etherdongle off of my computer, but when running with conductor firmware threw the cf card, the  3 songs that i copied and pasted into my sequence, the music is behind on the sequence by at least 2 seconds. if the songs didn't play fine threw the usb dongle, i would think the song and sequence were off, but they play just fine.



duane

[Mickpat]

My conductor has been running for 4 weeks now without any issues. 

If you are using LSP, the audio files must be 44.1k.  Serveral LSP users have reported issues with loosing sync over time when other formats are used (LSP as the scheudler.)  When you export from LSP to conductor, you basically are "playing" the show to generate the effects at 50ms so timing could be effected by the audio file format.  My suggestion is to convert the file using Audacity and try 128kbps or 196kbps using 44.1k sampling rate and export the files again.

[jnealand]

This is not a conductor issue, but the topic comes up all the time.  I have one audio file that always sound fuzzy in my show.  If I bring it up in audacity, all I see is that it is 44100Hz and 32 bit float.  How do I tell what bps it has been recorded / saved at?  I have moved thru the menus and do not see anything that tells me this.  Not being a musician I don't even know what most of the options / terms mean.  i know I could save the file and specify the bps, but the question is how to tell what it currently is.  Thanks

[keitha43]

This is not a conductor issue, but the topic comes up all the time.  I have one audio file that always sound fuzzy in my show.  If I bring it up in audacity, all I see is that it is 44100Hz and 32 bit float.  How do I tell what bps it has been recorded / saved at?  I have moved thru the menus and do not see anything that tells me this.  Not being a musician I don't even know what most of the options / terms mean.  i know I could save the file and specify the bps, but the question is how to tell what it currently is.  Thanks

I just right click the audio file in windows explorer and just choose "media info". It tells you in that screen. I don't know how to see it in audacity but when you export the mp3 you can change the bps there.

[lonewolf41]

OK, I was able to do so trial and error now that the show is off.  I took two different sequences from my show and 3 different versions of the MP3's and mixed and matched them.  I also had two different versions of each sequence.  One that used a profile and one that has the profile flattened into the sequence.  Here is what I found.

One of my original MP3's was 192kbps, the other was 320kbps.  All versions of the .sho using these MP3's had the music way behind the lights by the end of the song.  One song was 3 minutes the other was 4 and the 4 minute song was off by around 1 second by the end of the sequence.  The 3 minute sequence was off between 3/4 to 1 second by the end.  I made 128 & 64kbps versions of the MP3's and ran those with the same .seq files from the previous run and the music and lights were still in sync by the end of the song.  So it appears that the bit rate of the MP3's was causing one of my issues.

The other issue that I had was when the 4 minute sequence ran, the light just flashed random colors.  The music played, but the lights were nothing like they should of been...they just flickered randomly.  Strangely enough, this only happened with one sequence; however, if I flattened the sequence before converting it, this issue went away. 

So as of right now, if I use a flattened sequence before converting and use 128kbps MP3's, I think I can get my conductor to work well enough to run a show.  I also found out what was going on with my one string that I discussed here:  You are not allowed to view links. Register or Login

[deweycooter]

I wonder if it has to do with differences in the MP3 encoding.  You might want to look to see if your problem MP3s have been encoded with You are not allowed to view links. Register or Login - this is basically a cheat that allows MP3 files to be smaller when less data is needed.  I know that I've heard of sequencing issues in the past using MP3s that use VBR. 

[RJ]

You want to run 128 - 192 mp3 non variable rate on the conductor. I thought we posted that somewhere but my memory is bad.

RJ