Any solution for playing multiple music tracks?
Monkey Forums/Monkey Programming/Any solution for playing multiple music tracks?
| ||
| I am looking to play samples (music) on several channels, so that I can add or remove "layers" of music in my app, so that the layers work together in sync? I know that monkey only internally supports playing one sample with PlayMusic(), but has anyone worked around this? Would the smart thing be to start playing the 2 layers of "music" as loopable audio at the same time and the mute the secondary layer when it is not used? Or do you guys and gals use any middleware or other mod to be able to play 2 or more music samples at the same time? Any ideas and suggestions are welcome. |
| ||
| I use PlaySound() to generate "on the fly"-styles with drums, bass and chords. The starts of the sound events is driven by a timer and it sounds quite synchron. The muting can be done by SetChannelVolume(). Listen to my app "Duett" on GooglePlay.... |
| ||
| @Midimaster : What kind of timer do you use? In my sequencer, I look at the events in my sequence, and if their "firetime" is equal to or less than current time from Millisecs(), I PlaySound() them. I Increment/Wrap the channel, I play to, each time I play an event. I update the sequencer in OnUpdate() I'm not always satisfied with the results and would like a tighter system, with less latenzy and more precise timing than the ( at best) 16 ms. resolution I get from this system. |
| ||
| In my sequencer, I look at the events in my sequence, and if their "firetime" is equal to or less than current time from Millisecs(), I PlaySound() them. I Increment/Wrap the channel, I play to, each time I play an event. This might be unnecessary, but; I would get Millisecs() value into a global variable at the start of the loop. Just in case the loop-time on some machines is bigger, calling Millisecs() every time you need to know the time, it might already be incremented(? or is it?). Well, anyway, I think the variable would bring more precision - at least it feels like it. |
| ||
| I get Millisecs() only once in my main loop :-) JMTRACKR http://www.monkey-x.com/Community/posts.php?topic=4820 , looks at first glance as if it uses the same approach. ( fire on updatetime>firetime) Modplay seems good: http://www.monkey-x.com/Community/posts.php?topic=8430 Good timing is doable in Webaoudio: http://www.html5rocks.com/en/tutorials/audio/scheduling/ http://chromium.googlecode.com/svn/trunk/samples/audio/shiny-drum-machine.html [EDIT]: Another rocksolid Webaudio example : http://chimera.labs.oreilly.com/books/1234000001552/ch02.html#s02_3 It would be great to have in iOS and android, but as far as I can tell OpenAL does not support scheduled playback. |
| ||
| I do it like user "Difference": I use Millisecs() and compare it with the "time stamp" of the next event. With a 60Hz UpdaterRate your latency is less than 16msec. This is exact enough for music. In a 120bpm song the quarter note is 500msec. So an 1/16-note would be 125msec, a 1/16 triplet would be 83msec. This are still roundabout five 16msec-ticks So, if you hear latencys, they are propably caused by other reasons then by the UpdateRate(). |
   |