Talk:LlSetSoundQueueing - Revision history

EddyFragment Robonaught at 12:49, 30 May 2009

2009-05-30T12:49:13Z

← Older revision		Revision as of 05:49, 30 May 2009
Line 9:		Line 9:
	: ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 12:04, 30 May 2009 (UTC)		: ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 12:04, 30 May 2009 (UTC)

	Mmm.Considered that but unless I understand you wrong I would (anyone would) still need to know the timing of the sound being played to avoid a slight skip. I put in a feature request for llPlaySoundLoop and although Soft Linden made some helpful suggestions along the same lines there is no better way than queueing I can find for any lengths of sound to match up perfectly. Until (if ever) LL grant what I asked for in ~~>jira<~~ I would love to find a cheat to get around this 2 sound nonsense. Things we know -- 1) if say 10 [[llPlaySound]]s are scripted in a block with a [[llSay]] to advise when the playsounds are done, the say will fire before the first sound is finished (if over a second or so). 2) [[llLoopSoundMaster]] etc knows when the sounds are on and off. From this I deduce that somewhere in the deep code the full details of the sound playing is known including the length. So all I need to do is trick the "viewer"? into filing the sounds in accordance with that knowledge. Since queueing seems to be the only way for the scripter to access that info without ever seeing it or knowing it in advance (if one uploaded it for example) I (have just realised I am going on a bit) wanna do that. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 12:43, 30 May 2009 (UTC)		Mmm. Considered that but unless I understand you wrong I would (anyone would) still need to know the timing of the sound being played to avoid a slight skip. I put in a feature request for llPlaySoundLoop and although Soft Linden made some helpful suggestions along the same lines there is no better way than queueing I can find for any lengths of sound to match up perfectly. Until (if ever) LL grant what I asked for in [[#SVC-4260\|SVC-4260]] I would love to find a cheat to get around this 2 sound nonsense. Things we know -- 1) If say 10 [[llPlaySound]]s are scripted in a block with a [[llSay]] to advise when the playsounds are done, the say will fire before the first sound is finished (if over a second or so)(and I know that of course only the last sound will actually play. The point is that the [[llPlaySound]] function is over faster than the sound is). 2) [[llLoopSoundMaster]] etc knows when the sounds are on and off. From this I deduce that somewhere in the deep code the full details of the sound playing is known including the length. So all I need to do is trick the "viewer"? into filing the sounds in accordance with that knowledge. Since queueing seems to be the only way for the scripter to access that info without ever seeing it or knowing it in advance (if one uploaded it for example) I (have just realised I am going on a bit) wanna do that. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 12:43, 30 May 2009 (UTC)

EddyFragment Robonaught at 12:43, 30 May 2009

2009-05-30T12:43:05Z

← Older revision		Revision as of 05:43, 30 May 2009
Line 8:		Line 8:

	: ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 12:04, 30 May 2009 (UTC)		: ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 12:04, 30 May 2009 (UTC)

			Mmm.Considered that but unless I understand you wrong I would (anyone would) still need to know the timing of the sound being played to avoid a slight skip. I put in a feature request for llPlaySoundLoop and although Soft Linden made some helpful suggestions along the same lines there is no better way than queueing I can find for any lengths of sound to match up perfectly. Until (if ever) LL grant what I asked for in >jira< I would love to find a cheat to get around this 2 sound nonsense. Things we know -- 1) if say 10 [[llPlaySound]]s are scripted in a block with a [[llSay]] to advise when the playsounds are done, the say will fire before the first sound is finished (if over a second or so). 2) [[llLoopSoundMaster]] etc knows when the sounds are on and off. From this I deduce that somewhere in the deep code the full details of the sound playing is known including the length. So all I need to do is trick the "viewer"? into filing the sounds in accordance with that knowledge. Since queueing seems to be the only way for the scripter to access that info without ever seeing it or knowing it in advance (if one uploaded it for example) I (have just realised I am going on a bit) wanna do that. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 12:43, 30 May 2009 (UTC)

Strife Onizuka: /* Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. */

2009-05-30T12:04:09Z

Calling Strife Onizuka... hehehe. I would assume you would be the first to find this.

← Older revision		Revision as of 05:04, 30 May 2009
Line 6:		Line 6:

	As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 01:49, 29 May 2009 (UTC)		As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 01:49, 29 May 2009 (UTC)

			: ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 12:04, 30 May 2009 (UTC)

EddyFragment Robonaught: /* Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. */

2009-05-30T08:05:17Z

Calling Strife Onizuka... hehehe. I would assume you would be the first to find this.

← Older revision		Revision as of 01:05, 30 May 2009
Line 5:		Line 5:
	== Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. ==		== Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. ==

	As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 01:49, 29 May 2009 (UTC)		As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 01:49, 29 May 2009 (UTC)

EddyFragment Robonaught: /* Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. */

2009-05-29T01:49:11Z

Calling Strife Onizuka... hehehe. I would assume you would be the first to find this.

← Older revision		Revision as of 18:49, 28 May 2009
Line 5:		Line 5:
	== Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. ==		== Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. ==

	As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill.		As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- '''[[User:EddyFragment Robonaught\|Eddy]]''' 01:49, 29 May 2009 (UTC)

EddyFragment Robonaught: /* Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. */ new section

2009-05-28T23:49:08Z

Calling Strife Onizuka... hehehe. I would assume you would be the first to find this.: new section

← Older revision		Revision as of 16:49, 28 May 2009
Line 2:		Line 2:

	:Cool, very good job. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 03:21, 16 May 2009 (UTC)		:Cool, very good job. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 03:21, 16 May 2009 (UTC)

			== Calling Strife Onizuka... hehehe. I would assume you would be the first to find this. ==

			As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. Can you think of any little trick that might work? I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill.

Strife Onizuka at 03:21, 16 May 2009

2009-05-16T03:21:06Z

← Older revision		Revision as of 20:21, 15 May 2009
Line 1:		Line 1:
	Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before replaces the original. The queueing state continues to exist unless it is expressly ordered to FALSE. Cool I liked the challenge. bring em on. lolz -- [[User:EddyFragment Robonaught\|Eddy]] 01:20, 16 May 2009 (UTC)		Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before replaces the original. The queueing state continues to exist unless it is expressly ordered to FALSE. Cool I liked the challenge. bring em on. lolz -- [[User:EddyFragment Robonaught\|Eddy]] 01:20, 16 May 2009 (UTC)

			:Cool, very good job. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 03:21, 16 May 2009 (UTC)

EddyFragment Robonaught: New page: Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before repl...

2009-05-16T01:20:57Z

New page: Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before repl...

New page

Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before replaces the original. The queueing state continues to exist unless it is expressly ordered to FALSE. Cool I liked the challenge. bring em on. lolz -- [[User:EddyFragment Robonaught|Eddy]] 01:20, 16 May 2009 (UTC)