[JSFX] Hycompressor
- Автор темы belovw
- Дата начала
Я бы чёрный фон убрал в первую очередь, моветон немного
Такое может что-то (чисто по цветам, расположение и размер элементов не трогал, т.к не понимаю, что за что отвечает)
Такое может что-то (чисто по цветам, расположение и размер элементов не трогал, т.к не понимаю, что за что отвечает)
@belovw, все прекрасно, но с тз дизайна откровенная беда. И тут нужно понимать, как хочется: "я художник, а гейн редакшен там удобно", или изучать вкратце эргономику и современный юай, или воровать удачные варианты. Самым качественным, разумным, быстрым, и в целом правильным вариантом мне видится найти энтузиаста в помощь на девиантарте/бихэнсе
Кстати, не оч понимаю этого дизайн рефа "как у валгалла". По мне, ничего кроме примитивного дизайна, отвратительно неудобных пресет меню, грузного вектора, сочетания нобов и вертикальных слайдеров (это проклятье для пк оператора), и своего шрифта, - там нет
Это уже интереснее, но ума не приложу зачем нужен один большой ноб, и от чего прямо центре. Ну и шрифт, да, обычно у шрифтов яркость значительно ниже органов управления, которые они маркируют.
Кстати, не оч понимаю этого дизайн рефа "как у валгалла". По мне, ничего кроме примитивного дизайна, отвратительно неудобных пресет меню, грузного вектора, сочетания нобов и вертикальных слайдеров (это проклятье для пк оператора), и своего шрифта, - там нет
@fakeitback, весьма прикольно.
@electrical, спасибо за отзыв. Интерфейс решил использовать векторный по причине того что плагин получается независимым от внешних ресурсов. Ну и я как бы не дизайнер ни разу, поэтому сидеть рисовать интерфейсы вообще не мое. А векторный в этом плане прост - накидал крутилок, наляпал надписей и всех лелов.К стати, ресурсы CPU этот интерфейс практически не ест. Что-то меньше одной сотой процента. И если плагин закрыт, то графическая часть ресурсы уже не ест вообще. Так что пофиг.
Ребята, поменять цвета, размеры и расположение - секундное дело. Можно привлечь даже губастых блондинок. Они более чем справятся с этой ответственностью и помогут вдохновиться перед работой над дизайном. Главное, это то что основная работа уже сделана, решены вопросы логики и ее реализации. Единственно чего нет, так это ввод значений параметров с клавиатуры. Дело осталось за мизерной доли малого.
Ну и оптимизировать там конечно можно много чего. Чиста для культуры кода.
@electrical, спасибо за отзыв. Интерфейс решил использовать векторный по причине того что плагин получается независимым от внешних ресурсов. Ну и я как бы не дизайнер ни разу, поэтому сидеть рисовать интерфейсы вообще не мое. А векторный в этом плане прост - накидал крутилок, наляпал надписей и всех лелов.К стати, ресурсы CPU этот интерфейс практически не ест. Что-то меньше одной сотой процента. И если плагин закрыт, то графическая часть ресурсы уже не ест вообще. Так что пофиг.
Ребята, поменять цвета, размеры и расположение - секундное дело. Можно привлечь даже губастых блондинок. Они более чем справятся с этой ответственностью и помогут вдохновиться перед работой над дизайном. Главное, это то что основная работа уже сделана, решены вопросы логики и ее реализации. Единственно чего нет, так это ввод значений параметров с клавиатуры. Дело осталось за мизерной доли малого.
Ну и оптимизировать там конечно можно много чего. Чиста для культуры кода.
Это супер!
По поводу дизайна могу добавить, что большинство узнаваемых продуктовых цепочек - работа дизайн систем в том числе. То есть четко прописанных зависимостей, начиная от скруглений и отступов, заканчивая наборами символов (в нашем случае органов управления), шрифтами, палеткой и тд: пример от IBM. Иными словами, это достаточно обьемный и продуманный конструктор. Чтобы быстрее всего понять логику построения успешного юая, как мне кажется, проще всего самому собрать макет из готовых удачных дизайн систем
То что вы сейчас написали правильно, но для не дизайнера, это как послать на деревню к деду.
Можно вот так забабахать), регуляторы "обозвать", ну и т.п., 
, как вариант)
, как вариант)
Я бы написал вначале фреймворк для работы с ui (идею можно подглядеть по элементам и контроллам,инфы валом, с концептом главное не промахнуться.Лично для меня гуй самая геморная тема для освоения в плане реализации кода(биндинги, фуиндинги, ивенты, месаги всякие) , дизайн элементов как-то по-проще осваивается) ). В дальнейшем избавитесь от головняка при проектировании/прототипировании идей(говорить конечно легко в отличии от реализации фреймворка, но опыт приобретённый в процессе окупиться с лихвой) . В jsfx принцип чем то напоминает работу с графикой в winapi(но утверждать не буду, так си(на плюсы пока решил не дёргаться во избежание каши в голове) только начал изучать) .Создать красивый векторный, интерфейс в отличии от растра заключается в том, что по сути это двойная работа по трудозатратам и быстро надоест в отличии решения задач по dsp(лично для меня так) . Как пример где глянуть: (в фл студии правда) , есть утилита генерации векторных кнобов, слайдеров, есть список генерации требуемых параметров(цвет,геометрия фасок,форма, тени, и т.д и т.п, что то на подобии кнобмана).
Ни одного знакомого слова...
А это уже знакомое слово, но разговор идёт больше чем уверен не о том о чём я полумал.
Фреймворк-база(грубо говоря от чего плясать при разработке интерфейса). В принципе можно отделаться "лёгкой кровью" и написать библиотеку функций для облегчения при начале разработки, а в дальнейшем развивать эту библиотеку. Интерфейс(графический векторный) = программный код. Начальный уровень(линии, примитивные геометрические фигуры, поддержка польз.шрифта,работа с цветом, заливкой и т.д и т. п имеются ввиду функции для @GFX) уже сделан разрабами рипера. Вам предстоит вроде бы легкая на первый взгляд(но это совсем не так) задача.Все это оформить в векторную картинку на которой будут buttons, slider, xy_pad, keyboard и тд.,а также поведение этих элементов(поведение и данные разделены). Структур для данных в jsfx нет(данные храним в файлахинклюдах в виде суперфункций(описаны размеры бэкграунда фона, цвет и тд и тп) , методы описывающие поведение возможны(суперфункция/функция/набор функций описывающая, что сделать, когда на кнопку наведен курсор и нажать левый клик например в какую секцию отправить результат) .(как Вы выше в ветке писали в рипере поведение слайдера линейное, хотя это не совсем так-представление слайдера линейное по отношению к другому слайдеру(т. е отсутствует изменение размера/масштабирования слайдера по отношению к другому в связи с этим траблы некрасивые получаются при линке и модуляции параметров, могу и ошибаться), но разрабы оставили возможность в реализации собственного контролла(подглядел в интернете формулировку :контролл- примитивный элемент графического интерфейса, обладающий стандартным поведением(выполняет определённые ст. действия и имеет стандартный вид) . Другой момент как реализовать окно(если плаг не однооконный или менюшку с пунктиками нужно замудрить) статично считать из инклюда готовый темплейт окна при вызове функции или отрисовать с помощью набора функций вызова и отрисовки окна и тд и тп(хотя вроде в jsfx есть нативная функция для меню) . Рано или поздно кто-нибудь задаст вопрос-хочу пилить гуй в другом редакторе и чтобы было по фэншую в WYSIWYG, не знаю возможно ли это(скорее всего да ввиде плагина-утилиты, но на jsfx ресурсозатратно скорее всего, проще на чем-нибудь другом) ,и тогда придётся пилить парсер( грубо говоря считыватель данных о структуре интерфейса из файла разметки элементов(xml, json,txt, toml, придумать свой вариант разметки, etc. ), жалко, что нельзя запускать сторонний процесс для облегчения жизни из jsfx для этих целей(может быть я упустил этот момент из виду), также со временем захочется сделать адаптер для порта в другой формат(uidesc(версия для xml или более новая для json разметки) например для интеграции интерфейса плагина в vst3). Каждый элемент это код, поведение и взаимодействие с пользователем и другой платформой это тоже код.Нюансов очень много, вариантов реализации ещё больше)) .В итоге бошка кипит и нихрена не работает, а если работает,то не так как ожидаешь, а ещё надо оптимизировать и протестировать. Больше всего для разрабов(спорный момент, тк дебаг скромненький по возможностям и скорее для музыкантов-энтузиастов больше) в jsfx бесит встроенный дебагер своим опционалом и информативностью(отсутствие трассировки,замер таймингов,проверки на утечку памяти(вообще не очень ясен момент работы с памятью, т. к инфы ноль, канешна жы губенку я раскатал, но все же капля дёгтя в их сторону, также минус отсутствие типов, хотя язык типизированный) , а вот разделение графики и ДСП очень даже хороший дальновидный шаг со стороны разрабов и отсутствие реализации кроссплатформенности тоже конечно плюс разрабам. Про реализацию самого процессора jsfx ничего не скажу, не знаю, но все равно очень даже ничего, так как в реал тайме возможности скриптов позволяют делать всякие разные выкрутасы со звуком.Где-то может и наврал,где-то фигни сморозил,лучше наверное все же для старта глянуть в код уже готовых инклюдов библиотек(где то видел, точно знаю есть), но все же согласитесь лучше досконально в совершенстве знать свою разработку пусть даже велосипед(сужу по себе по началу такую лапшу и море говнокода кодил), чем пользоваться и недопонимать чужой велосипед(хотя можно и свою разработку через три дня отдыха не признать). В плане концепции реализации: как? процеДурно или в псевдоООПе будем реализовывать код или и то и другое, какие модели(MVC(vst3sdk), или MVVM) .Во я портянку расстянул))) . Вообщем Удачи)))
Ну да. Стиль нашего общения вышел далеко за предела следующего диалога
На первой трети текста, я был ещё на плаву. Потом мозг закипел.
Но "с первых акордов", всё верно, Логика в ваших словах железобетонная.
Этот путь если проходить, то проходить до конца. Потом уже можно будет с закрытыми глазами двигаться. И код будет структурированным и легким.
Другая проблема - вызов пользовательских функций ресурсозатратно, по сравнению с самим кодом. Я с этим столкнулся когда писал Reaspect. Обращение к индексным переменным ресурсозатратно. Поэтому пришлось копипастить код - в итоге он разросся до неприличных от первоначального размеров. НО, потребление ресурсов смог уменьшить чуть ли не 50 раз.
С графикой всё намного проще. Она выполняется максимум 25 раз в секунду, а порой и 12. Отчего зависит - не знаю. Но частота не стабильна. Вопрос решается просто - часы вставляешь в область @Sample и оттуда уже считываешь. Да, несмотря на то что каждая часть кода выполняется отдельно, переменные у них одни. Я один раз столкнулся с тем что у меня начался бардак. Название счетчиков было одинаковым в каждой части кода. Потом просто стал делать разные переменные. С другой стороны, всегда можно обратиться к переменной, которая находится в другой части кода.
Вот и получается что, количество выполнения графического кода как минимум в 2000 раз меньше чем выполнения кода в звуке. Поэтому на оптимизацию можно забить. Структура важнее. Надеюсь удачно подобрал выражение
В общем нужна библиотека, в которой будут описаны функции, они же процедуры, недостающие в самом трансляторе Рипера.
Надеюсь, прочитав ваше сообщение, я вас правильно понял. С глубочайшим уважением. Belovw /Владимир/
Последнее редактирование:
Ну нет и нет)Можно вот так забабахать), регуляторы "обозвать", ну и т.п.,
Посмотреть вложение 218989
, просто предложил) 
(это я про реакцию "
" на "картинку"))))
Последнее редактирование:
Что-то я пропустил уведомление из этой темы.
Но, кстати, так как Dual-mono - это же возврат к истокам и подразумевается, что используется 2 независимых прибора для стерео-компрессии, можно сделать небольшое расхождение параметров т.к. 2 железных прибора не могут быть полностью идентичными. Это тоже внесёт свою лепту в стерео-базу. Поэтому такую версию можно назвать уже не Lite, а типа Standart))
И при этом, иногда на мастере здорово компрессировать только Mid, а сайды оставлять "дышать". Но можно и сайды поджать на инструментах, которые надо либо "сфокусировать" либо "расфокусировать". И вот если можно будет ещё отдельно поджать мид или сайд - это уже широкий компрессор не на минималках, а близкий к максималке, поэтому для полного комплекта я предложил вариант WideComp Extreme.
Stereo - это когда детектор MID (как ты называешь Chan Link=100) и компрессируются оба канала от одного детектора (типа SSL, или он же "клей")
Dual-Mono - это 2 раздельных детектора L и R - оба канала компрессируются независимо.
Mid - детектор MID, и компрессируется только MID (сайды остаются без изменений). Т.е. сначала в цепи MS-Encoder (L+R=mid и L-R=side), компрессор воздействует на Mid-канал, а Side остаётся без изменений. Потом MS-Decoder, в котором Mid+Side=L, Mid+(-Side)=R.
Side - то же самое, что и предыдущий вариант, только компрессор жмёт side-составляющую, а mid остаётся без изменений.
В по поводу того, чтобы сразу компрессировать Mid и Side, если, например, с разными параметрами, наверное тоже так можно. Но, чтобы не менять интерфейс, можно просто сделать переключение, что сейчас редактировать, Mid или Side. Увеличивать интерфейс в 2 раза ради этого точно не стоит.
WideComp Lite - широкий компрессор на минималках) Ведь когда dual-mono - работают два детектора и инструмент звучит шире. Не везде это надо, но звучит шире. А Lite потому, что, с точки зрения расширения стерео-базы, dual-mono - это минимум, что можно сделать.
Но, кстати, так как Dual-mono - это же возврат к истокам и подразумевается, что используется 2 независимых прибора для стерео-компрессии, можно сделать небольшое расхождение параметров т.к. 2 железных прибора не могут быть полностью идентичными. Это тоже внесёт свою лепту в стерео-базу. Поэтому такую версию можно назвать уже не Lite, а типа Standart))
И при этом, иногда на мастере здорово компрессировать только Mid, а сайды оставлять "дышать". Но можно и сайды поджать на инструментах, которые надо либо "сфокусировать" либо "расфокусировать". И вот если можно будет ещё отдельно поджать мид или сайд - это уже широкий компрессор не на минималках, а близкий к максималке, поэтому для полного комплекта я предложил вариант WideComp Extreme.
Ну я ничего особенного не представляю. У меня в голове всё выглядит очень банально.
Stereo - это когда детектор MID (как ты называешь Chan Link=100) и компрессируются оба канала от одного детектора (типа SSL, или он же "клей")
Dual-Mono - это 2 раздельных детектора L и R - оба канала компрессируются независимо.
Mid - детектор MID, и компрессируется только MID (сайды остаются без изменений). Т.е. сначала в цепи MS-Encoder (L+R=mid и L-R=side), компрессор воздействует на Mid-канал, а Side остаётся без изменений. Потом MS-Decoder, в котором Mid+Side=L, Mid+(-Side)=R.
Side - то же самое, что и предыдущий вариант, только компрессор жмёт side-составляющую, а mid остаётся без изменений.
В по поводу того, чтобы сразу компрессировать Mid и Side, если, например, с разными параметрами, наверное тоже так можно. Но, чтобы не менять интерфейс, можно просто сделать переключение, что сейчас редактировать, Mid или Side. Увеличивать интерфейс в 2 раза ради этого точно не стоит.
Последнее редактирование:
Градиенты - это же не скевоформизм)) Скевоморфизм - это имитация физики, реалистичные тени, реалистичный свет, реалистичные объекты и их материалы)
А в примере Олега даж близко нет скевоморфизма) Но есть просто "ужасающий дизайн" и я соглашусь, что так делать не надо)
Последнее редактирование:
Я тоже не понимаю, что за что отвечает. Поэтому, большая просьба к @belovw , подписать все регуляторы так, чтобы даже начинающему фрутилупсеру с первого взгляда было понятно, где что. Даже если на данном этапе будет слишком много текста - это нормально, главное, чтобы люди всё понимали. А пока трудно принести пользу ибо люди не располагают нужной информацией (даже если она где-то и указана - то она сейчас не на макете и это сильно затрудняет понимание идеи дизайна).
Тогда это (мягко скажем) не самая лучшая попытка сымитировать правильные ручки))
так-то, конечно, вальгалла далеко не идеал
но они в своё время выстрелили вот этим сочетанием спартанских интерфейсов и крутых алгоритмов
надо бы память попытать, что ещё есть максимально простенького, но симпатичного
но они в своё время выстрелили вот этим сочетанием спартанских интерфейсов и крутых алгоритмов
надо бы память попытать, что ещё есть максимально простенького, но симпатичного
Да это жопа а не дизайн. Просто там если влить денег хорошо, зайдёт что угодно, хоть каляки-маляки моей племянницы. Так что не стоит равняться на худшее) Вот у PSP например неплохо в плане дизайнерских работ. Но такие работы как у них, проще уже в 3д моделлере делать, чем рисовать это в векторе или растре.