Quantized MetaSoundSource starts with volume dropout

In my continuing quest to convert my music theme manager over to MetaSounds, I’ve had an unusual glitch when using a Quartz quantized MetaSoundSource, meter is perfect, but there is a brief dropout of audio at the start of each new track. The song stays perfectly in beat and tempo, but the first part of the MetaSoundSource playing the wav sort of quickly fades in. You miss most of the first part of the first beat. It’s minor but it’s enough to ruin the feeling of the song.

The way I set it up, is identical to the old way of using Quartz in Blueprint and then calling the MetaSoundSource re-usably rather than the former Create Sound 2D call. The Queue is called each time a track hits its last measure and beat based on quantization events.

In the screen shot of my BP, I have a UseMetasound boolean which if set true, plays through the MS and I hear the drop in gain at the first beat of every new track queued. If set false using the old way, I don’t hear that audio drop out. Neither path suffers from a timing glitch. The BP shot is my Queueing routine for Quartz copied mostly from the training video on Quartz. I’ve also included my MetaSoundSource which is extremely basic. All it does is feed inputs and respond to triggers. To my surprise Play Quantize seems to trigger the On Play in the MS, but when the On Play occurs there is no sound until about a 1/16 note into the track.

Any ideas what would cause this drop out? Ideally, there is something in what I’m doing that is stupid and can be fixed. Any ideas?


It obviously always depends on what you’re trying to achieve but I find it easier to control playback directly from the Metasound source and instead use the BPs to send trigger msgs e.g., start/stop, bpm changes (floats/ints) ]. As I understand the Quarz system is underlying so no need to access
it outside of the Metasound graph. Here’s an example of how the Metasound can be set up.

What I’m trying to accomplished is fairly traditional, play a specific composition made of many composed tracks designed for a specific character and level which can play sequentially but may mellow or intensify based on game events. The tracks need quantization based on a table of data on how song parts can fit together. One has to know if they are on beat 4 (in 4/4) before introducing beat 1 of the next triggered track. That’s what quartz was providing for this method as it used to.

From a musical standpoint, an example of the application is that sometimes an 8 bar segment will be played in its entirety triggering the next 8 bar segment. But at any time based on game events (e.g. going into combat), the song has to be interrupted in meter to begin a different intensity version without waiting for completion of the entire 8 bars. My attempt at Metasounds-only didn’t like the mixing of the two concepts.

My first approach (to use only metasounds) defeated me after several days of trying to get measure / bar for interruption of a playing track at a logical musical point in the song. The timing variables of the internal metronome (based on time divisions of wave duration and bpm in fractions of seconds) I set up, were considered a loop if they had were used to trigger the Stop and Onplay, since under other circumstances the finishing of one wave would trigger the beginning of the next in cases where no event occurred. Because of the inability to use a mixture of variables to trigger, and/or termination of a track in other cases, this produces the metasound definition of looping and isn’t allowed. To rephrase, maintaining variables to keep track of where I was in the song, meant those variables could not be used in controlling termination of the track prematurely nor starting another track. That’s what Quartz does so easily, thus I punted and attempted this current more traditional approach though avoiding deprecated nodes.

Perhaps the video has the solutions to the problems I ran into. If it has the ability to stop playback of one clip prematurely on a measure boundary, then maybe there is an approach I’ve missed so far when attempting exclusively metasounds. I’ll check it out.

As to the gain glitch, is there an implication that attempting to control the metasoundsource from external BP will introduce audio glitches?

I will have to map your graph out to study it. It moves too quickly in the video to see what is going on (I’m slow). I do hear the results as it plays though. Possibly there is a solution there.

Yea man but no… just download from here

I appreciate the alternative approach, as that is what I was trying to do originally. The difference here is that you use a counter that has no dependency on the wav running to completion. I was resetting my measure/beat count based on a trigger coming from OnFinished. and that creates a dependency that doesn’t allow any hookup to the start or stop of the wave player (creates a loop).

The question is actually about whether a metasound can be controlled by an external BP using quartz without introducing the gain anomaly I came up with. But your answer speaks to what I was trying to do initially which logically seemed like the more correct approach (and should be possible). I will rethink that again from a standpoint of keeping a measure count completely isolated from the normal termination of the wave so a trigger delay can connect to the various starts and stops of the wave players. This would allow early termination of a cut without randomly starting the next on the wrong beat (or worse). That might be a way to do a metasound only solution.

Thanks

What I like about Metasound is that there’s no one way you have to set it up so it only depends on your game situation. But to me, the main advantage is that I can leave BPs to just send player triggers and RTPCs and all sync aspects can be controlled in the MS graph. I just used counters here but you could also use end of loop, finished, cuepoint, time (sec,ms), audio trig (via env follower), there are lots of possibilities. I also don’t have to think about a second BP controller – which also allows me to test many things without jumping into game play and I can keep the printouts in one place. It’s pretty easy to setup up various gates so I can have a player trigger a music event but have the music wait in the MS for the next beat to occur, or playout and trigger on end. Also as I understand it Quartz is underlying so there’s no need to control it from the BP as MS is always running in sync. But again, it all depends on your specific needs.

The difficulty with terminating a playing track early was determining the delay trigger value to terminate at just the right point without having coupling to the wave player or external wave player control inputs. I could not use the external inputs or outputs of the wave in determining that because it would create a loop. It may be that having the “metronome” (your code uses one with the BPM to Seconds, Trigger Repeat, and Trigger Sequence) be the only thing started by an external trigger input and it in turn triggers all plays and stops, thus avoiding loop detection. I had not done that, and my calculation to trigger the delayed trigger for stopping the playing wave at a specific time interval, could not be connected due to the loop detection. This is because my OnPlay was starting my Trigger Repeat. The delay trigger would, as an example, press stop on the idle theme, and start the combat intro. These could not be connected as long as the “metronome” was started by the initial OnPlay. I will try it without Play being started externally and see if it avoids the loop issue. In other words, the higher level program never triggers the play, it only triggers “metronome” start (and of course gain), then toggles InCombat on and off, letting the “metronome” do the dirty work. That’s what I’m going to try.