Multi OGG support

[GoogleCodeExporter]

A previously suggested feature, but recently requested again here:
http://www.fretsonfire.net/forums/viewtopic.php?f=11&t=32725&start=915#p555591

Since the audio mixing code has been optimized a bit, it might not be too much 
of a computing bottleneck to mix in another OGG, since EOF already mixes in 4 
voices.  I think that overall, this could blend nicely with yet another 
previous feature request about a way to manage OGG profiles.  A dialog menu 
could be created to help the user track which OGG files have been loaded.  A 
checkbox for enabling the audio mixing for each OGG would be useful, along with 
the delay for each audio stream, and a button to delete the OGG profile.  
Caching of waveform data for each OGG would probably be desirable, and perhaps 
there could even be a feature to automatically associate an OGG profile with 
the selected instrument.  For example, if the user had separated audio (such as 
authoring for RBN), they could specify which audio plays when they have PART 
DRUMS selected, and the appropriate waveform is also displayed.

Original issue reported on code.google.com by raynebc on 28 Sep 2010 at 2:03

[GoogleCodeExporter]

Using logic implemented from issue 93, it would be a great addition if each OGG 
could have its own volume slider.

Combining multiple OGG support with the current OGG profile system may be a 
complicated further by the fact that each profile stores its own MIDI delay 
value.  If each OGG profile was presented with its MIDI delay, and the user 
selected to have one mixed in with the chart's primary audio (guitar.ogg), that 
OGG would have to be mixed in while taking its delay into account.

Implementing this feature would be much easier if the OGGs could have 
individual decoded samples returned, or decoded into a SAMPLE array, but that 
would take a lot of memory.  I don't immediately know how difficult this is 
going to be if the OGGs are stored in memory in their encoded format.

Original comment by raynebc on 28 Sep 2010 at 7:41

[GoogleCodeExporter]

After studying the OGG Vorbis API documentation and ALOGG's source code, I 
created a function in r435 (eof_read_next_pcm_sample) that should allow us to 
read OGG files one sample at a time.  If this works, we can have EOF play 
guitar.ogg normally, and the callback can just mix samples from other loaded 
OGG files on the fly.  The mixing logic should be the same as that of mixing 
the cue voices in, as the sample will be given by the Vorbis API as unsigned 16 
bit PCM data.

Original comment by raynebc on 4 Oct 2010 at 9:08

• Changed state: Started

[GoogleCodeExporter]

Remaining tasks for this enhancement:

1.  Elaborate the internal OGG profile tracking to ensure full file paths are 
stored, and a pointer to that audio's waveform data if it has been generated.

2.  Create a dialog window to display the available OGG profiles.  Since 
allowing the menu to be dynamic based on the number of profiles that exist for 
the chart would possibly be too complicated, only display one profile at a time 
and provide a left and right GUI item to activate to display the previous/next 
profile.  Provide the following for each profile:  A text box for displaying 
the OGG file's full path, a text box for displaying the shown profile's number 
out of how many profiles are defined, a text input box for displaying/editing 
the profile's MIDI delay, a button to click on for creating/destroying the 
waveform data for that OGG file, a button for deleting the OGG profile, a 
button for making the displayed OGG profile the active profile and a checkbox 
for enabling the OGG's audio to be mixed with the active OGG during playback.  
Deleting the profile should also delete the waveform data and make the 
previous/next profile the active OGG profile.  If the currently active profile 
is the only existing profile, it should not be allowed to be deleted.  The 
currently active OGG profile should have its waveform rendered, and possibly 
some information about the profiles can be placed in the information panel 
(such as the active profile's OGG name minus file path, and the profile # of # 
that is active).

3.  For each profile that has the audio mixing enabled, have the callback 
function mix the appropriate sample of each into the active OGG file's playback 
buffer.  This will require that each enabled profile's OGG is appropriately 
seeked with the playing OGG file at the start of and during playback.  
eof_read_next_pcm_sample() returns status codes, and upon success, the sample 
can be mixed.  Otherwise it can be ignored (ie. if the OGG file reached its end 
sooner than the active profile's OGG file).

4.  Update documentation.

Original comment by raynebc on 7 Oct 2010 at 9:19

[GoogleCodeExporter]

After some more thought, it might be best to allow the following options for 
selecting which waveform to display:

2a.  Manually specify which OGG profile's waveform to display
2b.  Display the active profile's waveform

It will also be more convenient for people to author using master tracks if EOF 
could associate an OGG profile with an instrument track and automatically 
change the active profile based on which profile was associated with the 
instrument that is active (ie. changing to PART DRUMS would load the profile 
that the user indicated applied to that instrument, such as if they loaded 
drums.ogg).

2c.  For each OGG profile in the dialog, have a radio button that would specify 
which instrument track it is associated with (or none).  When this instrument 
is changed to, this OGG profile and its audio will be activated.  When another 
instrument track is changed to, the manually-active OGG profile will be loaded 
as long as no other OGG profile is associated with that instrument.  No two OGG 
profiles can be simultaneously associated with the same instrument, although 
multiple can be set to "none".  It will be best to ensure that this will work 
when changing the active instrument during playback.

Original comment by raynebc on 7 Oct 2010 at 11:16

[GoogleCodeExporter]

eof_read_pcm_samples() is broken, and would need to be fixed as reading the 
next sample for each loaded audio track is a critical component of this 
enhancement.

Original comment by raynebc on 9 Jan 2011 at 10:11