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

  • Автор темы Автор темы Trasher
  • Дата начала Дата начала
Trasher

Trasher

Well-Known Member
12 Янв 2013
643
452
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
Trasher написал(а):
1.0. Графический горизонтальный|вертикальныйСлайдер/РотариКноб/Буттон/кикБуттон-автоматизация из вьюпорта[Реализовано]
Нажмите для раскрытия...
У меня тоже есть нечто подобное, только не уверен что написано как библиотека - так, функция которая отлавливает мышь и задает значение ручки которую захватил, сброс параметра, тонкая настройка, пристрелка. Причем написать захват круга оказалось проще чем захват прямоугольника - до сих пор не придумал изящного решения.
Trasher написал(а):
1.1.Тоже самое только дисплей значений из енвелоп трека к графическом контролу рипера[реализовано] есть нюанс, но это косяк разрабов(не передаются стейты состояний типа доступной автоматизации из рипера в jsfx).
Нажмите для раскрытия...
У меня вроде бы работало. Надо проверить.
Trasher написал(а):
Возможность ресайза объектов при изменении размеров вьюпорта. (два режима + статичное масштабирование плагина[scale Mode]
Нажмите для раскрытия...
Сделал список объектов (только кнобы). В списке название ноба,
начальное, минимальное, максимальное, центральное значение,
позиция, размер (в относительных единицах),
цвет элементов ноба.
При отрисовке само всё масштабируется.
---
Всё остальное для меня как будто на китайском ))
 
  • Like
Реакции: Trasher
Владимир, курсор(его координаты) я принял как объект (абстрактно) - virtual_hand( чтобы его исключить из схемы тк это уже object_mvc) - - >следовательно во вьюпорте(пустая чёрная область с gfx_x=0,gfxw;gfc_y=0,gfx_h) каждый контроллер(не отображение слайдера) состоит из мультизон(1зона-общая область слайдера, 2зона-область для прыжка хедера(разделена на две зоны контролом хедер) при левом клике и самой области хедера при наведении в которую и нажатии левой кнопки (возможны вариации) начинается движение значений координаты (X-horizontal slider, Y-vertical slider) хедера), все изменения стейтов "отстукивают" в обсервер, в зависимости от стейта контроля, обсервер отстукивает "что надо сделать" - - >в модель приходят значения для процесса проц. части, во вью-->обновление положения координат хедера, те, что мы визуально видим(изменение бошки слайдера), вью отстукивает через обсервер в контрол- - >изменить зону тригера хедер. И так по кругу, но без цикла.Весь механизм) Аналогично с ресайзом, только минусом тянуть все координаты объектов, зон контролов, соотношения к нулевым координатам. Очень много зависимостей. Но срослось).upd потом гифку выложу как работает.
 
Последнее редактирование:
Trasher написал(а):
Очень много зависимостей.
Нажмите для раскрытия...
Это я знаю, почувствовал уже. А остальной текст опять на китайском был. ))))
Видимо нужен режим онлайна
Trasher написал(а):
Но срослось).upd потом гифку выложу как работает.
Нажмите для раскрытия...
218969

Ресайз конечно работает.
Меня тогда захейтили за цвета вырви глаз. А то что механизм поднял то такое.
 
  • Like
Реакции: KikoKentaurus и Trasher
Это всё равно что пытаться написать на KSP (KONTAKT) Superrior Drummer. Можно, но не нужно.
Посмотрите на любой взрослый или взрослеющий кроссплатформенный VST\CLAP\AU движок на C++, Java, C#, rust ‒ это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.

JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
 
  • Like
Реакции: Greev
@PianoIst, Тима, при всём уважение, JSFX оказался намного стабильнее и менее ресурсопотребляющим чем VST. Ну и глючащая защита то ещё удовольствие.
PianoIst написал(а):
JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
Нажмите для раскрытия...
Я бы не сказал. Главное алгоритм, а если он есть то его можно реализовать везде. Вопрос в том где он лучше будет работать.
PianoIst написал(а):
это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.
Нажмите для раскрытия...
У меня есть плагины которые были написаны за пару часов и по востребованности находящиеся в топе.
---
Холивар, ок. Прислушался.
 
PianoIst написал(а):
Это всё равно что пытаться написать на KSP (KONTAKT) Superrior Drummer. Можно, но не нужно.
Посмотрите на любой взрослый или взрослеющий кроссплатформенный VST\CLAP\AU движок на C++, Java, C#, rust ‒ это будет гораздо легче в перспективе хотя бы разработки длиной в месяц-полтора.

JSFX ‒ для плагина на коленке ПРЯМОЩАС, или для чего-то несложного по памяти.
Нажмите для раскрытия...
@PianoIst давайте по существу, в демагогию не будем углубляться, если есть мысли и предложения - welcome, если другое проходите мимо.Я повторюсь по срокам без дедлайнов.Процесс займёт намного больше времени по реализации чем Вы озвучили в перспективе. Всего хорошего.)
 
belovw написал(а):
какого?
Нажмите для раскрытия...
Определяйтесь сами с чего начать. Я с vst3sdk и vstgui начинал обучение тк винда ось и не было ещё clap.Сразу паровозом учите сборку[cmake] , разметку[json, xml]. Языки C, Cpp весь исходный код на них. Паттерны проектирования тоже надо и в ооп уметь(в встсдк соглашение:при реализации расширенного класса наследуется только один класс и необходимое количество интерфейсов(почти как в шарпе) . Про AU не скажу не знаю. В clap и vst3sdk есть интерфейсы на нейтив си. По VST3 нужно посмотреть еще COM. Vstgui ещё для мордофейса правда в основном растрового, для вектора третья сторона. )) Есть и другие пути.
 
  • Like
Реакции: belovw
belovw написал(а):
Как думаете, сколько времени уйдёт что бы всё это освоить?

Например
Нажмите для раскрытия...
Честно я не могу ответить на этот вопрос, но Владимир если вы прогаете на jsfx, значит си вы уже знаете, а это уже 60% успеха). Первое на что я наткнулся не смог собрать решение для визуал студии из-за незнания cmake(в ютубе есть пример как собрать решение). Посмотрите сайт utsbox.com по vst3 у штайнов на гите есть справка интерактивная не плохая, ну и документация в самой сдк. Учтите нужны сертификат разраба если на визуал студии будете делать и лицензионное соглашение со штайнбергами для коммерции. В Clap по-проще там если не подводит память-MIT.
Про другие пути - - >Juce.
 
belovw написал(а):
В общем те ещё терни.
Нажмите для раскрытия...
Писать Вы можете, но по соглашениям вроде как только в opensource. )) Jsfx вид сбоку. В Juice до 50000$ в год для сингла, но это не отменяет соглашений озвученных выше)) , в clap можно по-моему, давно не интересовался этим вопросом если честно, могу и дезориентировать.) Вам лучше поинтересоваться у осведомленных в этом вопросе людей.Как-то так.
 
Друзья, сори за небольшой оффтоп, подскажите пожалуйста какие либо миди библиотеки, наработки, ресурсы/ссылки как это вообще работает, откуда начать копать. Изучаю шарпы (c#), в качестве так сказать студенческого первого пет проекта хочу запилить простенький редактор для работы с железным синтезатором по миди (отправка и прием midi cc, ну может еще не сложных sysex ) сообщений.
Хочу оконное приложение сделать
 
fractala написал(а):
Друзья, сори за небольшой оффтоп, подскажите пожалуйста какие либо миди библиотеки, наработки, ресурсы/ссылки как это вообще работает, откуда начать копать. Изучаю шарпы (c#), в качестве так сказать студенческого первого пет проекта хочу запилить простенький редактор для работы с железным синтезатором по миди (отправка и прием midi cc, ну может еще не сложных sysex ) сообщений.
Хочу оконное приложение сделать
Нажмите для раскрытия...
NAudio
 
  • Like
Реакции: fractala
Думал, думал и придумал:как вариант для кроссплатформы использовать cmake в режиме скрипта(тулза) вместо анси си(мака у меня нет и не умею). Функционал такой же как на си реализация не много будет отличаться(оборачивание в макрос пункт 8[пока энкод] ) -? Стоит ли? Или фигня. Следующий вопрос сообществу-версионирование cal(endar) versioning(тк очень просто реализовать в отличии от SEMVER, формат ver - YYYY. MM)? Статический анализ пока непонятки. Где разместить исходники[в перспективе] ? (склоняюсь к бусти "пока в промо", чтобы не отпугнуть интересующихся)... или по запросу в личку, ваши варианты....(гит/хаб/лаб не особо хочется в связи с отсутствием опыта использования и дальнейших возможных траблов по независящим причинам, может собьянинский мосхаб)) ) Спс.
 
  • Like
Реакции: belovw
-------
[п. 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....
----------
Спс.
 
Последнее редактирование:
Войдите или зарегистрируйтесь для ответа.

Сейчас просматривают

Всего: 1 (пользователей: 0, гостей: 1)
Сверху Снизу