Структура SoundManager

[TanaTiX]

Есть необходимость написать SoundManager. То, какой в нем будет функционал, - дело 10е. Интересует именно воспроизведение звуков, точнее как дать понять менеджеру какой звук воспроизводить. Потенциально предполагается, что звуки будут подтягиваться из библиотеки (хотя даже если это будут внешние - не думаю, что это на что-то принципиально повлияет)
Собственно вопрос в том, как наиболее грамотно с точки зрения определять проигрываемый(ые) звуки? В НЕТе достаточно много вариантов, когда классу передается в качестве параметра строка, соответствующая тому или иному звуку, но у меня что-то закладываются подозрения, что это не совсем правильный подход. Хотелось бы услышать у кого какие соображения на тему организации воспроизведения звуков. Заранее спасибо.

[cleptoman]

ну, если юзать Dictionary в качестве хранилища, то можно и не только строку.
а вообще: трудно что-либо советовать, когда не понятна задача

[-De-]

Строка - нормально, звуки не так часто дёргаются. Иначе многовато мороки, т.к. enum нету.
Ну можно написать свой костыль вместо enum и использовать массив или вектор, но того не стоит, по-моему, задолбаешься туда новые значения закидывать.

[nOobCrafter]

TanaTiX проще нагуглить готовый вариант и его юзать, пардон но такие вещи давно написаны и хорошо работают, я юзаю вариант с синглтоном, в роли хранилища используется Dictionary.

[TanaTiX]

Сообщение от cleptoman

а вообще: трудно что-либо советовать, когда не понятна задача

Задача: есть в библиотеке набор звуков (потенциально не известного количества), которыми нужно управлять (проигрывать, при этом потенциально частота и разнообразие проигрывания могут быть абсолютно различными)

Вот один из первых вариантов, который вываливается при поиске. Что смущает - так это

public function addLibrarySound($linkageID:*, $name:String):Boolean

подобные конструкции с применением *

Т.е. получается что я могу туда передать все что угодно - и менеджер съест. Или создавать миллион проверок на валидность полученных данных (в том примере используется только проверка на наличие такого же объекта), ведь звук там или картинка, или просто строка - не известно.

В общем хочется универсальности и стабильности.

ЗЫ. или у меня манечка?

[cleptoman]

linkageID - это что-то из пережитков AS2

почему бы не пеердавать класс звука из либы и все
public function addLibrarySound($linkageID:Class, $name:String):Boolean

а еще лучше передавать экземпляры, тогда в вашем менеджере делаем метод а ля

 
public function addLibrarySound($sound:Sound, $name:String):Boolean
 
....
 
 
public function playSound($name:String):SoundChannel{
var sound:Sound = this.someSoundsHolder[$name];
if(sound){
return sound.play();
}
return null;
}

[TanaTiX]

это что-то из пережитков AS2

возможно, но не в наименованиях дело

Я так понимаю, в вышеуказанном примере someSoundsHolder является Dictionary?

[cleptoman]

может и обжект, если ключ стринговый..

[TanaTiX]

Назрел вопрос. Как правило подобного рода менеджеры являются синглтонами, т.е. не DisplayObject-ами. Следовательно если я, к примеру, хочу отследить окончание проигрывания произвольного звука, то я не смогу отослать событие об этом другим (потенциально всем) объектом приложения. И вообще, если сам менеджер воспринимать как контроллер, то как быть с событиями внутри контроллера?
Или я что-то не так понимаю?

[-De-]

DisplayObject может быть синглтоном и подобный менеджер можно хоть на сцену добавить. Не понятно только зачем. События могут слать штуки, унаследованные от EventDispatcher. Вот унаследовать его от него и слать. Любой, кто сможет долезть до него сможет и события слушать. Типа SoundManager.instance.addEventListener("ggsound_end", whateverListener);