Почему вообще существует проблема игольного ушка asio? Если это чисто программная реализация,то там же можно было ушко и пошире сделать,как я понимаю. Или это проблема на уровне железа?
Это костыль сродни увеличению буфераASIO Guard (anticipative Fx)
Не пишите билиберды..С современными компами уже нет никакой проблемы с ASIO и low latency, ASIO Guard (anticipative Fx) также отличная штука.
Носят значит 99 бравых хлопцев воду вёдрами, ну, а одному приспичило в ладошках потаскать, но так чтобы сандалии дымились, ну дай Боже ему здоровья.
П.С. Только лучше нормальный интерфейс, чтобы всё-таки он в стакане с крышкой таскал.
И это тоже не так.@Гуманитарий, В силу нереалтаймовой природы потребительских осей процу гораздо легче перерабатывать большие объёмы данных, но делать это реже (т.е. ему гораздо комфортнее при работе с большим буфером). Т.е. ему намного легче наполнить водой условную бочку воды, таская её вёдрами. Но многие пытаются заставить его таскать воду бегом в ладошках, а потом удивляются - почему это неэффективно, да ещё и расплёскивается по дороге (те самые выпадения сигнала в виде щелчков и треска при малых значениях буфера).
Хорошо, напишите Вы.Не пишите билиберды..
Не так то, что при слабом процессоре ваших бравых хлопцев не спасёт ни какой буфер выставленный в Anticipative Fx, да и для индивидуума прийдётся ставить буфер большой.Хорошо, напишите Вы.
Бравые хлопцы - это треки, на которых не активирован прямой мониторинг. Вёдра - это большой буфер, т.е. включён режим Anticipative Fx
Индивидуум - это трек с прямым мониторингом, который работает на буфере, который выставлен в настройках.
Что не так?
Ну, наверное, под современными компами, я имел ввиду не пентиумы первые, как думаете?Не так то, что при слабом процессоре ваших бравых хлопцев не спасёт ни какой буфер выставленный в Anticipative Fx, да и для индивидуума прийдётся ставить буфер большой.
Так что - всё по прежнему, чем мощнее процессор, тем удобнее работа.
И по-прежнему низкий буфер - это стрессовое состояние для проца.Так что - всё по прежнему, чем мощнее процессор, тем удобнее работа.
Так я не думаю, я всё сам проверяю.Ну, наверное, под современными компами, я имел ввиду не пентиумы первые, как думаете?
101%И по-прежнему низкий буфер - это стрессовое состояние для проца.
Ну….., не только пофигизма, увеличение мощности даёт возможность радивым программистам создавать более точные и сложные алгоритмы.Мне пока не доводилось поработать на таком компе, чтобы можно было вообще ничего не фризить и не думать о производительности. Но до меня доходили слухи, что уже есть какие-то компы, которых кому-то полностью хватает.
Да и блин, это такая бесконечная гонка -- производительность железа против пофигизма разработчиков, которую невозможно выиграть. Сколько производительности не дай, всю задействуют и всё равно будет мало
Компьютеры - машины универсальные, с ростом производительности проца растут и запросы (прерывания) современных осей (фон. процессы, службы и пр. резидентные проги).Сколько производительности не дай, всю задействуют и всё равно будет мало
Вот это вот всё - вредоносные и не нужные для нас плюшки, которые производители Винды и Мак Оси могли бы и дать отключать ВСЕ одним кликом, чтоб не нужно было заниматься этим всем по одной службе.(фон. процессы, службы и пр. резидентные проги).
Да уж, разбежались! Я думал Линух в этом отношении лучше, но там тоже самое. Хотя если шарить можно сделать его под себя, Archlinux.могли бы и дать отключать ВСЕ одним кликом
Линукс пока нативно не будет поддерживать VST3 - нафиг ни кому не нужен. Да и настраивать его нужно так же как и Win 10.Да уж, разбежались! Я думал Линух в этом отношении лучше, но там тоже самое. Хотя если шарить можно сделать его под себя, Archlinux.
Это было бы очень дорого. Осы потому и дешевые, что стараются быть универсальными и для всего сразу. В лучшем случае может быть чтото типа репака со всеми обрезанными ненужностями. Но с поддержкой новья будет полный швах и ее нужно будет перепиливать ежегодно. И это врядли будет стыковаться с правообладателямиАга, вполне могли бы делать какую-то workstation-версию ос, если бы кому-то было не пофиг, но всем пофиг
А откуда там будет лучше - это такая же нериалтаймовая ОС как windows или macOS. Так что там все те же самые грабли. Как только одно ядро загружается полностью, ждите дропаутов, сколько б других свободных ядер у вас ни было.Я думал Линух в этом отношении лучше, но там тоже самое.
Только это и требуется. Отсутствие мусора, долгий цикл обновления (мажорная версия раз в 3-5 лет), только багфиксы между мажорными версиями.В лучшем случае может быть чтото типа репака со всеми обрезанными ненужностями.
Там же как-то можно скомпиллировать реалтаймовое ядро. И решения есть работающие... ну тот же Receptor или Waves Soundgrid Server... или Korg Kronos.это такая же нериалтаймовая ОС как windows или macOS.
Что-то я о таком не слышала... да и в любом случае, даже если ядро риалтаймовое, приложения тоже должны быть в ядре... может, я, конечно, сильно отстала, и на базе (а скорее по мотивам) линукса сделали риалтайм ОС, которую как-то также назвали... но это уже точно не обычный Линукс.Там же как-то можно скомпиллировать реалтаймовое ядро.
Receptor - вроде самый обычный комп. Да что там, Maschine+ даже самый обычный комп кажется. Ну да, разумеется стараются оптимизировать ОС по максимуму. Но... Про Waves/Korg не знаю, но сильно сомневаюсь.Receptor или Waves Soundgrid Server.
Можно, в интернете полно информации. Так же на этом крутятся и новые MPC, и все энтузиастские распберри-подобные проектыТам же как-то можно скомпиллировать реалтаймовое ядро. И решения есть работающие... ну тот же Receptor или Waves Soundgrid Server... или Korg Kronos.
C VST-хостом на Линуксе. А про Waves даже ветка на ГС есть по сборке самопального сервера с осью на основе некомпилированных исходников, выложенных самим Waves.Receptor - вроде самый обычный комп.
Не совсем так. Линукс - это ядро (с набором дистров вокруг) в котором есть возможности рт реализации, причем уже очень давно.А откуда там будет лучше - это такая же нериалтаймовая ОС
Нууу, с этим в линупсе проблем нет от слова совсем, они скорее даже обратного характера: как ненужные выгрузить из ядрада и в любом случае, даже если ядро риалтаймовое, приложения тоже должны быть в ядре