yes, i meant in the designer. however, if i’m using quietest for events, which use parameter velocity and parameter control from code (which also affects volume), the events keep stealing sounds from each other, which results in audio corruption.
you should set priorities on events if you dont want them to steal each other.
What do you mean ‘corruption?’ the steal mode is nothing to do with events stealing from each other, it is only for the instances of that particular event, to do with ‘max playbacks’ for that event.
Event A and Event B do not touch each other in regards to those modes.
i was talking about same type of event and its instances. for example, i have two rolling balls on a hill, where both balls try to (and repeat to) spawn one instance of (same) event. and since event has an event limit of one, only one event will be playing (a loopable sound definition).
now, if i use a parameter (with parameter velocity!) which controls volume of this event, it causes for the instance to steal handles from each other. this probably happens because i update the parameter position on different time intervals (basically pushing it back, while velocity is driving it forward – this forces an event to fade out, after i stop updating the parameter). during this period the event which is further away, probably calculates that it’s volume is higher than the event’s which is closer, and steals the handle and start playing it. the parameter velocity kicks in, driving it forward and reducing the volume.
in a rather short period the first event, finds out that his new parameter value (forced from code) will cause the event to be louder, and steals is back, etc…
if volume was fixed, this probably would not happen, but volume has to change, so…
we had a distance based sound stealing system in our previous sound implementation (based on miles sound system) and it turned out to work quite nice (with right instance limits, that is), allthough it may "look a bit strange/unnatural" at first…
Please login first to submit.