Библиотека масштабируемого векторного интерфейса на jsfx/EEL2 собственными силами. (1 онлайн

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Собственно задача озвучена в названии темы.
Intro--------
Решил попробовать реализовать данную проблему для облегчения написания "морды" при прототипировании, разработке плагинов обработки звука/инструментов/инструментария работы с миди и тд и тп. Уверен на 100% путь будет не лёгким и не лишённым хождения на "костылях", так как при более тесном взаимодействии с проблемой, понимаю, что очень много пробелов в теоретической, практической частях.
----------------
Планируемый функционал библиотеки.[бюрократия)]
1.Разделенный функционал поведения объектов от отрисовки объектов на основе паттерна MVC[реализовано на 20-30%] .
2.Возможность ресайза объектов при изменении размеров вьюпорта. (два режима + статичное масштабирование плагина[scale Mode]+SmallViewMode. [не реализовано только прототип и идея реализации]
3.Обобщенный интерфейс подключения ui к процессорной части(необходимо для разделённого написания части обработки от части управления и дезигна) [реализовано разработчиками, требуется следовать правилам подключения].
4.0. Отдельная разработка дизайна гр. интерфейса плагина на основе темплейта. [не реализовано только описание и алгоритм]
4.1.Утилита по преобразованию юзер дизайн кода в theme/style/partstyle[не реализовано, только для венды из-за отсутствия вменяемой работы с файлами в jsfx]
5.0.FSM(абстрактно а может и нет) система/список состояний объектов.[не реализовано].
5.1.Инструмент для обработки состояний объекта путем отслеживания событий(Observer) [не реализовано, только алгоритм и описание возможно рассмотрение под реализацию для юзера по примеру для облегчения кода].
5.2. Соответственно инструментарий для работы с событиями(подписка на событие, обработка событий, делегирование) [не реализовано]
6.Api4User.[частично реализовано].
7.Атрибуты и свойства объектов[частично реализовано, но не уверен нужен ли данный функционал тк по большей части является костылем]
8.Препроцессорное оборачивание исходного кода(на выбор разработчика ui интерфейса) вне зависимости от секции за исключением участка/части дескриптор плагина. [частично реализовано, только венда]
9.Система версионирования[не реализовано]
10.Статический анализатор для исходного кода(процессорная, контроллерная, графическая часть) [частично реализовано, только венда,в дальнейшем возможно как отдельная опция,а возможно уйдёт в стол, тк это отдельная тема косвенно причастная к элементам графики ]
11.Система рендеринга исходного кода как отдельно подключаемого ui_view(псевдоООП или лист инструкций(бойлерплейт) -библиотечный импортируемый код) либо внедренного кода без всяких зависимостей в плагин(ООП либо лист/блок инструкций). [не реализовано]
----------------
По контролам
1.0. Графический горизонтальный|вертикальныйСлайдер/РотариКноб/Буттон/кикБуттон-автоматизация из вьюпорта[Реализовано]
1.1.Тоже самое только дисплей значений из енвелоп трека к графическом контролу рипера[реализовано] есть нюанс, но это косяк разрабов(не передаются стейты состояний типа доступной автоматизации из рипера в jsfx).
1.2.Все тоже что в п1.0-1.1.XY/XYZ Pad [в разработке частично реализовано]
1.3.StringList[не реализовано]
-----------
По Common и Base.
1.Нормализация дискретного параметра и наоборот[реализовано/спионерено с сайта статистов)].
------------
Документирование по Api третья сторона
Текст-md, rustbook
Схемы-mermaid
_______
П. С. Камрады если есть какие идеи по реализации и предложения рад буду выслушать. С названием библиотеки пока ещё не определился(только один вариант), тоже было бы не плохо выслушать варианты со стороны от сообщества.
________
В планах: здесь в теме буду публиковать шаги и ход реализации, а также варианты использования на примерах(по возможности, без дедлайнов, тк разработка ещё в процессе планирования архитектуры и прототипирования.)
 
  • Like
Реакции: fakeitback и belovw

belovw

Well-Known Member
22 Апр 2009
9.200
8.384
113
50
RK Almaty
1.0. Графический горизонтальный|вертикальныйСлайдер/РотариКноб/Буттон/кикБуттон-автоматизация из вьюпорта[Реализовано]
У меня тоже есть нечто подобное, только не уверен что написано как библиотека - так, функция которая отлавливает мышь и задает значение ручки которую захватил, сброс параметра, тонкая настройка, пристрелка. Причем написать захват круга оказалось проще чем захват прямоугольника - до сих пор не придумал изящного решения.
1.1.Тоже самое только дисплей значений из енвелоп трека к графическом контролу рипера[реализовано] есть нюанс, но это косяк разрабов(не передаются стейты состояний типа доступной автоматизации из рипера в jsfx).
У меня вроде бы работало. Надо проверить.
Возможность ресайза объектов при изменении размеров вьюпорта. (два режима + статичное масштабирование плагина[scale Mode]
Сделал список объектов (только кнобы). В списке название ноба,
начальное, минимальное, максимальное, центральное значение,
позиция, размер (в относительных единицах),
цвет элементов ноба.
При отрисовке само всё масштабируется.
---
Всё остальное для меня как будто на китайском ))
 
  • Like
Реакции: Trasher

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Владимир, курсор(его координаты) я принял как объект (абстрактно) - virtual_hand( чтобы его исключить из схемы тк это уже object_mvc) - - >следовательно во вьюпорте(пустая чёрная область с gfx_x=0,gfxw;gfc_y=0,gfx_h) каждый контроллер(не отображение слайдера) состоит из мультизон(1зона-общая область слайдера, 2зона-область для прыжка хедера(разделена на две зоны контролом хедер) при левом клике и самой области хедера при наведении в которую и нажатии левой кнопки (возможны вариации) начинается движение значений координаты (X-horizontal slider, Y-vertical slider) хедера), все изменения стейтов "отстукивают" в обсервер, в зависимости от стейта контроля, обсервер отстукивает "что надо сделать" - - >в модель приходят значения для процесса проц. части, во вью-->обновление положения координат хедера, те, что мы визуально видим(изменение бошки слайдера), вью отстукивает через обсервер в контрол- - >изменить зону тригера хедер. И так по кругу, но без цикла.Весь механизм) Аналогично с ресайзом, только минусом тянуть все координаты объектов, зон контролов, соотношения к нулевым координатам. Очень много зависимостей. Но срослось).upd потом гифку выложу как работает.
 
Последнее редактирование:

belovw

Well-Known Member
22 Апр 2009
9.200
8.384
113
50
RK Almaty
Очень много зависимостей.
Это я знаю, почувствовал уже. А остальной текст опять на китайском был. ))))
Видимо нужен режим онлайна
Но срослось).upd потом гифку выложу как работает.

Ресайз конечно работает.
Меня тогда захейтили за цвета вырви глаз. А то что механизм поднял то такое.
 
  • Like
Реакции: KikoKentaurus и Trasher

PianoIst

Well-Known Member
19 Май 2010
4.089
4.140
113
29
Kirchberg, kreis Zwickau
soundcloud.com
Это всё равно что пытаться написать на KSP (KONTAKT) Superrior Drummer. Можно, но не нужно.
Посмотрите на любой взрослый или взрослеющий кроссплатформенный VST\CLAP\AU движок на C++, Java, C#, rust ‒ это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.

JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
 
  • Like
Реакции: Greev

belovw

Well-Known Member
22 Апр 2009
9.200
8.384
113
50
RK Almaty
@PianoIst, Тима, при всём уважение, JSFX оказался намного стабильнее и менее ресурсопотребляющим чем VST. Ну и глючащая защита то ещё удовольствие.
JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
Я бы не сказал. Главное алгоритм, а если он есть то его можно реализовать везде. Вопрос в том где он лучше будет работать.
это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.
У меня есть плагины которые были написаны за пару часов и по востребованности находящиеся в топе.
---
Холивар, ок. Прислушался.
 

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Это всё равно что пытаться написать на KSP (KONTAKT) Superrior Drummer. Можно, но не нужно.
Посмотрите на любой взрослый или взрослеющий кроссплатформенный VST\CLAP\AU движок на C++, Java, C#, rust ‒ это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.

JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
@PianoIst давайте по существу, в демагогию не будем углубляться, если есть мысли и предложения - welcome, если другое проходите мимо.Я повторюсь по срокам без дедлайнов.Процесс займёт намного больше времени по реализации чем Вы озвучили в перспективе. Всего хорошего.)
 

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Определяйтесь сами с чего начать. Я с vst3sdk и vstgui начинал обучение тк винда ось и не было ещё clap.Сразу паровозом учите сборку[cmake] , разметку[json, xml]. Языки C, Cpp весь исходный код на них. Паттерны проектирования тоже надо и в ооп уметь(в встсдк соглашение:при реализации расширенного класса наследуется только один класс и необходимое количество интерфейсов(почти как в шарпе) . Про AU не скажу не знаю. В clap и vst3sdk есть интерфейсы на нейтив си. По VST3 нужно посмотреть еще COM. Vstgui ещё для мордофейса правда в основном растрового, для вектора третья сторона. )) Есть и другие пути.
 
  • Like
Реакции: belovw

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Как думаете, сколько времени уйдёт что бы всё это освоить?

Например
Честно я не могу ответить на этот вопрос, но Владимир если вы прогаете на jsfx, значит си вы уже знаете, а это уже 60% успеха). Первое на что я наткнулся не смог собрать решение для визуал студии из-за незнания cmake(в ютубе есть пример как собрать решение). Посмотрите сайт utsbox.com по vst3 у штайнов на гите есть справка интерактивная не плохая, ну и документация в самой сдк. Учтите нужны сертификат разраба если на визуал студии будете делать и лицензионное соглашение со штайнбергами для коммерции. В Clap по-проще там если не подводит память-MIT.
Про другие пути - - >Juce.
 

Trasher

Well-Known Member
12 Янв 2013
603
422
63
В общем те ещё терни.
Писать Вы можете, но по соглашениям вроде как только в opensource. )) Jsfx вид сбоку. В Juice до 50000$ в год для сингла, но это не отменяет соглашений озвученных выше)) , в clap можно по-моему, давно не интересовался этим вопросом если честно, могу и дезориентировать.) Вам лучше поинтересоваться у осведомленных в этом вопросе людей.Как-то так.
 

fractala

Well-Known Member
1 Авг 2012
2.416
998
113
Друзья, сори за небольшой оффтоп, подскажите пожалуйста какие либо миди библиотеки, наработки, ресурсы/ссылки как это вообще работает, откуда начать копать. Изучаю шарпы (c#), в качестве так сказать студенческого первого пет проекта хочу запилить простенький редактор для работы с железным синтезатором по миди (отправка и прием midi cc, ну может еще не сложных sysex ) сообщений.
Хочу оконное приложение сделать
 

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Друзья, сори за небольшой оффтоп, подскажите пожалуйста какие либо миди библиотеки, наработки, ресурсы/ссылки как это вообще работает, откуда начать копать. Изучаю шарпы (c#), в качестве так сказать студенческого первого пет проекта хочу запилить простенький редактор для работы с железным синтезатором по миди (отправка и прием midi cc, ну может еще не сложных sysex ) сообщений.
Хочу оконное приложение сделать
NAudio
 
  • Like
Реакции: fractala

Trasher

Well-Known Member
12 Янв 2013
603
422
63
Думал, думал и придумал:как вариант для кроссплатформы использовать cmake в режиме скрипта(тулза) вместо анси си(мака у меня нет и не умею). Функционал такой же как на си реализация не много будет отличаться(оборачивание в макрос пункт 8[пока энкод] ) -? Стоит ли? Или фигня. Следующий вопрос сообществу-версионирование cal(endar) versioning(тк очень просто реализовать в отличии от SEMVER, формат ver - YYYY. MM)? Статический анализ пока непонятки. Где разместить исходники[в перспективе] ? (склоняюсь к бусти "пока в промо", чтобы не отпугнуть интересующихся)... или по запросу в личку, ваши варианты....(гит/хаб/лаб не особо хочется в связи с отсутствием опыта использования и дальнейших возможных траблов по независящим причинам, может собьянинский мосхаб)) ) Спс.
 
  • Like
Реакции: belovw

Trasher

Well-Known Member
12 Янв 2013
603
422
63
-------
[п. 8]Возникли <незначительные стопорА> [А] Определение максимального размера одного "физического" файла плагина/библиотеки(без включения импортов). Кто-нибудь может подкинуть идею? Склоняюсь к max размеру в 34Mb на файл.Поясню, максимальный буфер для одного блока препроцессора 4Kb( те для плага в макс. размере=34 Mb минразмерфайлпрепроца=длина строки дескриптора+8500 блоков в каждом блоке по 4000 именованных параметров+'=*4000' +значение в hex*4000+'separator'*4000+ строка формата%x*4000 и функции принта[одна на блок] (портянка ещё та или ....меньше сделать?по итогам тестирования скорее всего ) ) ,также разработаны два режима работы (cmake в режиме скрипта) для разбивки на препроцессорные блоки:оба режима псевдослучайны.1режим бьёт исходный текст на блоки (чем меньше размер буфера блока, тем больше блоков препроцессора) от 32b-4K вне зависимости от размера исходника файла. 2.режим бьёт на блоки исходя из размера исходного текста...Если плаг маленький по размеру и нужно разбить с большим количеством блоков можно бить на блоки 1режимом,но если большой( как пример super8=11kb) лучше/предпочтительно бить во 2режиме(маленький по размеру плаг также бьётся с минимальной разбивкой на блоки) .Загвоздка в том, что при разбитии на препроцессорные блоки, также происходит автоименование параметра и генерация строк формата и принта. Имя на данный момент генерится и состоит из префикса+номера_блока(задекорирован) +индекса_позиции в блоке(декоратор-hex значение только в буквенной подстановке для облегчения сбора инфы), значение параметра hex_value.В итоге чем больше размер плага - - >тем длиннее имя параметра-->больше разновидностей вариантов анализа(что ни есть очень хорошо.Анализ <имени параметра> производится средствами regex в cmake, не очень хотелось, но тут пока без вариантов).Боюсь, что в итоге можно(велика вероятность) "схлопотать" плохо отслеживаемую коллизию по имени параметра в блоке.Может быть есть у кого идеи по автоименованию параметра с учётом того, что разработка ведётся в cmake или <тупо рандомно генерить строку> определённой длины с индексом позиции и удалять дубликаты имён в списке параметров в блоках препроцессора. Также, как мне думается модуль декодирования делать не буду(у разработчика сырые исходники и так есть в наличии).
-----------
Непосредственно по библиотеке ui(пока не густо) реализован первый элемент отвечающий за компоновку(layout) - canvas.(процеДурно).
-----------
Элементы свитч/стринг_лист-скорее всего по умолчанию будут только двухпозиционный_свитч и также стринг_лист с двумя значениями(в библе по умолчанию). Расширение (свитч до 40 положений процедурно в принципе аналогично как в ni reaktor5) и стринг_листа за юзером путем генерации юзер-компонента(расширение библы) через модуль в cmake(но будем посмотреть).
-----------
Пока не получается(попытка была, но неудачная также процедурно) отрисовка простой фигуры(без заливки) как в svg - - пример-->pnt_A(0,10);down(20);left(8);etc....
----------
Спс.
 
Последнее редактирование:

Сейчас онлайн (Пользователей: 0, Гостей: 1)