Вы правы, такая организация кода тоже может быть. Для конечного пользователя все станет немного проще, но есть несколько трудностей:
Компоненты будут содержать код для определения, какую технологию использовать.
Пакеты будут содержать очень много зависимостей.
Декодер не получится использовать как процессор, потому что все данные в pipe.Pipe передаются в float64, а для такой задачи нужно работать непосредственно с массивами байт.
Часть этих проблем являются следствием ограничений в Go. Кроме того, деление пакетов по технологиям является идиоматическим и можно часто встретить в стандартной библиотеке.
Спасибо за комментарий. Из реальных сценариев в голову приходят голосовой чат и аудио-стриминг. Я хотел сделать демо, где играл бы небольшой отрезок аудио и можно было бы в real-time накидывать на него разные эффекты. Такой server-side processing для аудио. Пока отложил в ящик из-за сложного (для меня) клиента.
В целом, клиент-серверное взаимодействие есть в планах и обязательно будет описано по мере запиливания.
<sarcasm>Пойду проверю свой счет в банке.</sarcasm>
Если серьезно, то я просто нашел интересную мне задачу и решил ее языком, который мне нравится. Решение показалось мне интересным, я создал фреймворк и теперь хочу его развивать. Не считаю что какой то язык лучше другого. Каждому свое применение.
Я думал о генераторах и как их реализовать для удобного использования. Помимо осциллятора я бы отнес к генераторам звука запись сигнала через аудио интерфейс. Здесь, наверняка, надо будет добавить какие то общие для всех генераторов параметры. Например, длительность генерации или возможность прервать ее «вручную». Как и любой другой источник, осциллятор должен будет реализовывать pipe.Pump. Конкретно — pipe.Pump с нужными для осцилляторами параметрами: форма волны, частота, амплитуда и т.д. К сожалению, я не очень знаком с генерацией сигналов, но было бы очень интересно реализовать.
Я пока не реализовывал декодеры, но по идее любой аудио-формат — это потенциальный источник и пункт назначения для аудио данных. Соответственно, пакет mp3 мог бы иметь Pump и Sink реализации чтобы читать и писать файлы. Аналогично wav. Если у исходного файла подходящая частота дискретизации и число каналов — можно брать и использовать.
Вы правы, такая организация кода тоже может быть. Для конечного пользователя все станет немного проще, но есть несколько трудностей:
Часть этих проблем являются следствием ограничений в Go. Кроме того, деление пакетов по технологиям является идиоматическим и можно часто встретить в стандартной библиотеке.
Спасибо за комментарий. Из реальных сценариев в голову приходят голосовой чат и аудио-стриминг. Я хотел сделать демо, где играл бы небольшой отрезок аудио и можно было бы в real-time накидывать на него разные эффекты. Такой server-side processing для аудио. Пока отложил в ящик из-за сложного (для меня) клиента.
В целом, клиент-серверное взаимодействие есть в планах и обязательно будет описано по мере запиливания.
<sarcasm>Пойду проверю свой счет в банке.</sarcasm>Если серьезно, то я просто нашел интересную мне задачу и решил ее языком, который мне нравится. Решение показалось мне интересным, я создал фреймворк и теперь хочу его развивать. Не считаю что какой то язык лучше другого. Каждому свое применение.