сейчас
@Ostap Fender поднял достаточно насущную проблему. Хотелось бы влыожить рассуждение по ее поводу сюда:
Расположение и работа слайдеров - не та часть, которую надо копипастить.
Надо оставить ровно столько слайдеров, сколько их будет в максимальной комплектации (експрессия, атака, релиз, сустейн, LFO, и т.д.) По одному на параметр.
Не для каждой группы собственные, а в принципе, мы ж типа аналог моделируем? Аналог не будет ручкой вращать от нажатия кнопки.
То-есть для каждого слайдера заведем мини-секцию, отделенную пропусками строк в on init, примерно так:
Код:
on init
declare ui_slider $Attack (0,127,1)
set_control_par(get_ui_id ($Attack),$CONTROL_PAR_MOUSE_BEHAVIOUR,подобрать)
set_control_par(get_ui_id ($Attack),$CONTROL_PAR_DEFAULT_VALUE,0)
set_control_par_str(get_ui_id ($Attack),$CONTROL_PAR_PICTURE,"картинка")
declare ui_slider $Release (0,127,1)
set_control_par(get_ui_id ($Release),$CONTROL_PAR_MOUSE_BEHAVIOUR,подобрать)
set_control_par(get_ui_id ($Release),$CONTROL_PAR_DEFAULT_VALUE,0)
set_control_par_str(get_ui_id ($Release),$CONTROL_PAR_PICTURE,"картинка")
end on
и т.д.
Потом в этой же мини-секции добавить по текстовой переменной, которая будет отвечать за надпись
Потом создать сетку расположения:
условно:
есть базовый х и базовый у. Из этого делается ряд переменных для расположения элементов:
$x_base (изначальное смещение по х)
$x_step (смещение каждого следующего элемента по х)
$x_width (размер кнопки\слайдера по х)
то же самое для у
$y_base
$y_step
$y_height
как минимум по три параметра, иногда надо больше.
А дальше при расположении самих элементов занимается элементарной процедурой сложения-умножения:
move_control_px ($Attack,$x_base+$x_step*3+$x_width*4, $y_base)
этой строчкой ты расположишь элемент в третью ячейку той таблицы, которую организуешь сам.
Таким образом впоследствии мы сможем изменением одной цифры менять все интервалы между контроллерами.
Потом, как и говорил во всех группах за одни и те же параметры должны отвечать одни и те же контроллеры:
во всех группах атака, скажем, будет подчиняться контроллеру 50, а релиз 51
потом в каллбеке on ui_control (переменная слайдера) добавляем команду
set_controller (номер контроллера, переменная слайдера)
Таким образом мы установим атаку во всех группах на уровень слайдера.
С текстом придется повозиться больше всего.
Нужен будет строковый массив (к примеру !Attack_indicator[128]), в котором будет храниться значение для каждого положение контроллера приравненное к ms
Легче всего это сделать так:
Код:
$i := 0
while ($i<128)
!Attack[$i] := максимальное значение атаки в ms \ на 128 * $i
inc ($i)
end while
Далее нужно придумать каким способом у нас будет выводиться текст на виртуальный дисплей.
Самый простой - сделать его в виде ui_label
и простым суммированием текстовых переменных добавлять все надписи. Будет возможно, некрасиво, но просто
Код:
set_text ($indicator, "Attack" & !Attack[%CC[50]])
add_text_line($indicator"Release" !Release[%CC[51]])
При чем, это нужно будет прописать в каллбеке каждого контролера, а так же в каллбеке on init
Более сложный способ - добавление самого окошка в кач-ве картинки и расположение отдельных ui_label со скрытым фоном (hide_part (&Attack_indicator, $HIDE_PART_BG)) как нам хочется. Даст больше гибкости в настройке, но добавит геморроя.
Ну и в довершение работы над слайдерами - прописать все hide_part для тех кнопок на которых они не нужны отдельной функцией, вызываемой из всех каллбеков, или в каждом каллбеке по отдельности. Речь идет о ui-каллбеках кнопок и возможно каллбеке on note
Вообще работа над качественным интерфейсом - самая изнурительная, после нарезки сэмплов.
Искать новые алгоритмы для реализации никем не придуманных функций интересно и здорово; заниматься же постоянным копипастингом собственных формулировок с заменой одной-двух букв, в коде на 3000 строк - уныние.
[DOUBLEPOST=1457590637,1453663022][/DOUBLEPOST]еще одна концепция программирования сегодня всплыла в обсуждении:
Чтобы, скажем, одной ручкой контролировать и dry и wet сигнал конволюции в противофазе, надо сделать так:
Код:
on init
declare $i_invert
declare $i
$i_invert = 127
$i = 0
declare %invert_velocity[128]
while ($i_invert >= 0)
%invert_velocity[$i]:=$i_invert
inc ($i)
dec ($i_invert)
end while
end on
on ui_control ($drywet_slider)
set_engine_par ($ENGINE_PAR_SEND_EFFECT_DRY_LEVEL,%invert_velocity[$drywet_slider]*7874,-1,0,1)
set_engine_par ($ENGINE_PAR_SEND_EFFECT_OUTPUT_GAIN,$drywet_slider*7874,-1,0,1)
end on
при этом то, что я обозвал $drywet_slider должно быть со шкалой 127.
При этом: я добавил коэфицент умножения *7874. Это число получается, если максимальную шкалу engine-параметра разделить на 127. Но, нам же не нужно wet и dry сигналы разгонять до абсурдных значений.
Соответственно, это число должно быть меньше, выводить надо экспериментальным путем, чтобы в положении 0 слайдер выдавал 100% dry сигнала, а в положении 127 - 100% wet-сигнала. Возможно, как раз 1000 подойдет
Вообще очень полезно иметь при себе инвертированную шкалу миди-параметров, я ее использую довольно часто. К примеру, если нужно организовать какой-нибудь специфический кроссфейд. Так же можно создать несколько разных шкал, которые будут расположены по всему диапазону. В общем, стоит подумать о миди-маппинге.
. А контакт какой? Мне еще лень было обновляться на 0.6, а в мануале по 0.4 я такого не нахожу)) Думаю, быстрее будет спросить в 
