Start Position Time On PlaySheduled

Unity Engine
, , ,
1

Hi everyone, Mine is a recommendation for AudioSource class. I think it would be useful to have a “StartPositionTimeOnPlaySheduled” independent of the audioSource.time so that a jump can be scheduled in the same audioSource when the PlaySheduled time indicates it, being able to continue playing the audioSource until that jump and not having to use another audioSource to make that jump. When the jump is made, the audioSource.time would take the value of “StartPositionTimeOnPlaySheduled”. I hope I have been clear. Thank you very much.

2

I’m not sure I understand why you would need a second AudioSource. Could you give a example?

Also, if you set AudioSource.time and then setup a .PlayOnSchedule, doesn’t it start playing at the position specified earlier?

3

Hi SevenString!,
Thanks for your reply.
In particular, I’m developing a tool to play different regions of a clip, each time a region ends it chooses another one at random and changes the position.
Something like this,

public AudioClip audioClip;
public PAudioClipRegionClass[] regions;
public AudioSource audioSource;
public int regId;

void Start () {
	
	audioSource = GetComponent<AudioSource>();
	audioSource.clip = audioClip;
	regId = Random.Range(0, regions.Length);
	audioSource.time = regions[regId].start;
	audioSource.Play();
	
}


void Update() {

	if(audioSource.time >= regions[regId].end) {
		regId = Random.Range(0, regions.Length);
		audioSource.time = regions[regId].start;
	}
}

In most cases there is no problem but when you have to be very specific with different parts of music (for example) or engine simulation it is not so exact and generates cracks and clicks. I have noticed that in the Update when it reaches the end of the region the audioSource.time is not exact in the value but is a little later.
After trying several solutions I decided to implement the PlayScheduled and the ScriptAPI example uses 2 audioSource between event and event (region and region).

I tried it and it works but I think we could save all that process and memory by simply adding a variable that tells the PlayScheduled where to start while the audioSource.time is changing because it is running.
That is why my recommendation if it is possible, maybe internally it is not possible.

4

I believe your workaround is probably the best thing to do considering the audio backend and API, good job!

I see your point now, and I believe that would relate to an elaborate marker/loop-point system. This is very very specific, and to be really honest, I don’t see that being developed any time soon.

But I still think you should elaborate on how you see this, mock an API maybe and post it here! :slight_smile:

1 Like
5

Thanks for your reply!
Best regards!