Пожалуйста проголосуйте.

[Zerocool]

buncker скажи мне как разаботчик слейта , бедствует слейт ???
)
вот слейт драммер 4.0 , ...и никаких айлоков нет , и ничего не ломали вроде )

если софтина реально незаменимая , (как твой триггер скажем ) - она будет иметь успех и $$$
если это очередной "винтажный EQ" - ... нахрен никому не сдался)...

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

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

 

[basЫl]

что там такого уникального чего нет в кубе/рипере/ризоне/кейквоке/аблетоне/протухлзе

охохо, я больше ничего не буду писать.

использование для обсчетов видеокарты - это больше минус чем плюс (отбрасываем сразу все буки)

http://fudzilla.com/home/item/31461-nvidia-won-most-haswell-high-end-notebooks

и много в программе плюсов, чтобы они эти минусы могли перевесить?

то опросы подобные этому ..

чем не нравится опрос? я спрашиваю мнение пользователей по конкретному вопросу и получаю ответы. В чем проблема?

 

[Zerocool]

basЫl я конечный юзер, и у меня в итоге наблюдения за этой затей не появилось ни малейшего позыва что то у вас покупать ..
вы мне подозрительны )....и ваша затея тоже ))
и судя по всему не только мне ....
это повод задуматься

 

[basЫl]

спасибо за ваше мнение, оценил.

 

[Andrew_S.]

график конечно красивый, но и у ЦП сейчас тоже с гигафлопами полный порядок .

anyway, если есть уверенность - удачи в поисках инвестора!

 

[basЫl]

у ЦП сейчас тоже с гигафлопами полный порядок

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

 

[buncker]

basЫl,а кроме графика то есть что?
архитекрура GPU этож не х86, а куча однотипных и дико специализированных процессоров, так ведь? И сравнивать их тупо по мегафлопам мягко говоря некорректно.
Конечно выкатили для них язык разработки который пытается скрывать особенности архитектуры от разработчика, но ведь до сих пор на GPU заявленную производительность можно выжать только на специфических задачах же?
Плюс латентность была раньше дикая при работе с GPU - эту вещь победили?

вот такую инфу было бы интересно услышать - а не график с рекламной статьи.

PS интел свои knight corner не так просто на рынок двигает.... нормальне х86 ядро, с нормальными simd расшерениями, с нормальной памятью итп.

 

[AL.L]

процессор Intel Xeon Phi ..второе поколение имеет 61 ядро , производительность на уровне 1.2 TFLOPS ) ...
Nvidia GTX Titan , скорость вычислений данных с плавающей точкой равно 1.5 TFlops в секунду (это пока чего удалось добиться на практике) , теоретически же эта дрянь может выдавать и 4,7 tflops ) ...

Но тут куча подводных камней и всё теоретически )

Да ладно вам , чего вы так скептично к этому относитесь ? ....ещё ничего нет а вы уже не довольны =) ....может у людей всё получится !

 

[buncker]

AL.L, ни одного слова в стиле "да у вас хлам и ничего ен выйдет" от меня не было. Я вообще ко всем кто что-то новое делает или пытается делать отношусь с глубочайшим уважением.
Просто basЫl вроде как в теме, и было бы интересно увидеть что-то более близкое к жизни нежели рекламный график. Там на графике есть прекрасная подпись а-ля "теоретически достижимая производительность" =)

PS а вот xeon phi рано или поздно слопает ускорители типа уада и протулза хд, это к бабке не ходи.... Ведь на него реально без проблем портивраоть любой вст код тупо перекомпиляцией и всё... а скорость работы на голом х86 ядре на котормо больше ничего не крутится (ну там операционка со всей требухой) - дикая.

 

[AL.L]

buncker Возможно )) , кстати перспективная идея , насчёт phi) .....ну просто всё идёт к тому ,что рано или поздно будет полное слияние cpu и gpu ...и какие то разработки в данной области могут быть вполне перспективными и в будущем уже будет и опыт и знания ..

 

[ugahugo]

Не понял я зачем 2D, и тем более 3D в DAW, это же не квейк.

Это была критика как раз фреймвёрков и библиотек, собственно, что вы сказали, то я и подтвердил, только ранее.

http://habrahabr.ru/company/microsoft/blog/121937/

AMP в анонсе от MS мне показался дико интересным по началу. Ибо они обещали очень удобные структуры для работы с кодом, реализованные как в .Net (теже TPL.Parallel.Foreach и т.д.). AMP даёт также, например, конкурентные контейнеры с реализованными внутри механизмами синхронизаций при работе с контейнером, даёт несколько более удобные структуры для улучшения использования кеша (сделали они тайлы, хотя это делается быстро).

Но, по сути, MS не решили две основные проблемы. 1. Самая главная проблема - как параллелить код, кроме как руками. Развёртывать циклы в коде, залить в кеш побольше - это прошлый век. Актуальнейшая проблема - есть некоторая конфигурация ресурсов (ваша видеокарта или несколько видеокарт) и есть конфигурация задач, вам нужно всё разметить в режиме реального времени таким образом, чтобы успеть всё обработать во временном буфере, равном буферу задержки аудиоплаты. Отсюда требуется писать собственные планировщики нитей и заранее готовить к этому код (параллелят сейчас с помощью теории аффинных отображений, это математика). Этого никто не решил. 2. Вторая основная проблема, это доступ к самым низкоуровневым средствам, уровня драйвера (как память выделять, как слать данные, когда) + непосредственный доступ к ключам компилера. Т.к. C++.AMP построен на DirectX, то отсюда все недостатки (поправьте меня, если я не прав), кроме того, DirectX не отличается скоростью работы, в сравнении с той, какой мы достигли (не считая нагрузки) в нашем решении (на стороне GPU - пока что только nVidia CUDA).

Кроме того, MS даже не удосужилась полноценно встроить AMP в часть .Net, отсюда все проблемы с P\Invoke сохранились (обёртка неуправляемого кода со всеми тонкостями).

В таком случае, встаёт резонный вопрос: "Принимая во внимание всё выше сказанное, какой смысл пользоваться именно этим решением для разработки, если ничего лучше "нативных" решений nVidia CUDA \ AMD FireStream нет?". Удобства не добавляет, самые важные проблемы не решены, перформанс несколько хуже (для двух некоторых эквивалентных программ выполненных на разных платформах с целью сравнения).

 

[ugahugo]

если программулина раз в 2 дня чего то хочет, то возникает вопрос - а как она узнает что прошло 2 дня?

Не обязательно. Клиент-серверным способом это можно решить. Собственно, так и хотели это решать.

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

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

Но, по сути, по теме я уже ответил. И если пользователи хотят именно так работать - пусть будет так. Уверен, ситуация изменится скоро в нашу сторону, ибо это тенденция последних 15 лет. Вопрос в том, кто её будет менять.

 

[ugahugo]

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

Никто не говорил, что поддержки VST не будет. Был вопрос, сможет ли чудесным способом VST - плагин заработать на GPU. Мы ответили, что это могут решить, например, Lockeed Martin или NASA, но не мы. А так, подключить купленный вами VST - вообще не вопрос.

GPU как минус, не как плюс? Я не хочу спорить, но мне всегда казалось, что если разработчики авиалайнеров делают авиалайнер, который перевозит быстрее, дешевле и большее количество пассажиров на борту - это только плюс.

 

[ugahugo]

basЫl,а кроме графика то есть что?
архитекрура GPU этож не х86, а куча однотипных и дико специализированных процессоров, так ведь? И сравнивать их тупо по мегафлопам мягко говоря некорректно.
Конечно выкатили для них язык разработки который пытается скрывать особенности архитектуры от разработчика, но ведь до сих пор на GPU заявленную производительность можно выжать только на специфических задачах же?
Плюс латентность была раньше дикая при работе с GPU - эту вещь победили?

вот такую инфу было бы интересно услышать - а не график с рекламной статьи.

PS интел свои knight corner не так просто на рынок двигает.... нормальне х86 ядро, с нормальными simd расшерениями, с нормальной памятью итп.

Привет,

Архитектура GPU - это куча однотипных простых ALU (большая часть), и некоторое количество Special Function Units (кто работает с трансцендентными операциями, sin(x), e^x и т.п.).

Насчёт специфических задач - да.

Смотря что считать латентностью. У нас на то, чтобы послать данные с аудиоплаты в память, потом на видеопамять, просчитать один Delay и послать всё обратно уходит, внимание, 10 микросекунд (порядок именно такой). Это было зафиксировано на моей gt610m. Это достаточно низколатентно для работы со звуком, как считаете? При этом мы работаем с, внимание, ужасно медленным .Net (хотя я как говорил, что это не так, так и буду говорить), с обёрнутым кодом, ещё и GUI при этом у нас адекватно бежит (хоть и работает на костылях).

P.S. Терафлопсы, гигабайты, гигагерцы не решают всё в последней инстанции. У вас есть главный элемент программы, - это цикл. Если вы можете (особенно) в режиме реального времени грамотно управлять некоторым кодом, содержащим цикл, то это решает, строго говоря, вообще всё. Лишний проход - и время увеличивается на сумму всех времён выполнения всех инструкций в теле цикла. Вот и всё. nVidia не зря докладывает об x20 и более ускорении выполнения программ, ибо знает, что краеугольный камень - это решение задачи распараллеливания (хотя бы статично, на этапе компиляции).

Посему лично я за GPU. Отдельная тема - FPGA для космоса, но за такие бабки, извините.

Knight'ы x86 - очень интересная тема, с Unix'ом внутри. У меня не было возможности поиграться с этим, но, мне кажется, всё упирается во фреймвёрк и средства разработки под него. Если будет реализована возможность полностью залить туда x86 код и это не будет стоить разработчику дополнительно практически ничего - то да, отличное решение (не смотря на стоимость). В ином случае, думаю, революции не произойдёт.

 

[buncker]

ugahugo, на сколько я понял, knight исполняет обычный х86 код. Максимум надо поставить интеловский компилятор к вижуал студии обычной майкрософтовской и всё, в том и прелесть.

Значит с задержками уже лучше на столько стало, круто! А вопрос глобального плана можно? надеюсь он не раскрывает каких то ваших бизнес секретов...
Какие задачи на GPU есть желание переложить?
В разрезе DAW обычной самая требовательная к ресурсам вещь это собственно плагины. Можно придумтаь ещё пару тройку применений, ну там апсемплить дико весь мультитрэк на лету итп, но это больно частные случаи.
Так вот если взять плагины - то как заставить сторонних разработчиков делать порты своих плагинов на ваш фреймворк новый чтоб пусктаь код на GPU?

Ведь не умаляя ваших достоинств, я всёж уверен в том что какая бы гениальная команда у вас не была, создать полный спектр плагинов под GPU вам не под силу, ну протсо потому что кроме технических навыков чисто нужно нечто более для этого.
А "стандарный" набор плагов которыми балуют нас все хосты свободно тянет современный проц обычный. Более того, вместо современой топовой видео карты можно купить топовый проц, а то и пару, а то и второй комп под вычисления на базе вены или как там её...

простыми слваоми - куда вы будете девать эту производительность?

PS про автоматическое распаралеливание как то не очень понятно именно в разрезе DAW. Основная нагрузка DAW -плагины. Это изолированные алгоритмы, нужно их прост орассадить по ядрам, дать данные, и забрать данные. Может коненчо я слишком узко вижу.. но мой взгляд снизу так сказать, из того самого плагина...

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

 

[Andrew_S.]

> а вот xeon phi рано или поздно слопает ускорители типа уада и протулза хд

они его уже давно слопали. те DSP-шки которые там стоят морально устарели много лет назад. просто уад пользует это как дополнительную "защиту от копирования". протулз похоже уже плюнул на свою железяку.

> Никто не говорил, что поддержки VST не будет. Был вопрос, сможет ли чудесным способом VST - плагин заработать на GPU. Мы ответили, что

этто понятно .

> GPU как минус, не как плюс? Я не хочу спорить, но мне всегда казалось, что если разработчики авиалайнеров делают авиалайнер,
> который перевозит быстрее, дешевле и большее количество пассажиров на борту - это только плюс.

тут дело немного в другом. ок, мы перенесли все обсчеты на видеокарту, а чем тогда ЦП то заниматся?
да и что конкретно считать на видеокарте? можно конечно написать EQ или компрессор тупо "по учебнику", или взяв готовую библиотеку, только что толку от такого EQ\компрессора. нужны "звучащие" алгоритмы. а как это сделать - в учебнике не написано. это вообще нигде не написано. и если таких алгоритмов нет, то чем тогда грузить видеокарту? суммирование - достаточно "легкий" процесс.

 

[ugahugo]

buncker, По сути, все задачи хочется переложить. Недавно вот парились над компрессором \ гейтом, выяснилось, что, по сути, поиск "пробоя уровня (заданного юзером)" не особо параллелится (исключая применения редукции (в задаче поиска максимума \ минимума), например), но вот зато, если пробой есть, то подсчитать, собственно, "гашение" можно параллельно. Так что, по сути, некоторые задачи будут решаться гетерогенно. А так, обязательно будет и весь джентельменский набор, описываемый basЫl'ом, и хотелки (у нас также есть идеи не только в части алгоритма, но и в части нового функционала, уникального). Обязательно будем адово работать над тяжёлыми обработками типа свёрток, ибо есть хорошие алгоритмы, реализованные даже на GPU (статьи) на эту тему.

Мы работаем над собственным SDK и форматом. Назвали его GEM (GPU Execution Module). Если очень кратко, то мы сделаем SDK, который будет состоять из 2 частей. Первое - это по части UI (связывание данных и не только), второе - это по части взаимодействия с нашим низколатентным движком (работа с нашим планировщиком нитей GPU) и, собственно, сам код, исполняемый на GPU (соответственно, для nVidia это будет .cuh, .cu, .ptx, для AMD FireStream - свой формат). Идея SDK заключается в том, чтобы дать людям уровня от полупрофессионала (кодер + алгоритмист) до про конторы задействовать GPU, реализуя алгоритм, как будто ты пишешь обычную функцию, исполняемую на GPU, но при этом мы освобождаем юзера от решения одной очень важной глобальной задачи - как написать эту функцию так, чтобы на различных множествах конфигураций задач и конфигураций ресурсов, перформанс был некоторым хорошим средним. Это очень важный момент. Ну и мы лечим юзерам синие (или любые другие) экраны смерти, которые они во многих случаях получают, например в Nebula VST.

Насчёт алгоритмов и команды. Это как смотреть на всё вообще. Мы, не имея алгоритмиста (человека, хорошо владеющего теорией DSP, Matlab'ом, например и всякими кошерными и не очень полиномами), сделали за несколько дней параллельные дилэй и флейнджер с очень хорошим processorcs occupancy.

Производительность пойдёт на тяжёлые реал тайм обработки. Наша философия - производительность пост про решений по цене решений предназначенных для музыкантов. Мы можем тут кучу фишек рассказать, что это вам даёт, но достаточно просто хотя бы спросить об этом пользователей тойже Nebula VST (уже решённый стандартный кейс).

Это не автоматическое распараллеливание. Именно, что нужно рассадить множество алгоритмов на множестве ресурсов для некоторого максимально возможного occupancy. Конфигураций алгоритмов много, конфигураций ресурсов тоже много, итоговых конфигураций ещё больше, отсюда решение не выглядит как некоторая стандартная функция, представляющая алгоритм, с кучей служебной инфы для "рассадки", ничего тогда не получится. Никаких 10 мкс.

 

[Andrew_S.]

> сделали за несколько дней параллельные дилэй и флейнджер с очень хорошим processorcs occupancy.

дилей и фленжер - пишутся на 2 часа максимум. еще за полчаса пишется хорус, так как он от фленжера мало чем отличается. processorcs occupancy даже на ЦП минимален, особенно если использовать SSE. людей больше интересует вопрос - а как это все звучит?

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

 

[ugahugo]

Andrew_S,

тут дело немного в другом. ок, мы перенесли все обсчеты на видеокарту, а чем тогда ЦП то заниматся?
да и что конкретно считать на видеокарте? можно конечно написать EQ или компрессор тупо "по учебнику", или взяв готовую библиотеку, только что толку от такого EQ\компрессора. нужны "звучащие" алгоритмы. а как это сделать - в учебнике не написано. это вообще нигде не написано. и если таких алгоритмов нет, то чем тогда грузить видеокарту? суммирование - достаточно "легкий" процесс.

По вопросам психоакустики это конкретно не ко мне. Сделать 100 тысяч эквалайзеров с подкрученными коэффициентами и продавать их по-отдельности - это тоже не ко мне. Я, строго говоря, убеждён, что это задача не разработчика, а как раз клиента, как минимум, частично. На данный момент мы отталкиваемся от некоторого basic bunddle безо всяких психоакустических изощрений, у нас же нет своего коммьюнити и т.д.. Было бы совершенно не рационально сейчас сидеть и слушать разных людей, "как сделать вкусный EQ", ибо, повторюсь, нет своей аудитории (именно клиентов), а иначе, "ты сейчас рискуешь угодить прохожему", что выглядит, мне кажется, не здорово. Мы сделаем то, что хотим сделать, посмотрим, как к этому отнесутся люди, которым это интересно, начнём с ними общение и тогда уже поймём, куда двигаться.

Конкретно по части использования GPU - я, опять же, рекомендую рассмотреть кейс тех, кто пользуется Nebula VST. Собственно, чем должен заниматься CPU, если выполнение алгоритмов перенести на GPU, мне кажется, ответ очевидный для всех.

Мы прекрасно понимаем сегментирование рынка и то, что всем не угодим. Сейчас мы не претендуем на роль Market Maker'а, ибо нет для этого ни продукта, ни ресурсов. Однако, мы видем интерес (статистика есть), посему мы и решили этим заняться.

 

[ugahugo]

> сделали за несколько дней параллельные дилэй и флейнджер с очень хорошим processorcs occupancy.

дилей и фленжер - пишутся на 2 часа максимум. еще за полчаса пишется хорус, так как он от фленжера мало чем отличается. processorcs occupancy даже на ЦП минимален, особенно если использовать SSE. людей больше интересует вопрос - а как это все звучит?

Если это так для (всех типов) GPU с некоторой регулярно максимальной processors occupancy, то мы с радостью приглашаем вас к себе, хех. В этом топике регулярно происходит подмена понятий, pardonne moi...

Сколько дилэев затащит, скажем, BloomField \ Haswell на 8 ядер на ваших SSE, например, в StudioOne (положим, родной, VST, как правило, поменьше) и GTX680, как вы считаете? А фоновый рендеринг будет возможен при этом? А в Skype заглянуть вы сможете? В общем, зачем холиварить, есть кейс у пользователей Nebula VST, я вас к ним третий раз отсылаю, простите .

 

[Andrew_S.]

> Если это так для (всех типов) GPU, то мы вас с радостью приглашаем вас к себе, хех.

да да, я помню! сперва предлагаете нахаляву решить совершенно идиотскую задачку, а потом гаситесь.

> Было бы совершенно не рационально сейчас сидеть и слушать разных людей, "как сделать вкусный EQ"

понимаете ли в чем дело. сведение звука, это очень специфичная штука, основанная как раз на "вкусном звуке". "усредненно хреново" никому не надо.

> Сколько дилэев затащит, скажем, BloomField \ Haswell на 8 ядер на ваших SSE, например, в StudioOne (положим, родной,
> VST, как правило, поменьше) и GTX680, как вы считаете? А фоновый рендеринг будет возможен при этом? А в Skype
> заглянуть вы сможете?

вы простите 1000 дилеев в проекте планируете использовать. или фоновый рендеринг в время сведения?
а и-нет на рабочем звуковом компе в студии - это мягко говоря моветон.

> В общем, зачем холиварить, есть кейс у пользователей Nebula VST, я вас к ним третий раз
> отсылаю, простите .

ладно мужики, сильно спорить не буду, тут у каждого свое ИМХО.
уважуха за упертость и кучу потраченного времени. желаю чтобы все таки пошло, а не слилось в унитаз!

 

[ugahugo]

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

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

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

 

[ugahugo]

> Если это так для (всех типов) GPU, то мы вас с радостью приглашаем вас к себе, хех.

да да, я помню! сперва предлагаете нахаляву решить совершенно идиотскую задачку, а потом гаситесь.

> Было бы совершенно не рационально сейчас сидеть и слушать разных людей, "как сделать вкусный EQ"

понимаете ли в чем дело. сведение звука, это очень специфичная штука, основанная как раз на "вкусном звуке". "усредненно хреново" никому не надо.

Простите, честно говоря, тема куда-то зашла в адовый флейм с подменой понятий и фантазиями. Мне кажется, я очень точно отвечал на все оффтоп-вопросы.

 

[buncker]

ugahugo, последний вопрсо - у вас в команде есть разработчики муз софта с музыкальным бэкграундом? Другими словами -у вас есть хоть один человек который знает йифровой звук с двух сторон? Есть человек котоырй юзкейсы разрабаывтает связанный с релальной оптребностью музыкантов?

просто толи я вообще глубоко не в теме (что очень веротяно!), толи разговор про распаралеливание алгоритмов типа дилэя\хоруса\компрессора это какой-то стёб жесткий.

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

PPS тема изначально провальная ИМХО (спрос с людей в инетах про вариант защиты имею в виду). Есть сложившиеся шаблоны рабоыт у людей в голове. Если продутк на продажу в ближайшее время - то над овписываться, если продукт - революционер прокладывающий своей кровью дорогу в светлое будущее - то какое дело до мнения юзверей? (джобс стиль =) )

 

[basЫl]

ugahugo, последний вопрсо - у вас в команде есть разработчики муз софта с музыкальным бэкграундом? Другими словами -у вас есть хоть один человек который знает йифровой звук с двух сторон? Есть человек котоырй юзкейсы разрабаывтает связанный с релальной оптребностью музыкантов?

нет. есть.

PPS тема изначально провальная ИМХО (спрос с людей в инетах про вариант защиты имею в виду).

это не тема, это опрос. Он показал что большинству не понравилось. Не понимаю, как можно что-то делать для людей НА ПРОДАЖУ, при этом их не спросив, у них устраивает ли их продукт.

Революцию всем подавай... Эволюция не подходит? на всех не угодишь.

 

[ugahugo]

buncker,

Да, конечно.

Я повторюсь, речь идёт о самом базовом банддле. Сделать ререлиз с подкрученными коэффициентами - вопрос недели, мне кажется.

Конкретно этот топик был затеян для проверки гипотезы о подписке на выборке людей с rmm.su.

Мы не говорили, как выглядит наш продукт. Мы не говорили, что в нём уникального, возможно, кому-то не нужного, там есть или появится. Там нет психоакустики на данный момент, но есть вещи востребованные, каких нет у конкурентов в части функционала, который может пригодится, например, в Live или post pro (не только GPU-технология) или, например, при создании проекта, который вы своими силами закрыть не можете (или на это уйдёт слишком много времени, которого у вас нет).

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

 

[Andrew_S.]

> Сделать ререлиз с подкрученными коэффициентами - вопрос недели

вообще то достаточно умные дядьки c серьезным слуховым опытом тратят на это годы и годы...
мне бы ваш оптимизьм

 

[ugahugo]

> Сделать ререлиз с подкрученными коэффициентами - вопрос недели

вообще то достаточно умные и опытные дядки тратят на это годы и годы...
мне бы ваш оптимизьм

Мы знаем. А ещё они тратят годы на переделку микшеров, которые суммируют пустые регионы. С их бюджетами на R&D в полтора десятка миллионов долларов в год и когортами людей.

 

[basЫl]

закрываю тему.

 

[buncker]

Мы знаем. А ещё они тратят годы на переделку микшеров, которые суммируют пустые регионы. С их бюджетами на R&D в полтора десятка миллионов долларов в год и когортами людей.

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