Помогите создать экшн / кастом экшн / скрипт

  • Автор темы Автор темы @Michael
  • Дата начала Дата начала
Возможно ли, находясь в медиа эксплорере рипера (например, перебирая сэмплы), запускать экшены из других секций, в частности из секции Main? Например, конкретная задача - воспроизводить/останавливать проект (экшен Transport: play/stop) нажатием на пробел непосредственно из окна медиа эксплорера. PS: насколько понимаю, без скрипта это не решить.

Находим нужный пункт в Экшнс, там где пробел для плэй+стоп. назначаем shift+пробел.

Во всех окнах работают шорткаты с шифтами, альтами, контролами и f1-f12
 
Последнее редактирование:
у меня все скрипты отображаются только в секции Main (это не нормально?)
В какой Section вы находитесь когда скрипту делаете Load - в такой он и отображается. Можно загрузить в несколько.
 
  • Like
Реакции: lil-burn
@EUGEN27771, @Aleksandr Oleynik,
Скрипт от Сегодня, в 14:26 почему-то не работает
то есть:
1. создал скрипт, содержащий строку Main_OnCommand(40044, 0), сохранил как eel.
(40044 - Transport: play/stop)
2. добавил в папку Scripts рипера, загрузил через кнопку Load в секции Media Explorer.
3. нашел этот скрипт в списке экшенов, назначил его на пробел
4. открыл Медиа Эксплорер (в докере), прослушал пару файлов
5. нажал на пробел - результата нет. Вообще.

Более того, скрипт не работает даже через run в окне списка экшенов и даже в окне Midi editor (если добавить его в секцию Midi editor).
Но! Этот же скрипт работает в секции main (если его добавить в эту секцию). То есть написал я его, вроде, правильно.
В чем тогда может быть дело?
________________________________
Причину нашел. Теперь надеюсь, что вопрос исчерпан)
 
Последнее редактирование:
еееее) Скрипт стал работать, но только после того, как удалил его кнопкой Delete из всех секций и загрузил его только в секцию Media Explorer. Не факт, но по ходу все-таки нельзя один и тот же скрипт загружать в несколько секций, иначе будет работать только скрипт в первой секции.
 
Не факт, но по ходу все-таки нельзя один и тот же скрипт загружать в несколько секций, иначе будет работать только скрипт в первой секции.
Может быть и так.Имя поменять не проблема.
====
Есть вопросы другого рода.
Хочу допилить ретроспектив рекорд для АУДИО.
Для МИДИ размер буфера в 2 с лишним миллиона сообщений легко позволяет писать вообще все без разбора(такого вообще вряд ли за целый день наиграешь),поэтому там вопросов нет.
А вот для АУДИО - 8388608 семплов - это всего около 95 секунд стерео в 44100.Это и есть проблема.
И отсюда вопросы:
1)Нужен ли больший буфер для этой функции и нужна ли вообще эта функция конкретно для аудио.
2)Если да,то каким способом лучше реализовать.
Варианты такие:
0)Самый простой(и надежный)-перезапись буфера каждый раз при смене позиции или заполнении,еще,как вариант циклическая перезапись.Но-ограничение 8388608 семплов.
Или при двух JS,на левый-правый канал (8388608)*2 семплов,чуть сложнее.
Более сложное:
1)использовать несколько инстанций JS,включать их последовательно,по мере заполнения.И таким образом можно расширить буфер,у каждого JS-8388608 семплов,потом объединять все в один трек.
Вполне реальный вариант,по крайней мере,в теории.
2)использовать основной,управляющий и распределяющий JS и к нему дополнительные JS как "слоты памяти",но тут нужно разобраться.Этот вариант самый красивый,как мне кажется,и если удастся его реализовать,неограничен никак,можно задавать размер кол-вом "слотов памяти".
3)При заполнении выкладывать заполненный буфер на трек с JS,начинать писать новый и т.д.Непонятно,как оно пойдет в процессе записи и вообще некрасиво.
Короче,кто что-либо может предложить еще,какие идеи.
 
Скидывать буфер в wav файлы определённой длины в указанное место, а потом скриптом по таймингу их выкладывать.
 
Скидывать буфер в wav файлы определённой длины в указанное место, а потом скриптом по таймингу их выкладывать.
Это,видимо,невозможно.Если бы было возможно,то и вопросов не было бы.Насколько я понял,JS может писать "в файл" только через @serialize,и только в файл проекта(боже упаси писать туда мегабайты буферов).И то,это при загрузке эффекта,смене пресета и т.п.А,еще даже такая запись идет с потерей точности.По крайней мере,так написано.Короче,не вариант.
 
@@Michael,у меня уже есть полностью рабочий вариант,и здесь выкладывал,и там выкладывал.
1.gif
Но осталась проблема 8388608-макс. размер буфера.Может Вы предложите какие-то способы?
[DOUBLEPOST=1449002486,1449002145][/DOUBLEPOST]
export_buffer_to_project() также ограничен?
да.
==
Но ему можно подсовывать разные данные,то есть собирать несколькими инстанциями JS,передавать через gmem и расставлять по треку,это пока основной вариант,если не найдется чего-то поинтереснее.Сейчас попробую писать из JS в файл,назло документации(может я что-то неправильно понял),но результат,думаю,предсказуем.
П.С.В файл не пишет,только в файл проекта.
[DOUBLEPOST=1449011987][/DOUBLEPOST]По первому варианту,вот что пока выходит,выглядит устрашающе,но работает:
1.gif
На треке несколько JS(вообще,их может быть сколько угодно).Первый начинает писать сигнал в свой буфер,остальные ждут.Когда буфер первого заполняется,он останавливает запись и передает сигнал на второй,включается второй и т.д. по цепочке.Так можно собрать буфер любой длины.
 
Последнее редактирование:
Женя, какое кол-во JS-ов в общем не важно, важно что для включения режима должен делать пользователь. А он должен нажать кнопку и всё. Если так получится - то ОК
 
8388608 семплов - это всего около 95 секунд стерео в 44100
при 16 битах. А при 24 будет 63 секунды для одного канала. Перемкнуло, сори.В принципе это столько же сколько и у куба.
[DOUBLEPOST=1449072988,1449072713][/DOUBLEPOST]@EUGEN27771, прикольные картинки. Выложил бы свои наработки по этой теме, а то пока выглядит как дразнилка. К стати, у меня тоже имеется собственная работоспособная версия решения этого вопроса, вот только интереса на нашем форуме она почему-то не получила. Мне пока не надо, другим видимо то же - да и бог с ней.
 
Последнее редактирование:
при 16 битах. А при 24 будет 63 секунды для одного канала. В принципе это столько же сколько и у куба.
Не,у нас же ЧИСЛА храняться в буфере(в памяти эффекта),а не АУДИО.
А числа у нас при любых раскладах минимум 32-х битные,потому только от семплрейта и зависит длина файла.
прикольные картинки. Выложил бы свои наработки по этой теме, а то пока выглядит как дразнилка.
Версия с 95-секундным буфером(чисто пробная) уже давно выложена в теме скриптов
ReaScripts (скрипты для Reaper) - делимся ,тоже никому вообще не интересно.
Версию с длинным буфером пока не делал,сам JS выкладываю.
Принцип работы вкратце-на трек вешается несколько этих JS(теоретически,сколько угодно).Когда на трек поступает сигнал,первый JS пишет его в свой буфер,когда его буфер полностью заполниться,он отдает сигнал следующему JS,тот начинает писать в свой буфер и т.д. по цепочке.
Дальше скриптом нужно повытягивать на трек все заполненные буферы из всех JS на нужный трек и все.
PHP:
desc:ForRetroRec(Audio) v20151122
slider1:0<0,1024,1>Slot
slider2:0<-2048,2048,1>Data
slider3:1<0,1024,1>Track Number
slider4:0<0,1,1>Insert Audio
slider5:0<0,4194304,1>Lenght(in samples)
@init
//ext_nodenorm=1;//for check only
ext_noinit=1;
buf=0;
@slider
Track_Num = slider3;
Insert = slider4;
@block
max_i=8388608;
//max_i=44100*2;//for check only

slider5 = Lenght;
@sample
i==0 ? maxsamples = max(abs(spl0),abs(spl1)) * 10^16;//
play_state==0 ? i=0;
play_state==1 && i<=max_i && (maxsamples>10) ? (buf[i]=spl0;buf[i+1]=spl1;
                                                Lenght=i/2;i+=2;);

i>max_i ? (spl0=spl0;spl1=spl1;) : (spl0=0;spl1=0;);

@gfx
Insert==1 ? (Insert=0; i=0; slider4=0;
             export_buffer_to_project(buf, Lenght, 2, srate, Track_Num, 0, tempo););

К стати, у меня тоже имеется собственная работоспособная версия решения этого вопроса
Покажите и свою,может у Вас идеи по-интереснее,может вместе что-то придумаем.
+++
в JS некоторые слайдеры и т.п. не задействованы пока,они будут потом использоваться,так что не обращайте внимания.
 
Последнее редактирование:
Ознакомился. Интересно решил вопрос обхода графической части плагина! Но проблема ограничения длины массива в 8мега слов, думаю заставит нас использовать файлы в качестве буфера. В тоже время, поторюсь, не вижу проблемы ограничения для реализации режима пререкорд аудио аля куб. Для протулсовского панч ин рекорд понадобится больше.

http://rmmedia.ru/threads/119293/

В коде нет защиты от переполнения массива.
 
Последнее редактирование:
тоже никому вообще не интересно.
А это обычное дело..... Когда идёт сравнение с Кубом - все в один голос утверждают, что без ретро спектив рекордс жить нельзя.
А как только появилась такая возможность - интерес к теме пропал.
Я всегда спрашивал - а если хочется что-то записать - не ужели сложно нажать кнопку записи?????
Хотя РЕАЛЬНО вы Евгений сделали инструмент лучше обычной записи - он тупо пишет всё подряд, а вы потом сортируете - нужно, не нужно.
 
думаю заставит нас использовать файлы в качестве буфера
Вопрос в том как писать в файлы?JS пишет через сериалайз только в файл проекта,и то при куче условий,и это неприемлемо.
В тоже время, поторюсь, не вижу проблемы ограничения для реализации режима пререкорд аудио аля куб. Для протулсовского панч ин рекорд понадобится больше.
У меня замысел еще серьезнее,хочу,чтоб писалось вообще все,что звучит на входе и при этом буфер любого желаемого(разумного и даже неразумного) размера.
Собственно,буфер любого размера уже есть,чуть позже покажу более понятно,как это работает.
Спасибо,я смотрел Вашу тему,с нее и начал,кстати,не заработало,покак не поставил кв. скобки buf[ ],только потом понял.
Для протулсовского панч ин рекорд понадобится больше.
А чем он примечателен?Просто никогда не видел,как работает...Может быть и его не сложно сделать
Когда идёт сравнение с Кубом - все в один голос утверждают, что без ретро спектив рекордс жить нельзя.
Да,это точно.Вот и для Аудио скоро сделаем буфер часа на два.Интересно будет.
 
скрылись из-за особенностей синтаксиса форумного движка.

для Аудио скоро сделаем буфер часа на два.
Один вопрос - зачем? Зачем так много?

Думаю вполне можно забить на ограничение размера. В кубе тоже максимум минуту можно писать - проблем с этим нет. У нас с 8мега словами - даже в стерео 1.5 минуты выходит. А пишем в основном моно. Для многоканальной записи )в случае многоканального трека) пререкорд думаю не нужен. Осталось порешать с механизмом переполнения и продумать алгоритм работы. Повторюсь - в моём сейчас используется алгоритм по типу Протулс Панч Ин Рекорд. Это когда запись на буфер начинается с момента старта курсора. Если кнопка записи нажата не была до комманды стоп - ничего не происходит. В противном случае, после остановки можно начала айтема (в ПТ) вытянуть до момента старта. В моём варианте просто апоявляется ещё один айтем.
 
Один вопрос - зачем? Зачем так много?
Спортивный интерес,и я пошутил,конечно,про 2 два часа,сделаю меню,где можно будет указать сколько конкретно нужно.
Осталось порешать с механизмом переполнения и продумать алгоритм работы.
Можно циклическую перезапись,когда всегда остаются только последние полторы минуты.Вообще,можно писать в gmem[](с особым именем,там тоже 8м тогда),как во временный буфер,и порциями скидывать с перезаписью в локальную память buf[].
после остановки можно начала айтема (в ПТ) вытянуть до момента старта
можно и так попытаться сделать,склейка,оффсет и т.п.
Но Ваш вариант ни чем не хуже.Добавьте в скрипт открытие-закрытие окна FX при вставке,чтоб не висело и все.А еще нужно запомнить в JS начальное положение курсора,и скриптом потом считать,чтоб добавлять айтем в конкретную позицию,мало ли как кто курсор поставит или настроит.
=====
Вот с механизмом перезаписи буфера можно поэкспериментировать,там интересно,целое поле для экспериментов.
[DOUBLEPOST=1449091149,1449090906][/DOUBLEPOST]Кстати,
В коде нет защиты от переполнения массива.
ничего с ним не будет,это не массив в принципе,а локальная память,что не влезет-не вставится.
 
  • Like
Реакции: lil-burn
что не влезет-не вставится.
Лучше бы вставилось. Потому что самое начало не факт что нужно. По поводу массивов, независимо от имени, его длина равна 8м слов. Имён может быть много, но массив один и все эти имена, в рамках одного плагина, будут ссылаться на этот массив. Естественно будут иметь место перекрытия диапазонов.

порциями скидывать с перезаписью в локальную память buf[].
Как?
 
Один вопрос - зачем? Зачем так много?
Ну представь себе репу, на которой джемят часто потом прослушивают то, что джемили и джемят под это дело... Очень часто запись не вкшлючается - зачем её включать когда просто идёт репитиционный процесс.
И тут минут через час джема все понимают, что вот 30 минут назад был ИДЕАЛЬНЫЙ вариант, а всё, что после наигрывали - фуфло.
Вспомнить точно уже ни кто не в состоянии.
Понятно, что в следующий раз будут жать REC в начале репы, но через пару часов бесплодных попыток - вытрут это дело и жать опять перестанут.

Если бы программа писала все входа и midi и аудио ничего не спрашивая и чётко запоминала метки начала всех тэйков - разве это не было бы чудом?
 
Лучше бы вставилось. Потому что самое начало не факт что нужно.
Ну тогда циклическая перезапись.
По поводу массивов, независимо от имени, его длина равна 8м слов. Имён может быть много, но массив один и все эти имена, в рамках одного плагина, будут ссылаться на этот массив. Естественно будут иметь место перекрытия диапазонов.
Что описано выше-это касается локальной памяти.Есть еще глобальная-1м по-умолчанию,а если в опциях поставить ей уникальное имя,то 8м.Я думаю,они(локальная и глобальная) не пересекаются,но не проверял и не разбирался.
Вообще,даже без этого,чисто в локальной можно сделать перезапись,memset-memcpy,и технологию найти,это же не супер-редкая операция,с другими данными,наверное,так тоже поступают.
 
Ну представь себе репу, на которой джемят
Саш, вариант из разряда объять необъятное. Ну вот не бывает подключенная DAW к пульту во время репы. На самой DAW репетируют буквально пару команд. Вроде как у Саундроада, но там Куб. Вроде как у тебя, но на репе они (с твоих слов) используют инструменты. Ну пусть твои сейчас репают в ДАВ, ну пусть таких команд 10-20, в рамках мирового масштаба это ничто. Нет ни одной проги которая бы сохраняла всё и вся. А те что есть, всё равно нужно запускать. И если исходить из ситуация ой блин хочу, то в твоём случае это реализуемо, как ещё не понятно, с твоей дотошностью вообще не проблема получить инструмент который будет выполнять эти функции. Можно вообще заставить сохранять на диск всё и вся, а потом раз в пятилетку очищать что по назаписывал. Но опять таки это нужно только тебе.

Мне бы хотелось иметь режим по более чем минута, но даже сейчас мы имеем в моно 3 минуты. Для моих задач - больше и не надо. Но в случае записи квартета или барабанов, конечно будет уже маловато. И тут я вижу два варианта:
1) уломать Джастина сделать масив длинее чем 8м.
2 уломать Джастина сделать человеческий пререкорд
3) написать плагин по типу SWS выполняющий этот самый пререкорд.

Как я и говорил ранее, даже сейчас в режиме панч ин мы с @diggidon пробовали реалиовать через цикл экшены. Засада была в том что циклы сбивались при определённых условиях.
 
Саш, вариант из разряда объять необъятное. Ну вот не бывает подключенная DAW к пульту во время репы. На самой DAW репетируют буквально пару команд. Вроде как у Саундроада, но там Куб. Вроде как у тебя, но на репе они (с твоих слов) используют инструменты. Ну пусть твои сейчас репают в ДАВ, ну пусть таких команд 10-20, в рамках мирового масштаба это ничто. Нет ни одной проги которая бы сохраняла всё и вся. А те что есть, всё равно нужно запускать. И если исходить из ситуация ой блин хочу, то в твоём случае это реализуемо, как ещё не понятно, с твоей дотошностью вообще не проблема получить инструмент который будет выполнять эти функции. Можно вообще заставить сохранять на диск всё и вся, а потом раз в пятилетку очищать что по назаписывал. Но опять таки это нужно только тебе.
Володя, всё это понятно!
Причина по которой это нужно только мне, а вот то - только тебе, в том, что с усложнением функциональности программ о многих функциях люди узнают случайно или вовсе не узнают. По причине сложности использования большей части функционала (требуется какое-то освоение, где минимальное, а где и крепко поломать голову нужно) им пользуются только энтузиасты, которых мы в разделе Рипера хорошо видим.
Чтоб какой-то функцией стали пользоваться - она должна быть одно кнопочной ---- нажал - функция заработала и для того, чтоб всё происходило как нужно, от тебя программа больше ни чего не ждёт, отжал - перестала работать. И всё должно быть на столько продуманно, чтоб не возникло ни каких конфликтов.
Начиная изучать какую-то новую возможность человек должен за очень короткий промежуток времени в ней разобраться и понять - нужна или нет, если на изучение нужно больше 10 минут - для 95% пользователей, которые до сих пор как-то без неё обходились, она будет НЕ НУЖНА!
Я очень долго не мог понять, почему на сложно функциональные программы, типпа Bidule нет вообще толково расписанного мануала - потом понял - Те, кому Bidule интересен или крайне нужен в работе, разберутся и без Мануала, а Мануал не добавит ни одного пользователя сверху, потому как инструмент для энтузиастов и обычными пользователями использован быть не может в этом виде - в нём больше двух кнопок!


PS: Вот применительно к Ретроспектив рекордс лично мне было-бы удобно, если бы -
Я нажал кнопку этого самого RR и прога меня бы попросила - а издайте звук на тех треках, которые вы хотели бы включить в перечень RR, я последовательно или сразу все БРЯКНУЛ бы разок (и Audio и MIDI) и нажал в интерфейсе проги OK - ВСЁ!
Потом, если нажму RR в Off, или если я забуду отжать эту кнопку в Off, при закрытии DAW - RR меня спросит - а чё делать с тем, над чем я так терпеливо час трудилась - и выбор какой-то и OK.
Думаю пользователей при таком функционале прибавилось бы.
Правда обсуждать было-бы совсем нечего - работает и работает :)
 
Последнее редактирование:
  • Like
Реакции: lil-burn
можно ли создать скрипт, который после назначения на него колеса мыши при кручении колеса вниз будет выполнять один экшен, а при кручении вверх - другой?
 
@@Michael, вот решение предыдущего вопроса - милое дело Вторник в 14:26
знай меняй одно число и все) вот так же бы и с этим - менять бы только 2 числа
посмотрел скрипты с использованием get_action_context() - глаза разбегаются от синтаксиса
 
Вот как работает цепочка из 100 буферов:
1.gif
100*8388608 = 9510,9 секунд,2 часа 38 минут в стерео 44100.
В,примере,естественно,я ограничил буферы 1 секундой,но это значения не имеет.
Собственно,ограничений нет вообще,только в кол-ве памяти компьютера,100 буферов поставлено от фонаря,можно и 1000 поставить,если в Рипере нет ограничений по кол-ву эффектов в инсерте,а если есть,можно и это обойти.
Пока это чисто экспериментальный вариант,выкладывает все в одну линию.
Дальше можно сделать запоминание всех позиций,если они меняются и раскладку в соответствии с позициями по тейкам.То есть так же,как я сделал в миди-варианте.
===
Если кому-то интересно.
2.gif
Посэмпловая точность,независимо от кол-ва буферов,места соприкосновения не влияют на звук,все вычитается в ноль.
Единственное,JS не пишет чисто нулевой сигнал,то есть,грубо говоря,абсолютную тишину,ниже шума денормализации.Такого на входе не бывает никогда,поэтому нет смысла,любой вход в сотни тысяч раз шумнее,этот момент и использован,как механизм активации буфера,можно разрешить иначе,но так проще и эффективнее всего.
Еще,обычные 4-8 буферов (380-760 секунд стерео) работают практически моментально,если пугает по скорости первый пример со ста буферами.
 

Вложения

  • 3.gif
    3.gif
    165,2 KB · Просмотры: 278
Последнее редактирование:
  • Like
Реакции: Aleksandr Oleynik
  • Like
Реакции: lil-burn

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