Hackathon Proposal:Addon specific Sound Queues

This article is a stub. You can help the wiki by expanding it.

Title:	[[File: |thumbnail|]]
Potential mentors:	Erik (sound I/O), Florent (addon framework)
Intro:	provide addon specific sound queues that can be individually toggled on/off (muted) and controlled (volume) for troubleshooting purposes, the lookup path (file handling) could be defaulted to the addon's directory - the global fgcommand would be overloaded/shadowed by an addon-specific API call
Interested Parties:	please add yourself if you are interested in working on this
Status:	RFC
Summary:	The idea is to have one queue per add-on, and an addons.Addon method that would implicitly use the add-on specific queue. This would allow users to mute a specific add-on using /sim/sound/queue_name/enabled (one could also have some generic setting of a per-queue “gain” factor using similar properties?). However, there is for now only one 'instant' queue.
Background:	the "instant" queue sounds like an excellent idea - however, another solution might be to simply overload the corresponding play-audio API in Nasal space, so that each addon uses an overloaded API, that uses the addon's name as the default name for the queue - i.e. addons, should not be using the lowest level fgcommand, but could have their own "playAudioSample()" API in Nasal space, which uses the global fgcommand, with the addon's name as the internal default queue - custom queues, could then be using something along the lines of "addonName.subqueue". Basically, addon's would default to an addon-specific queue, and get their own API for playing sounds that way (Florent worked out most of the existing Addon API, so he knows what I am talking about here
Details:	the idea is to simply overload/provide a dedicated "playSound" API for addons, that would internally use the existing API - that way, all addons would be using their own name as the "namespace" for the corresponding "instant" queue. This does not need any C++ code - this can be done in Nasal space (again, Florent worked out the current addon API several years ago - so I suppose Florent is in a better position to judge if it's worth adding this or not) Speaking in general, I think it would be a worthwhile addition - as it would also allow us to provide addon-specific configuration options for sound, e.g. volume control - at the mere cost, of implicitly providing only an API that provides the equivalent of an "instant" queue whose name is "addon.FooBar" That would also allow people to mute addons etc The corresponding GUI could be Nasal/Canvas based, and would merely to go through all addons (for which we have an API) and provide volume/mute options for each.
Ideas:	The question is, would it be it easy to, and do we want to extend this so that, e.g., any queue whose name is "instant" or starts with "instant-" works in the same way? The idea is that the "enable" property would still work for such queues (I'm not sure I've tested setting it to 0 for "instant"). If this is implemented, Florent could add a playAudioSample() method to the addons.Addon ghost that would by default use the "instant-⟨addon ID⟩" queue. (For convenience, the method could also have a default path prefix which is the add-on base path.)
Required skills:	Property tree, PropertyList XML File, Nasal, Listeners
Learning Opportunities:
Notes:

References