Совершенно все равно, что там...
Тут обратная синтезу задача..., т.е. разложение.
----------------
1.Стоит ожидать, что реакция системы будет заметна на глаз и потому фонограмму придется давать с опережением, чтобы ~0.1Сек задержки не были столь навязчивы. (Это для бытового применения)
2. При эксплуатации нужно быть готовым на режим, когда придется муз ряд прогонять больше одного раза, чтобы подобрать состав инструментов(настроек), чтобы остановиться на оптимальном. Это потребует развитой интерфейс и базу коэффициентов. Получается, что этот инструмент становится в пределе участником шоу наравне с музыкальными...

Практика покажет

Если свет будет мельтешить в ритме музыки, то ну его нахрен такой концерт. Нужно намного спокойнее, плавнее. И задержка в 0.1 с здесь не помеха.

Ну вот так уже лучше.
Но не разложение, а редукция.
Разложение здесь также невозможно как невозможно разложить 3D в 2D.

Для редукции вам нужны эвристики. Эвристика под названием "старые музыкальные инструменты" мне кажется здесь неудачной.

Никто не мешает сделать фон, компенсирующий резкое мигание... Я ожидаю больше развитие свето-темы, нежели стробоскопические дерганья. Все это решаемо



Критерии каждый формирует(или выбирает) сам.
Никто не требует идеальности. Да и не будет её тут...
Это хороший повод углубиться в архитектуру "редуктора".

бас-гитару, барабаны, тарелки - сможете выделить по частоте
гитару, скрипку, трубу - сможете разделить по тембру
вот вам уже шесть, мало ?


нужно сначала понять, что пихать в плис
заложитесь лучше на нейросеть из мк - оно и проще в реализации, да и пооперативней работать будет


фарш невозможно провернуть назад
кое-что выделить - да


была какая-то советская цветомузыка, так ритм ловила весьма и весьма удачно
нужно очень постараться, чтобы не сделать такое же на мк

это уже не современно... Банально. Кстати,- тембр,- понятие уже многомерное и в новой концепции более доступнее


Вы не владеете темой конвейерной обработки... Даже не комментирую.
Уже понятно что. Осложняется задача необходимостью настроек от МК и прогоном моделей на Матлабе на разных реализациях. Обучение NN - САМОЕ муторное в этой концепции/
...Ломаю голову, применять ли сигмоидную функцию в качестве функции активации NN (сделать таблично) или кусочной аппроксимацией? Их там в "сетке" много... МК не способнен на столь глубокое распараллеливание, как FPGA. Вижу огромное применение такой архитектуры в практике(не только "восствновления фарша" из музыки)
Вы идеалист. Не ставится такая задача

МК - хорош в своей области.

наверное редкие инструменты имеют неизменный во времени тембр - вот вам уже и многомерность


многопроцессорность как раз и даёт конвейерность, с одним какие там конвейеры
а про гибкость мк против фпга я уж даже и не говорю
и в фпга вы должны загонять нечто готовое, чего у вас нет


вы хотите построить некую нейросеть, которая будто бы будет способна сама собой обучаться
не верю
вот сделаете 99% работы самостоятельно, а 1% отдадите на обучение - может оно и взлетит, иначе - нет


один мк за доллар против одного фпга за сто ? давайте лучше по эквивалентной цене за мипс и килобайт+мегабайт считать, ага ?


нет, мк хорош, а фпга хорош в своей области

Вы изначально не верно поняли задачу.
...Различать каждый из двух инструментов с разным тембром

Из пушки по воробъям...
На том и стою, что создаю, чего пока нет...
Обращаю внимание, что сразу закладываю в ФПГА возможность смены коэффициентов
Но и не это главное, а то, что мне доступно легко менять архитектуру, что при вашей "многопроцессорности" это проблемно. Схемотехника давлеет..

А я разве говорил о самообучении?.. Наоборот. Акцент был на предварительной отработке в Матлабе. За кого вы меня держите?... Чудно...

Опять одномерное восприятие!.. То что в ФПГА делается врожденно,- МК просто не способен. Кесарю кесарево...
Если выполнить все в вашей парадигме - траты на проектирование будут зашкаливать как материально, так и во времени. Например размерность сети, разрядность, связи
Вам придется делать несколько итераций схемотехники.
Я бы взялся бы за этот путь, когда уже станет известно оптимальное построение системы. Пока это этап исследований и лучше комбинации МК с ФПГА просто самый шикарный.

Я не сторонник крайностей. Одинаково дружу как с тем, так и с этим...

это сильно упрощает, можно попробовать тупо через корреляцию источника с суммой двух инструментов по очереди с разным тембром


я понял, но зачем менять архитектуру вычислителя, когда требуется менять архитектуру сети ?


траты на копипасты околонулевые, стоимость изготовления печатной платы их с лихвой перекроет

Это традиционный путь. Я о нем упоминал уже... Затратный...
если верить теории, с некоторым приближением, можно получить приемлемый результат дешевле... (в смысле аппаратного ресурса)


Архитектура сети и есть часть общей архитектуры


Это время (изготовление\монтаж\проверки), а значит траты тоже

если стоимость разработки софта для фпга принять за ноль, то таки да
если взять количество мк пропорционально количеству моделей и каждую записать во флешь, то с околонулевой стоимостью получите и конвейер и параллельные вычисления
сколько там флеши у фпга ? сколько моделей войдёт ? ага

Сообщение отредактировал Огурцов - Apr 27 2016, 18:48

Основные траты идут на модели в Матлабе. Когда станет ясно, что должно быть в ФПГА, софт для ФПГА будет сделан за неделю (естественно с тестбенчем)
Обращаю внимание, что никаких конфликтов производительности, синхронизации потоков , присущим МК, тут принципиально нет. МК - смена порядка NN - весьма болезненно. Наращивание потребует внешнего железа (N* МК).
У вас смутные представления о кухне по работе с ПЛИС.
К вашему сведению,- Делать проект для оценки ресурса на ФПЖА можно на любом этапе. Портируют проект на чип с 50% избыточностью (в расчете на возможные дополнения)

...Вы считаете траты не как разработчик, а как финансист. Это беда для прогресса, для коллектива.

я вообще не про распознавание,

но ещё в СССР была статья в Радио, где музыкальное произведение писалось в 1 канал стереофонограммы, а сопровождающая его заранее приготовленная партитура световых огней и спецэффектов - в другой.
В этом есть плюс... Электроника что-то распознает и зажгёт лампочки по-своему. А вот человек может и пофантазировать...

Я вас понимаю...
Сам неоднократно посещал с 1972г в парке им.Горького (зал открыт в 1969 г.) реализованного Ю. А. Правдюком, что в Харькове. Там оператор управлял рычагами и кнопками трафаретами и освещением...
Удивительно, что сам Правдюк и жил там в маленькой каморке, что была при этом зале. Ужасная судьба творческого человека... Надо будет зайти глянуть, что сейчас... Вы мне напомнили.

неделя фпгашного кодера == полста тысяч


с чего вы взяли


матричному вычислителю всё равно что и как считать, как программу напишете, так и будет и не надо ничего наращивать в железе, если производительности хватает
если же не хватает, то и вам придётся
а вот мне весьма любопытно, как вы будете плавучку в фпга считать и прочую тригонометрию, сколько ресурсов уйдёт на тривиальщину


я вижу, аргументы закончились ?


потому что всё заказчики, что бьют себя тапком в грудь, крича, что они такие крутые и богатые, в конце всегда плачут, почему так дорого
и только нормальные ценят старания по оптимизации, понимая, что ещё чуть дешевле и будет уже намного хуже