[Мур 1]

Не смешите, там один сплошной синтез.

Совершенно все равно, что там...

Тут обратная синтезу задача..., т.е. разложение.

----------------

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

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

 

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

[ViKo 1]

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

[AlexandrY 2]

Совершенно все равно, что там...

Тут обратная синтезу задача..., т.е. разложение.

----------------

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

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

 

Ну вот так уже лучше.

Но не разложение, а редукция.

Разложение здесь также невозможно как невозможно разложить 3D в 2D.

 

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

[Мур 1]

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

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

 

 

Ну вот так уже лучше.

Но не разложение, а редукция.

Разложение здесь также невозможно как невозможно разложить 3D в 2D.

 

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

Критерии каждый формирует(или выбирает) сам.

Никто не требует идеальности. Да и не будет её тут...

Это хороший повод углубиться в архитектуру "редуктора".

[VCucumber 0]

1.Ударные, Бас-гитара,Соло, Фотрепиано, Саксофон...

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

гитару, скрипку, трубу - сможете разделить по тембру

вот вам уже шесть, мало ?

 

2. Без ПЛИС точно не потянет, Контроллер тут как сервис различных наборов и редактуры настроек

нужно сначала понять, что пихать в плис

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

 

3. Для начала разделить кашу на потоки..

фарш невозможно провернуть назад

кое-что выделить - да

 

 

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

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

 

[Мур 1]

...гитару, скрипку, трубу - сможете разделить по тембру

вот вам уже шесть, мало ?

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

 

нужно сначала понять, что пихать в плис

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

Вы не владеете темой конвейерной обработки... Даже не комментирую.

Уже понятно что. Осложняется задача необходимостью настроек от МК и прогоном моделей на Матлабе на разных реализациях. Обучение NN - САМОЕ муторное в этой концепции/

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

фарш невозможно провернуть назад

кое-что выделить - да

Вы идеалист. Не ставится такая задача

 

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

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

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

[VCucumber 0]

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

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

 

Вы не владеете темой конвейерной обработки... Даже не комментирую.

многопроцессорность как раз и даёт конвейерность, с одним какие там конвейеры

а про гибкость мк против фпга я уж даже и не говорю

и в фпга вы должны загонять нечто готовое, чего у вас нет

 

Уже понятно что. Осложняется задача необходимостью настроек от МК и прогоном моделей на Матлабе на разных реализациях. Обучение NN - САМОЕ муторное в этой концепции/

вы хотите построить некую нейросеть, которая будто бы будет способна сама собой обучаться

не верю

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

 

МК не способнен на столь глубокое распараллеливание, как FPGA.

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

 

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

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

 

[Мур 1]

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

Вы изначально не верно поняли задачу.

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

многопроцессорность как раз и даёт конвейерность, с одним какие там конвейеры

а про гибкость мк против фпга я уж даже и не говорю

и в фпга вы должны загонять нечто готовое, чего у вас нет

Из пушки по воробъям...

На том и стою, что создаю, чего пока нет...

Обращаю внимание, что сразу закладываю в ФПГА возможность смены коэффициентов

Но и не это главное, а то, что мне доступно легко менять архитектуру, что при вашей "многопроцессорности" это проблемно. Схемотехника давлеет..

вы хотите построить некую нейросеть, которая будто бы будет способна сама собой обучаться

не верю

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

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

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

Опять одномерное восприятие!.. То что в ФПГА делается врожденно,- МК просто не способен. Кесарю кесарево...

Если выполнить все в вашей парадигме - траты на проектирование будут зашкаливать как материально, так и во времени. Например размерность сети, разрядность, связи

Вам придется делать несколько итераций схемотехники.

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

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

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

[VCucumber 0]

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

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

 

легко менять архитектуру, что при вашей "многопроцессорности" это проблемно

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

 

Если выполнить все в вашей парадигме - траты на проектирование

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

 

[Мур 1]

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

Это традиционный путь. Я о нем упоминал уже... Затратный...

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

 

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

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

 

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

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

[VCucumber 0]

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

если стоимость разработки софта для фпга принять за ноль, то таки да

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

сколько там флеши у фпга ? сколько моделей войдёт ? ага

Изменено 27 апреля, 2016 пользователем Огурцов

[Мур 1]

если стоимость разработки софта для фпга принять за ноль, то таки да

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

сколько там флеши у фпга ? сколько моделей войдёт ? ага

Основные траты идут на модели в Матлабе. Когда станет ясно, что должно быть в ФПГА, софт для ФПГА будет сделан за неделю (естественно с тестбенчем)

Обращаю внимание, что никаких конфликтов производительности, синхронизации потоков , присущим МК, тут принципиально нет. МК - смена порядка NN - весьма болезненно. Наращивание потребует внешнего железа (N* МК).

У вас смутные представления о кухне по работе с ПЛИС.

К вашему сведению,- Делать проект для оценки ресурса на ФПЖА можно на любом этапе. Портируют проект на чип с 50% избыточностью (в расчете на возможные дополнения)

 

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

[Ydaloj 0]

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

 

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

В этом есть плюс... Электроника что-то распознает и зажгёт лампочки по-своему. А вот человек может и пофантазировать...

[Мур 1]

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

В этом есть плюс... Электроника что-то распознает и зажгёт лампочки по-своему. А вот человек может и пофантазировать...

Я вас понимаю...

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

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

[VCucumber 0]

софт для ФПГА будет сделан за неделю (естественно с тестбенчем)

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

 

конфликтов производительности, синхронизации потоков

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

 

, присущим МК, тут принципиально нет. МК - смена порядка NN - весьма болезненно. Наращивание потребует внешнего железа (N* МК).

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

если же не хватает, то и вам придётся

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

 

У вас смутные представления о кухне по работе с ПЛИС.

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

 

...Вы считаете траты не как разработчик, а как финансист

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

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