How to sequence sounds?

Consider:

llPlaySound("sound1", 1);
llSetSoundQueueing(TRUE);
llLoopSound("sound2",1);

For some reason this loops sound1 only. Anyone know why?
How shuld one code to get sound1 to play once, followe by sound2 continuously looping?

FC

This script seems to work normally for me... when touched, it plays the first sound, then loops the second sound continuously until it's touched again.

default
{
    state_entry()
    {
        llStopSound() ;
    }

    touch_start(integer total_number)
    {
        state noisy ;
    }
}

state noisy
{
    state_entry()
    {
        llSetSoundQueueing( TRUE ) ;
        llPlaySound( "sound1", 1.0 ) ;
        llLoopSound( "sound2", 1.0 ) ;
    }
    
    touch_start( integer num )
    {
        state default ;
    }
}

You might want to add a delay after playing the first sound, equal to the length of the first sound. Sound scripts seem to like that better, sometimes.

Many thanks, this script does the job! Though why it takes state switching to make this work is beyond my understanding.

Also the LSL Wiki page on llSetSoundQueueing implys that this command should follow llPlaySound or llLoopSound as it deals with the 'current playing sound'. i.e. you must have the first sound playing before you can invoke the queueing.
It appears this is not the case.

FC.

Well, the state-switching was just a convenient way for me to turn the test-object on and off, so I wouldn't drive the people around me insane with looping sounds. I have no idea if it makes any difference in terms of the soundplaying itself.

My understanding of llSetSoundQueueing() was that it just sets a flag for the script, whether it is supposed to queue sounds, or not, so I always just put it before any sound functions. I have no idea if I'm right, or not.

The script posted 3 messages back does not work correctly today. It mostly only plays the loop sound. About 1 click out of 20 it will correctly play the first sound, then the loop. There have been a couple of updates of SL in this period, maybe llSetSoundQueueing is even more broken now.
The timer comment gave me an idea. What DOES work reliably is to start the first sound and also set a timer running. In the timer event, when the play length for the first sound is about to run out then start the second sound looping. There is a small hiccup at the start of the second sound, but the sequencing has been 100% reliable so far.

Tomorrow never knows...

I just recently read someplace, probably the wiki, that llSetSoundQueueing has some odd quirks, one of which is the soundlooping problem that you were experiencing. Introducing the manual delay using a timer is an accepted work around.

Could someone please post some example code? This might solve a problem I'm wrestling with. Thanks.

I think this was what Cross was getting at about the sleeping between playbacks.

llSetSoundQueueing( TRUE ) ;
llPlaySound( "sound1", 1.0 ) ;
llSleep( Length_of_sound1 );
llLoopSound( "sound2", 1.0 ) ; 

It might be necessary to tweak Length_of_sound1 a bit.

It'd be interesting if Sound Queueing supported more than a single sample in the queue; it would allow sufficient buffer to perhaps counteract the streaming nature of playback commands. Another useful command might be llGetSoundLength(key Sound). Heheh, and as long as we're dreaming, llLocalSoundEngine([], []) with its own sequencer and software synth.