Коллеги, реально нужна ваша помощь и вдумчивое прочтение того, что я сейчас напишу. Нужны советы, естественно аргументированные и обдуманные.
Я не могу принять решения (выбрать какое будет компромисно - правильным и перспективным).
Речь идёт о функциональной схеме реализации Инструментального Стэка в том виде, в котором по максимуму я бы хотел его видеть.
По сколько я в первую очередь хочу сделать так, чтобы при переключении любых Пресетов не происходило ни каких, даже малейших подрывов звука, то кросфэйд между одним выстроенным звучанием и другим - единственно возможное решение. Я внимательно изучил как реализованны во многих программах все возможные операции со звуком в во время его звучания (имею в виду Мюты, Байпасы, Соло там и прочее) и везде где это решено без щелчков в звуке - стоит кратковременный, несколько мс, но фэйд.
А вот как реализовывать перебор этих самых Пресетов через Фэйд так чтоб это было удобно не только пользовать, но и настраивать, чтобы это решение жрало как можно меньше ресурсов компа - вот тут не всё так однозначно и ясно, как мне казалось в начале, до того как я один из вариантов решил полностью, а второй довёл почти до работающей Бэтты.
Я изложу три найденных мной варианта и прошу вдумчиво их изучить и помочь с выбором по которому дальше пойти.
Сначал хочу обсудить подход - что берём во внимание, что для кого является важным, а что второстепенным.
Для меня в порядке важности (1-самый важный) это вот так -
1. Максимальное качество звука на выходе, никаких артефактов при переключении.
2. Максимально удобное использование уже запрограмированного Стэка.
3. Переключение Пресетов в произвольном порядке, с любой скоростью.
4. Минимально возможные требования к мощности компа, т.е. предпринять все возмжные ухищрения, чтобы ресурсов такое решение отбирало как можно меньше.
5. Максимально удобное програмирование Стэка.
ну вот у меня Максимально удобное програмирование Стэка на 5-ом месте, а я понимаю, что для тех, кто не создавал этот самый Стэк, этот пункт будет на втором или даже на 1-ом месте.
Итак варианты решения -
1. Тот вариант, который я уже реализовал в Рипере с написанными под негог несколькими плагами -
http://forum.rmmedia.ru/showthread.php?t=105767
Изначально решил сделать понятную схему - Каждый Пресет это по сути расположенная на отдельном Треке обработка, которая может состоять из любого кол-ва последовательных и паралельных плагинов.
Переключение между Пресетами-Трэками - это на каждый трэк, настраиваемый по длительности и форме кривой, кросфэйд. Отдельно трек для входа инструмента (на нём все стабильно не меняющиеся обработки - ну преамп какой-нить любимый, EQ с обрезными фильтрами, возможно один раз отстроенный Гейт). Отдельно выходной Трэк - который в общем используется как Фэйдер для управления уровнем громкости инструмента в миксе. Есть ещё трэк Управления этим Инструментальным Стэком, на который подключаются внешние миди управлялки и на котором стоит спец плаг управляющий всем Стэком в целом.
Собственно в такой Стэке настройка его сводится к настройке каждого Трэка-Пресета на звучание в той или другой части композиции, а переключение - подача сигнала на переход звука с одного Трэка Пресета на другой.
Мне показалась такая схема очень наглядной и понятной и простой и в програмировании и в использовании.
Но у такой схемы есть один существенный недостаток - к примеру я исользую для Гитарной обработки всегда Один ТОЛЬКО Amplitube, понятно, что с разными настройками. и получается так, что мне прийдётся создать столько Треков-Пресетов, сколько разных звуков из Amplitube я хочу получить за одну композицию - в среднем это около 10, да и Берингеровская ножная миди педаль имеет в одной закладке 10 кнопок.
Значит мне прийдётся установить 10 Amplitube - По каждому на один свой Трек-Пресет и каждый настроить на свой звук.
Но я тут-же увеличиваю нагрузку на Процессор ровно в 10 раз больше по сравнению с одним Amplitube, который трещит при переключении пресетов, у которого нет никаких кросфэйдов при переключении, но в 10 раз меньше жрёт!
Вторая проблема - это в 10 раз больше грузим память компа.
С первой проблемой я справился - управляющий Стэк-ом плагин выводит все Плагины на не использующихся в момент игры Трэках-Пресетах в Байпас, что снимает тут-же нагрузку с процессора - т. е. в моём СТЭК-е в работе находится одновременно не более двух линеек плагинов в двух Треках-Пресетах на которых происходит переключение с одного на другой.
А вот с памятью - НИКАК, так как чтобы выгрузить плаг из памяти, его нужно вывести в Офлайн (а не Байпас). В Рипере можно плаг и в Офлайн легко дистанционно увести, и происходит это быстро, но вот поднять его потом из офлайна - всё равно, что по новой загрузить плагин - долго и пиковая нагрузка возрастает. Т.е. если переключатся между двумя Треками-Пресетами на которых одна из линеек плагинов в офлайне - будет ОЧЕНЬ долго и просто не приемлимо.
Значит проблема Памяти в этом варианте остаётся не решаемой - просто миримся с этим и смотрим, чтобы при 32Bit приложении она была рассредоточена по разным открытым блокам процессов, что в Рипере ВОЗМОЖНО, а вот в Bidule- я такого не нашёл, как в прочем и офлайна для конкретно выбранного плага.
2. Второй вариант я практически реализовал в Bidule и споткнулся, чуть дальше поясню на чём.
Я решил сделать двух Трековую схему.
Т.е. создаётся на одном треке линейка из ВСЕХ используемых в ходе Концерта плагинов и настраивается каждый Пресет, как вызов из Байпаса только определённых плагов, которые должны участвовать в формировании звука и в каждом из них заданного Пресета (но уже внутреннего Пресета плагина, который там и сохранён).
Потом эта линейка полностью дублируется на второй трек и между ними ставится управляемый Кросфэйд.
Алгоритм работы такого СТЭКА получился на два порядка более сложным, так как требует сложную логику по переброски крос фэйда всё время лево-право и изменение Пресетов только в той, на которую собираемся перейти.
При этом нужно было решать что делать, если Пользователь не дождавшись окончания КросФэйда нажмёт следующий пресет и при наличии звука в обоих линейках, переключающийся Пресет создаст опять щлчёк и пр. пр. пр.
Я практически всё это решил, но понял, что это очень плохо работает и очень сложно настраивается, потому как все задержки и последовательность событий выстраиваются в последовательность и сильно удлиняют время перехода с Пресета на Пресет, в не зависимости от того , какое оно выбранно собственно для КросФэйда.
Кроме того такой Стэк очень не интуитивно програмируется - так как мы не видим как в случаи многотрекового решения все Пресеты одновременно, все настройки зашиты где-то в недрах программы при програмировании и что-то потом поменять в двух одинаковых линиях эффектов - это нужно иметь хорошее образное мышление.
Но при этом у нас только две инсталяции каждого используемого в Концерте плагина, всего два трека, память экономится столь-же хорошо, как и Процессор.
3. Вариант - компромис -
Состоит из Трёх Треков с одинаковой линейкой плагинов. Работает аналогично варианту 2, НО! снимает почти вопросы с быстродействием переброски звука, так как у нас всегда в момент нажатия следующего Пресета и переключения Пресетов в плагинах, трек на котором они находятся находится в положении - громкость убранна до нуля. При этом варианте логика сильно упрощается и мы не боимся, что Пользователь нажмёт выбор следующего Пресета до отработки Фэйда предидущего.
Минус - всё та-же не информативность при програмировании и увеличение на треть (по сравнению с вариантом 2) загрузки и Проца и Памяти. С Процом можно решить байпасом не используемых плагов, как сделал в варианте 1, с памятью - НИКАК, при том, что при трёх линейках может оказаться так, что загруженных плагинов будет даже больше чем в варианте с 10-ю Треками-Пресетами по первому варианту - ну это тогда, когда каждый новый пресет из 10-и нам нужных, требует нового Плагина -
В варианте где каждый Пресет это Трэк (1-ый) - плагинов по любому будет 10, а в варианте с трёх трековой схемой - 30!!!!!!!!!! Кстати в двух трековой 20
Вот сижу и чешу РЕПУ и задаю себе вопрос - А не придумал ли я в первый раз самую идеальную схему?
Я не могу принять решения (выбрать какое будет компромисно - правильным и перспективным).
Речь идёт о функциональной схеме реализации Инструментального Стэка в том виде, в котором по максимуму я бы хотел его видеть.
По сколько я в первую очередь хочу сделать так, чтобы при переключении любых Пресетов не происходило ни каких, даже малейших подрывов звука, то кросфэйд между одним выстроенным звучанием и другим - единственно возможное решение. Я внимательно изучил как реализованны во многих программах все возможные операции со звуком в во время его звучания (имею в виду Мюты, Байпасы, Соло там и прочее) и везде где это решено без щелчков в звуке - стоит кратковременный, несколько мс, но фэйд.
А вот как реализовывать перебор этих самых Пресетов через Фэйд так чтоб это было удобно не только пользовать, но и настраивать, чтобы это решение жрало как можно меньше ресурсов компа - вот тут не всё так однозначно и ясно, как мне казалось в начале, до того как я один из вариантов решил полностью, а второй довёл почти до работающей Бэтты.
Я изложу три найденных мной варианта и прошу вдумчиво их изучить и помочь с выбором по которому дальше пойти.
Сначал хочу обсудить подход - что берём во внимание, что для кого является важным, а что второстепенным.
Для меня в порядке важности (1-самый важный) это вот так -
1. Максимальное качество звука на выходе, никаких артефактов при переключении.
2. Максимально удобное использование уже запрограмированного Стэка.
3. Переключение Пресетов в произвольном порядке, с любой скоростью.
4. Минимально возможные требования к мощности компа, т.е. предпринять все возмжные ухищрения, чтобы ресурсов такое решение отбирало как можно меньше.
5. Максимально удобное програмирование Стэка.
ну вот у меня Максимально удобное програмирование Стэка на 5-ом месте, а я понимаю, что для тех, кто не создавал этот самый Стэк, этот пункт будет на втором или даже на 1-ом месте.
Итак варианты решения -
1. Тот вариант, который я уже реализовал в Рипере с написанными под негог несколькими плагами -
http://forum.rmmedia.ru/showthread.php?t=105767
Изначально решил сделать понятную схему - Каждый Пресет это по сути расположенная на отдельном Треке обработка, которая может состоять из любого кол-ва последовательных и паралельных плагинов.
Переключение между Пресетами-Трэками - это на каждый трэк, настраиваемый по длительности и форме кривой, кросфэйд. Отдельно трек для входа инструмента (на нём все стабильно не меняющиеся обработки - ну преамп какой-нить любимый, EQ с обрезными фильтрами, возможно один раз отстроенный Гейт). Отдельно выходной Трэк - который в общем используется как Фэйдер для управления уровнем громкости инструмента в миксе. Есть ещё трэк Управления этим Инструментальным Стэком, на который подключаются внешние миди управлялки и на котором стоит спец плаг управляющий всем Стэком в целом.
Собственно в такой Стэке настройка его сводится к настройке каждого Трэка-Пресета на звучание в той или другой части композиции, а переключение - подача сигнала на переход звука с одного Трэка Пресета на другой.
Мне показалась такая схема очень наглядной и понятной и простой и в програмировании и в использовании.
Но у такой схемы есть один существенный недостаток - к примеру я исользую для Гитарной обработки всегда Один ТОЛЬКО Amplitube, понятно, что с разными настройками. и получается так, что мне прийдётся создать столько Треков-Пресетов, сколько разных звуков из Amplitube я хочу получить за одну композицию - в среднем это около 10, да и Берингеровская ножная миди педаль имеет в одной закладке 10 кнопок.
Значит мне прийдётся установить 10 Amplitube - По каждому на один свой Трек-Пресет и каждый настроить на свой звук.
Но я тут-же увеличиваю нагрузку на Процессор ровно в 10 раз больше по сравнению с одним Amplitube, который трещит при переключении пресетов, у которого нет никаких кросфэйдов при переключении, но в 10 раз меньше жрёт!
Вторая проблема - это в 10 раз больше грузим память компа.
С первой проблемой я справился - управляющий Стэк-ом плагин выводит все Плагины на не использующихся в момент игры Трэках-Пресетах в Байпас, что снимает тут-же нагрузку с процессора - т. е. в моём СТЭК-е в работе находится одновременно не более двух линеек плагинов в двух Треках-Пресетах на которых происходит переключение с одного на другой.
А вот с памятью - НИКАК, так как чтобы выгрузить плаг из памяти, его нужно вывести в Офлайн (а не Байпас). В Рипере можно плаг и в Офлайн легко дистанционно увести, и происходит это быстро, но вот поднять его потом из офлайна - всё равно, что по новой загрузить плагин - долго и пиковая нагрузка возрастает. Т.е. если переключатся между двумя Треками-Пресетами на которых одна из линеек плагинов в офлайне - будет ОЧЕНЬ долго и просто не приемлимо.
Значит проблема Памяти в этом варианте остаётся не решаемой - просто миримся с этим и смотрим, чтобы при 32Bit приложении она была рассредоточена по разным открытым блокам процессов, что в Рипере ВОЗМОЖНО, а вот в Bidule- я такого не нашёл, как в прочем и офлайна для конкретно выбранного плага.
2. Второй вариант я практически реализовал в Bidule и споткнулся, чуть дальше поясню на чём.
Я решил сделать двух Трековую схему.
Т.е. создаётся на одном треке линейка из ВСЕХ используемых в ходе Концерта плагинов и настраивается каждый Пресет, как вызов из Байпаса только определённых плагов, которые должны участвовать в формировании звука и в каждом из них заданного Пресета (но уже внутреннего Пресета плагина, который там и сохранён).
Потом эта линейка полностью дублируется на второй трек и между ними ставится управляемый Кросфэйд.
Алгоритм работы такого СТЭКА получился на два порядка более сложным, так как требует сложную логику по переброски крос фэйда всё время лево-право и изменение Пресетов только в той, на которую собираемся перейти.
При этом нужно было решать что делать, если Пользователь не дождавшись окончания КросФэйда нажмёт следующий пресет и при наличии звука в обоих линейках, переключающийся Пресет создаст опять щлчёк и пр. пр. пр.
Я практически всё это решил, но понял, что это очень плохо работает и очень сложно настраивается, потому как все задержки и последовательность событий выстраиваются в последовательность и сильно удлиняют время перехода с Пресета на Пресет, в не зависимости от того , какое оно выбранно собственно для КросФэйда.
Кроме того такой Стэк очень не интуитивно програмируется - так как мы не видим как в случаи многотрекового решения все Пресеты одновременно, все настройки зашиты где-то в недрах программы при програмировании и что-то потом поменять в двух одинаковых линиях эффектов - это нужно иметь хорошее образное мышление.
Но при этом у нас только две инсталяции каждого используемого в Концерте плагина, всего два трека, память экономится столь-же хорошо, как и Процессор.
3. Вариант - компромис -
Состоит из Трёх Треков с одинаковой линейкой плагинов. Работает аналогично варианту 2, НО! снимает почти вопросы с быстродействием переброски звука, так как у нас всегда в момент нажатия следующего Пресета и переключения Пресетов в плагинах, трек на котором они находятся находится в положении - громкость убранна до нуля. При этом варианте логика сильно упрощается и мы не боимся, что Пользователь нажмёт выбор следующего Пресета до отработки Фэйда предидущего.
Минус - всё та-же не информативность при програмировании и увеличение на треть (по сравнению с вариантом 2) загрузки и Проца и Памяти. С Процом можно решить байпасом не используемых плагов, как сделал в варианте 1, с памятью - НИКАК, при том, что при трёх линейках может оказаться так, что загруженных плагинов будет даже больше чем в варианте с 10-ю Треками-Пресетами по первому варианту - ну это тогда, когда каждый новый пресет из 10-и нам нужных, требует нового Плагина -
В варианте где каждый Пресет это Трэк (1-ый) - плагинов по любому будет 10, а в варианте с трёх трековой схемой - 30!!!!!!!!!! Кстати в двух трековой 20
Вот сижу и чешу РЕПУ и задаю себе вопрос - А не придумал ли я в первый раз самую идеальную схему?
