|
Seven Shikami
Registered User
Join date: 22 Sep 2006
Posts: 82
|
11-23-2006 10:34
I'm trying to make a DJ mixing table. The theory is sound but the implementation is screwy...
The main table plays a drumbeat using llLoopSoundMaster. Then, the secondary table plays the melody lines, which are the exact same length as the drumlines down to the byte, using llLoopSoundSlave. Touching a table will issue a new loop, which, thanks to llSetSoundQueueing, won't file until the current one is finished.
It works... but when I go to change either of them, they fall out of sync after 2-3 changes. Basically SL is inserting minute pauses between the new playbacks.
If I set it up so the beat goes through an independent beatbox and the melody is done on TWO turntables, and I manually alternate back and forth between them, it's seamless... because it's spread across two prims, there's no gap to speak of, it plays on time even if it overlaps a tiny amount. But that means I have to babysit the thing and pick "Okay, sample 1, table 1. Now sample 1, table 2. Now sample 1, table 1..." back and forth.
I tried setting up a timer to automate this 'back and forth' but the result was hideous, with samples playing over themselvs, etc. My timer might've just been screwy, but.
What's the best way to achieve this effect..?
|
|
Raeyan Aldrich
Registered User
Join date: 14 Oct 2006
Posts: 44
|
11-23-2006 22:52
/54/05/147356/1.htmlthis was a script i made for someone real fast a few weeks ago... it should give you a rough outline of how to do it smoothly.
|
|
Seven Shikami
Registered User
Join date: 22 Sep 2006
Posts: 82
|
11-24-2006 06:09
Unfortunately, that's trying to get ONE channel to loop properly. I'm trying to get one channel, using MasterLoop, to sync with another channel using SlaveLoop. It works... once. If the second channel replaces its loop it falls out of sync (which makes no sense given the whole point of using slave loops is that it DOESN'T fall out of sync).
I could trim off 0.1s as suggesed, but then it'd REALLY go out of sync...
|
|
Raeyan Aldrich
Registered User
Join date: 14 Oct 2006
Posts: 44
|
11-24-2006 16:59
yes i was providing that link more for reference... you see how i had it queue the next sound prior to stopping the current one... try doing that and then having them re-sync that way once you start a new loop. just to elaborate a little... u have 2 buttons on the table, we'll call the objects drumloop1 and melody1 lets assume that the sound actually comes from the button when pressed. simply add a command to the link message event to "listen" for a sync command. when this is heard the button calls llStopSound() after re-queuing the current sound it is playing. simply make a re-sync button for your table that sends llMessageLinked() with the sync command. when this is pressed it will be heard by all the buttons and they will respond by calling their sound command again then calling stopsound which should cause every sound in the table to re-sync with all the others... obviously this button would need to be pressed at the end of a loop to sound as smooth as possible... but if a DJ cant click a button in sync with music... well... then he or she shouldnt quit their day job  im sure with a little playing around and creativity you can figure it out  if not feel free to talk to me in-world or on here... i may have some scripts laying around that could be of use
|
|
Seven Shikami
Registered User
Join date: 22 Sep 2006
Posts: 82
|
11-24-2006 20:55
Yeah, a pushbutton to issue a Stop and Restart would do it... but would leave an audible gap, especially if the DJ doesn't time the new set of loops right -- or if the sim is lagging, and the response is slow.
Ideally, I'd like the Dj to be able to pick what the NEXT loop will be on either channel at any time, and have them stay synced without needing precisely timed human intervention. Which, from the description of slave/master sounds, is what should be happening... why slave-loops are not in fact slaving properly to the master doesn't make sense.
I've found it works fine... if the DJ has to manually fire the slave every single time, if slave-loop is not used but slave-play is, over and over, across two different objects. But that's even worse than manually restarting the loops...
|