Hi, we recently changed from Designer to Studio and with that came some redoing. Got stuck on one thing.
I’m trying to playback a sound that got a start, loop and an end segment.
The waveforms are tweaked to be seamless down to the sample, and since the waveform is quite basic (it’s a carhorn) they can’t overlap without getting loud artifacts.
It works just fine in Designer, the loop and end sounds start mode are set to wait for previous and the loops loop mode is set to loop and play to end (the loop is very very short).
But I can’t find this (and plenty of other) functionality in Studio anywhere, any ideas?
There are a number of ways to do what you want in Studio; Exactly which one would be best for you depends on the precise requirements of your event. Assuming the most basic possible case, the simplest thing for you to do would be to add each of your examples to the timeline of an event as time-locked single sound modules, then create a loop region around the loop section and give that loop region a trigger logic condition that you can disable when you want to move on to the end section.
Yes, that plays everything in order but with loud pops. Kinda like using a sustain point.
[attachment=0]horn.jpg[/attachment]
As I said the sound modules needs to finish before the next one starts to play, and the following sound file needs to start right on the sample after the one before has finished, just as the loop and play to end and wait for previous functions combined did in Designer.
You should not be using a sustain point, and the middle sound module should not be set to looping. Instead, it should be a timelocked single sound module with a loop region, as I originally said. The looping behaviour should come from, and only from, the loop region; This will ensure that the sound plays to end each loop so long as the module is at its default length and not set to loop mode. Setting the module to loop mode causes it to become non-timelocked and removes the play-to-end behaviour, neither of which are things you want.
Pops should not be happening. What format are the samples you are using?
Yea, the module in the middle where set to looping, that solved it and I used the “move to”-function to set the sound modules to the exact correct location. PCM 44.1 kHz, the pops occurred because the waveforms didn’t align with the loops start and end, but now they do.
One problem though, I have another track in the same event that works in the exact same way but when outside of the vehicle, and I’m using a parameter to crossfade between inside and outside. The problem is that the outside loop is a bit shorter so it needs its own loop region, but that overrides the loop region of the inside loop. A solution for that would be to use more than one parameter as trigger logic, but I can’t find a way to do that.
I work around it for now by using separate events for inside and outside, but I’d rather have them in the same event, is that possible?
Cross-fading between similar structures with different loop lengths? Hmm… The solution that’s easiest to implement at the moment uses referenced events.
Construct each start-loop-end section as its own event, with its own loop region and controlling parameter - just like the one you’ve already made. However, give the parameters identical names. Then, create a third event, and add the existing two events to it as event reference sound modules, each on its own audio track such they they will play simultaneously. To this third event, add a parameter with exactly the same name as the parameters in the referenced events, and voilà: The parameters in the two referenced events will be controlled by the parameter of the parent, meaning that if you change the third event’s parameter, the condition logic of the referenced events will be triggered. All you need to do then is set up automation to crossfade between the two audio tracks of the third event, and you’re done.
Admittedly, because of the different loop lengths, you will experience a slight oddity if you crossfade from one to the other when you’ve triggered the play-out-and-end behaviour, but synchronisation problems are almost always going to be present with this kind of loop length mismatch.