Does SetSoundQueing really work with PlaySoundSlave????

I've been banging my head against this one for a while so maybe someone can tell me how to approach this - if its possible at all.

I have a loop/beat mixing system built around the LoopSoundMaster and LoopSoundSlave commands. This I have working fine.

What I would like to add is a feature so that I can have longer melodic lines made of multiple sound files that will still slave to the master for sync. Right now with the 10 second limit at most tempos you can only have a four bar loop. Funky but gets repetitive.

So - I want the basic CD type function of playing successive files - but synced to the master prim . To do that I'm using SetSoundQueing and PlaySoundSlave. I can get the files to play in succession but cannot get it to Slave to the master. As soon as I tell it to start, it begins irrespective of the master position, and never achieves a sync.

All the sound files are quite precisely the same length.

The basic strategy is to:
Start file one and set a timer to half the length of the file.
call SetSoundQueing and then call the second file and set a timer for the regular file length.

The idea behind this approach is that the next call should happen around half way through the playing file and SetSoundQueueing should keep that call from interrupting the playing file, and with PlaySoundSlave used the next file should start with the next master iteration.

The basic problem I notice is that the first file may take a while to start so here's a question. If I call a sound file and then set a timer, does the script wait for the sound file to start playing before starting the timer?? I'm assuming that it doesn't and that the server considers the job done with the call to the client to play the sound, otherwise I could just set the timer to precisely the file length and forget SetSoundQueueing entirely.

I find myself in the usual position in regard to SL scripting.
Is it me and my understanding of the sometimes very minimal LSL documentation? or
Is it another function that hasn't been thoroughly debugged ?

- they've "FIXED" SetSoundQueueing a few times now - maybe one more time??

Last few times I tried it, it didn't work. but I've not checked for about 4 weeks now.

by the time you finished writing that you could have tested it and let us know


anywho, im not shure it was really broken or ever fixed, it just starts the DL process before its needed not to have it there and ready when you call for the sound on the next line....

so how long does it take the asset server to process the request, find the file, and actually transfer it to a random client with all kinds of differing internet speeds and loads?

how many grains of salt are in the ocean today?

" so how long does it take the asset server to process the request, find the file, and actually transfer it to a random client with all kinds of differing internet speeds and loads? "

how many grains of salt are in the ocean today?

That is the fundamental problem - which requires the timer function to be loose enough to accomodate the unknown initial delay. That plus the fact the queue is only one file deep. Any delays could cause files to be missed by a call over top of the previous.

In a sense I have been testing it for some time now by trying to get this function working. I just don't know if I've been testing it properly. If anyone can say it "It Works For Me" I'll start looking at my algorithm and script. It wouldn't be the first time. If not I'd best devote my time to get the Lindens to fix this.