Archie-reascript: обсуждение, пожелания, сообщения об ошибках.

@Archchie, а возможно такое действие: рендериться трек с цепочкой плагинов, но аудио файл не создаётся, а переписывается/дописываются только пики в reapeaks? По типу как дописываются Spectral peaks в файлы reapeaks, или что то наподобие...

Очень важно наблюдать какое воздействие на файл совершает цепочка плагинов и при этом не убивать время на рендер самого аудио файла (смещение фазы, прямоугольник и т. п.). В некоторых DAW это реализовано...
 
Последнее редактирование:
Типа как в кубе сделали ?
Неа я не знаю как это сделать.
 
Типа как в кубе сделали ?
Неа я не знаю как это сделать.
Ну да, только в кубе, как я понял, на файл, а не на весь трек (наподобие как в Reaper на айтем FX применяется)... "Летающую в воздухе" идею Штейны поймали... Куча проблем с живыми инструментами порой происходит (после FX), а на слух это не вычисляется.

Приходилось, и не раз, просто рендерить, только лишь для того что бы посмотреть где косяк - а он появляется только в определённый момент изменения параметров - это сколько раз рендер нужно было делать...

Жаль... Хорошо когда ты "знаешь как это сделать". Вдруг придёт идея?:Dle87:
 
Последнее редактирование:
@Archchie, интересно, а вот есть такой скрипт - типа запрет на действие?
Просто бывает так, что в какой то последовательности действий происходит конфликт и было бы не плохо иметь возможность не позволяющую срабатывать экшену или скрипту в определённой ситуации...
Можно привести и конкретные примеры, да и не у одного меня, возможно, такое случается. Reaper чрезмерно "свободен", а другие DAW не позволяют совершать те или иные ошибочные действия, которые могут привести к конфликту (я не баги имею в виду).

п. с. при больших возможностях у Reaper мало прав на ошибку...
 
Последнее редактирование:
Привет, Арчи. Столкнулся со странной особенностью в функционировании твоих последних скриптов "Duplicate selected events to mouse position (snap relative)" и "Move selected events (snap relative). В наcыщенном проекте эти cкрипты cрабатывают c заметным опозданием. Порой приходитcя ждать неcколько cекунд.

Как например в этой гифке внизу.


Все другие хоткеи / экшны/ скрипты в проекте срабатывают моментально.

Как думаешь, с чем это может быть связано и возможно ли подправить код?
 

Вложения

  • Duplication issue.gif
    Duplication issue.gif
    158,8 KB · Просмотры: 391
В версии 5.983 некоторые скрипты стали работать с артифактами - медленнее чем штатные экшены в кастоме. Что то с графикой - могу прислать видео . Твои скрипты работают как надо...
 
Привет, Арчи. Столкнулся со странной особенностью в функционировании твоих последних скриптов "Duplicate selected events to mouse position (snap relative)" и "Move selected events (snap relative). В наcыщенном проекте эти cкрипты cрабатывают c заметным опозданием. Порой приходитcя ждать неcколько cекунд.
Как думаешь, с чем это может быть связано и возможно ли подправить код?

К сожалению да, присутствует задержка если в тейке очень много нот (более 500 уже заметная), связанно это с тем, что скрипт удаляет все ноты и прописывает все ноты в тейке по новой, если этого не делать, то с нотами происходят какие то странности, они (иногда некоторые из нот) то удлиняются во весь тейк, то вообще пропадают куда то.
Есть еще другая функция, которая работает со всеми нотами, но к сожалению я не знаю как с ней работать, да и за ней вроде как тоже замечались баги с исчезновением. Так что я к сожалению не знаю как это исправить. Sorry.


@Archchie, интересно, а вот есть такой скрипт - типа запрет на действие?
Просто бывает так, что в какой то последовательности действий происходит конфликт и было бы не плохо иметь возможность не позволяющую срабатывать экшену или скрипту в определённой ситуации...
Моя, твоя не понимать)).
В каком смысле запрет на действие ?
В рипере нету искусственного интеллекта и скрипту надо четко и подробно объяснять, что ему делать.


@Archchie, Подскажи, реально сделать такой в идентичности Zoom и с фоновыми светящимися кнопками? Первый на фул проект(W)вертикальный,второй на зум треков(H)горизонтальный.Кнопки горят до тех пор,пока не произошло следующее зуммирующее действие,т.е всегда можно возвратиться к предыдущему варианту.В Рипере почему то зум треков,происходит по порядку как undo,мне нужно чтоб возвращались в исходное состояние все прозумированные треки.И вполне возможно что такие скрипты уже есть,но чтоб кнопки светились... врядли.

W / H - Вроде как ты и хотел.
Arc_View; Zoom height full project - recover back.lua
Arc_View; Zoom width full project - recovery back.lua
 
Последнее редактирование:
  • Like
Реакции: Krikets
К сожалению да, присутствует задержка если в тейке очень много нот (более 500 уже заметная), связанно это с тем, что скрипт удаляет все ноты и прописывает все ноты в тейке по новой, если этого не делать, то с нотами происходят какие то странности, они (иногда некоторые из нот) то удлиняются во весь тейк, то вообще пропадают куда то.
Есть еще другая функция, которая работает со всеми нотами, но к сожалению я не знаю как с ней работать, да и за ней вроде как тоже замечались баги с исчезновением. Так что я к сожалению не знаю как это исправить. Sorry.

А можно перехитрить / обойти это недоразумение прописав в том же скрипте предварительную разбивку тейка на несколько айтемов поменьше, и затем их обратную склейку после выполнения основной функции: то есть копирования нот?
 
да и за ней вроде как тоже замечались баги с исчезновением. Так что я к сожалению не знаю как это исправить. Sorry.
Если понимать как работает MIDI, то всё хорошо работает. Багов быть там не может, так как там сырая инфа без постобработкки рипером.
 
  • Like
Реакции: Archie's
А можно перехитрить / обойти это недоразумение прописав в том же скрипте предварительную разбивку тейка на несколько айтемов поменьше, и затем их обратную склейку после выполнения основной функции: то есть копирования нот?
Нет, это будет еще дольше, потому как ладно разрезать - это быстро, а вот что бы склеить, надо сделать следующее, просканировать все айтемы, запомнить всю их информацию, удалить их, создать новый большой айтем и запихнуть в него все инфу.

@Antibio, Обновил. С горем пополам. Функцию позаимствовал у @@Michael, (думаю @@Michael не будет против)

Багов быть там не может, так как там сырая инфа без постобработкки рипером.
Не не может, а не должно быть, но они есть.
В рипере как я понимаю миди редактор изначально написан через ж..., там даже все стандартные экшены работают с багами.
Вот наложи ноты одна на другую примерно так
167019
(это три ноты) и попробуй любую из них скопировать, не важно как, хоть стандартным экшеном (ctrl+c), хоть скриптом сделанным из S/GetAllEvts, результат будет один и тот же, нота скопируется, а остальные (не эти три, а во всем проекте, где есть такое наложение) сломаются, про S/GetNote вообще молчу - что они вытворяют, ладно экшены / скрипты, наложи их так и закрой - открой миди редактор и ты обнаружишь что они сломаны, т.е у них длина изменится.

По поводу MIDI_ S/GetAllEvts ты ее всю распаковал в таблицу (ParseRAWMIDI) и там вроде все стало понятно, да и в принципе ей можно уже пользоваться, думаю там больше нет никакой информации и для всех целей ее будет достаточно.
А вот с запаковкой вообще ничего не понял, почему в первом pack четыре параметра, т.е. три, как и описано в S/GetAllEvts, а во втором pack 6 параметров и почему ключи разные(i4Bs4), как их подбирать вообще?
Код:
    local str_per_msg = string.pack("i4Bs4", new_ppq-last_ppq, data[i].flags, data[i].msg1);  
    local str_per_msg = string.pack("i4Bi4BBB", new_ppq-last_ppq, data[i].flags, 3, data[i].msg1:byte(1), newPitch, data[i].msg1:byte(3));
Откуда ты берешь вот эти цифры :byte(1)>>4 == 0x9 ?
Есть ли где нибудь какая нибудь инфа по этому поводу как хранятся миди в рипере и как вообще этим пользоваться, что бы об этом почитать?
 
Последнее редактирование:
@Krikets, "H/W" Обновил.
Убрал мерцание с кнопок.
В "W" добавил "time selection" по умолчанию и убрал сброс сохранения при скролле (внутри все регулируется)
В "H" добавил выделенные треки.
Т.е. если не выделено не одного трека, то зумятся все треки - как и было.
Если выделен один, то он один увеличится в размер экрана.
Если выделено несколько, то в зуме будут участвовать треки от первого выделенного и до последнего выделенного.
 
Ну да.Но заметил такую штуку.Рядом поставил идентичный экшн.И когда нажимаю 1- ую кнопку,то она мерцает,а рядом стоящая 2ая, работает как полагается.И если идти от обратного,то происходит все в точности до наоборот.Необъяснимо но факт).Нужно,чтоб еще кто затестил.Может это у меня баги какие.
 
Рядом поставил идентичный экшн.И когда нажимаю 1- ую кнопку,то она мерцает,а рядом стоящая 2ая, работает как полагается.
В каком смысле "идентичный экшн".
После обновления скрипта рипер перезагружал? т.к. это автоматические скрипты и после обновления скрипта перезагрузка рипера обязательная процедура. Потому как у тебя продолжает работать старая версия, я этого не учитывал в прошлой версии, что бы новая версия ломала старую, в этой версии учел, теперь каждый новый запуск будет ломать предыдущую сесию
 
Последнее редактирование:
@Archchie, Перегружал.Но выявил вот что.У меня эти кнопки были,в 1ом тулбаре.И там они так и работают подмигивая.Но я попробовал закинуть их в другой тулбар (плавающий) и там все норм...В чем может быть причина,они мне нужны именно там,в 1-ом главном тулбаре
 
@Archchie , Читай про стандартный midi протокол (в рипере от стандартного он отличается наличием флагов selected/muted), это ответ на все вопросы касаемо кода и твоего непонимания происходящего по копировании. По части рипера - экшн options Correct overlapping notes while editing в MIDI editor.
 
Последнее редактирование:
  • Like
Реакции: Archie's
@Krikets, Починил версия 1.02 Если в прошлой версии перезагружал рипер, то перезагрузка теперь необязательно.

По части рипера - экшн option overlapping notes в MIDI editor.
Про этот экшен знаю, и он тоже некорректен
В случае с таким же наложением
167027
я должен получить вот такой результат
167029
а получу вот такой
167030
Вторая нота пропадет.
Читай про midi протокол, это ответ на все вопросы касаемо кода.
Спасибо! Поищу.
 
В случае с таким же наложением
167027
я должен получить вот такой результат
167029
Так это баг скрипта, а не режима коррекции) Не могу проверить, приаттач скрипт в тред.

Хотя вот вроде всё логично и правильно:
1.gif
 
Ну - у тебя так же. Когда ты маленькую ноту вставил в середину, то середина должна вырезаться, а две ноты остаться. Правильно?
Т.е. вырезается вся правая часть, а не середина, как должно быть.
167033
 
Нет, не правильно. Было две ноты, а должно стать три?
При перемещении порядок получается следующий:
(1) NoteOn
(2) NoteOn
(2) NoteOff
(1) NoteOff

После второго пункта рипер не понимает какую ноту закрывать, для предупреждения таких ситуаций и придумали режим, который убивает overlapped notes и делает следующее:
(1) NoteOn
(1) NoteOff и тут же (2) NoteOn
(2) NoteOff
 

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