[mdk-re] Re: [mdk-re] Взгляд со стороны

[Alexandre Prokoudine]

On Sun, 17 Mar 2002 02:20:23 +0300
ROmul <romul.home на mtu-net.ru> wrote:

> On Sat, 16 Mar 2002 15:58:42 +0300
> 
> AP> Пока не столкнутся люди схожих интересов и не начнут делать что-то одно.
> AP> Что столкнуло Джоди Голдберга и Мигеля? А вот поди ж ты, Гнумерик
> AP> получился ... :-)
> Ага,ага...чую брожение в умах :))
> 
> AP> Трёх кнопок в Линуксе никогда не будет. Четыре - как минимум =) А если
> AP> серьёзно, то будущее именно за быстро- и легкомасштабируемыми ОС.
> Да, конечно. Но должны быть две части "масшабируемости" для юзера (в этом направлении Линукс 
> двигается и неплохо.) то есть юзер должен иметь возможность настроить что-то быстро тыкнув мышей пару раз, при этом никто не мешает админу или продвинутому юзеру колупаться с текстовыми конфигами доводя до совершества нужную технологию. СУПЕРМасштабируемость линукса это с некоторой точки зрения недостаток.
> Кстати тут заметил одну фишку в гтк... нехорошую. Это не баг, а фича, но какая-то глупая...Напишу отдельным письмом чтобы чистоту треда попытаться сохранить :))

Ждёмс-с :-)

Кстати, а ведь ещё для первого gtk+ писался патч, добавляющий в
стандартный диалог дополнительные кнопки - о нём AVL, вроде, писал. Как
бы его на системном ALT-уровне внедрить?


> 
> AP> здоровье. Кстати, в соседнем Липецке два здоровых торговых дома на
> AP> Линуксе сидят ... не знаю, на какой ОСи висит книжный магазин на Новом
> AP> Арбате, но слышал - что на юниксе.
> Зайду, спрошу. Кстати для супермаркетов и крупных магазинов Линкс самое-то.
> Ибо там терминальные решения, которые, как мы знаем от Витуса Вагнера - Сила :))

Киньте в меня ссылкой, а то его так часто цитируют ... А я только одну
статью про табличные процессоры читал ... Стыдно, аднака ...

> 
> AP> сетке виндовые и линуксовые машины потому что "так надо" - весьма
> AP> геморно. Это называется зоопарк.
> Нужен зоопарк. Докель сущетсвуют задачи трдно решаемые под Линуксом нужны винды, если мы исходим из 
> положения "софт под задачу".
> 
> AP> Уважаемому мной ROmul' наверняка хотелось бы иметь Linux-box для своих
> AP> сугубо музыкальных целей.
> Хотелось бы. Ибо я успел прочуствовать как ведет себя Линукс на ресурсоемких задачах. Просто супер!
> У меня ради эксперимента компилилось ядро и одновременно писался сидюк + я браузил по инету. Ядро скомпилилось, сидюк записался, я по инету полазил... Супер! А музыкальные задачи они дико ресурсоемкие и требуют гениальной оптимизации всего на свете, прежде всего оптимизации размещения информации на диске
> (кстати по хорошему сделать бы отдельную FS для хранения аудиоданных...), многопотокового чтения с диска,
> работы с аудиодрайверами и памятью...все важно. И под Линуксом это скорее будет в нормальном виде чем под виндой.

БеОСная ФС не устроила? :-)))
Я от её скорости в своё время фигел по страшному.


<skip>

> 
> 
> AP> проблем принципиальных за исключением драйверов просто НЕТ. Драйверов,
> AP> кстати, не хватает именно под полу/профессиональную технику. Например,
> AP> моя новая карточка (SB 5.1 Live) в Linux - MIDI'less. 
> Но зато ALSA в полном объеме поддерживает RME HAMMERFALL, а он профессиональная карточка.
> Правда разработчики карты сами об этом позаботились.

Ставлю за них свечку. Чтоб таких побольше было.


> 
> 
> AP> Тот музыкант, который ещё немного программист, мог бы при наличии
> AP> драйверов заскриптовать, скажем, на Питоне, то, что ему надо и
> AP> пользоваться этими скриптами.
> Вариант. Это был бы аналог cal в Cakewalk. нужны только заранее написанные библиотеки на питоне, привязанные к функциям конкретного секвенсера.
> 
> AP> pygtk/pygnome/PyQt и общий бинарник. Так, если не ошибаюсь, делались
> AP> векторная рисовалка Sketch и "диаграмщик" Dia.
> Кстати можно примерно предсказать каков расход памяти будет у такого интерфейса? Насколько быстро он сможет перерисовываться...как ни странно для музыкальных приложений это тоже принципиально.
> Вот gtk относительно тормозно делает перерисовку....и не всегда как надо.

В каких именно случаях?

>  
> AP> Музыкантам нужен аналог Cakewalk или Cubase.
> Или Лоджик Аудио, который сейчас лидер на этом рынке...и правильно - супер продукт.

Не знаю. Года на два отстал :-)

>  
> AP> возможность слить с клавиш записанные где-то куски и обработать их на
> AP> писишнике на том уровне сложности, который зависит от их компетенции, а
> AP> не от компетенции разработчиков оной программы. 
> Идеальная формулировка. Более того, не только "забить" с клавиш, но и ввести мышкой в виде нотного текста

Это можно сделать в Brahms

> который можно распечатать в читабельном виде) 

И это тоже :)

> или "колбасок" в pianoroll (matrix в Лоджике). 

Блин. И это тоже :-)))

> Так же нужны редакторы специально для ударных, 

Срочно идите на http://brahms.sourceforge.net :-)


> рисование мидиконтроллеров прямо по треку в секвенсере кривыми безье. 

И это тоже, вроде ...

У меня пакеты для компиляции пока качаются. Если получится скомпилить -
буду терзать Юрия Седунова, чтоб собрал Брамса для Сизифа

> Идеально отлаженная синхронизация миди и аудио. Настраеваемая квантизация (чего я не нашел в линуксовых секвенсерах, а это база.) ну я перечислять могу еще час...

Я одну уже назвал :-)

> 
> APAP> вызывает пока только Anthem). Если не с MusE, то с anthem вполне можно
> AP> работать.
> С anthem нельзя... в нем нет нормальных редакторов вообще и даже базовых функций. 
> Смотри выше.
> 
> 
> AP> клавишной партией в один демо-трек. А сложность обработки PCM сигнала
> AP> будет определяться уже не фичнутостью самой программы, а ПЛАГИНАМИ, 
> Как ни странно и фичнутостью тоже. Потому, что такая программа должна представлять из 
> себя аналогию студийного микшера и иметь возможность по разному роутить аудио сигналы, 
> по разному включать обработки в поток и прочее...
> 
> AP> ночи. Плагинового интерфейса в Linux что ли нет? А LADSPA что такое? :)
> AP> Они уже часть VST'шных плагинов конвертнули. В сизифовом пакете этих
> AP> плагинов 36 штук.
> Да? Какой пакет?

[alex на localhost alex]$ rpm -qa | grep ladspa
ladspa-swh-plugins-0.2.3-alt1
ladspa_sdk-1.11-alt4


> 
> AP> В общем, в конечном итоге всё сводится к реализации возможностей. ROmul'
> AP> сумеет, пожалуй, точнее отобразить требования
> Да. Смогу. Более того, я даже могу попытаться разработать концепцию интерфейса и организации 
> проги....хотя все равно я бы делал кальку с Лоджика :))

Уже сделано :)

Брамс, опять же :-)


> 
> 
> AP> Samplitude или хотя бы одной из софтин от Soundforge - всё равно, что
> AP> похоронить идею заживо.
> Забыл про ardour. Проект развивается и он очень переспективный. Из аудиопроектов, которые я нашел, пожалуй самый.

Кстати, разработчики MidiMountains и Ardour, судя по инфе на сайте
первых, собираются кооперироваться ... Хорошая новость

> 
> AP> Программер не умеет писать музыку, а музыкант не программирует, поэтому
> AP> лучшие разработки пишутся конторами, которые на этом специализируются.
> Вот кстати Emagic, которые сделали лоджик они в основе своей музыканты...И секвенсер этот начинался с простенькой програмки нотатора на Atari! Потом на маке, а потом и под винду...
> 
> AP> Поэтому мы и имеем дело с абсолютно невнятным glame, автор которого
> AP> обладает, по всей видимости, извращённым чувством юмора. 
> Помнится, когда я это здесь написал сразу после установки glame, меня обругали...
> Мол нужно разработчику слать исправления...А что слать, если главным исправление, которое нужно сделать 
> это не подпускать этого человека к разработке интерфейсов для аудиопрограмм вообще...

Не помню чтобы ругали - если только личной почтой. Тогда то же самое ждёт и меня :-) Однако фраза "Интуитивно понятный интерфейс - это интерфейс, для освоения которого нужна немалая интуиция" подходит к этому случаю идеально.

> AP> Я очень хочу посмотреть на этот range of host applications. 
> Да. Эта фраза меня тоже за живое задела.... Вспомним кстати мою фразу про замкнутость linux comunity 
> на себя в начале треда. На теме музыкального софта отчетливо видно что я имел в виду. Мы имеем кучу хороших разработок аудиоинтерфейсов, API, библиотек. Такое количество винде с ее directsound не снилось
> Кучу всяких прибабахов для РАЗРАБОТЧИКОВ. И минимум приложений написанных при помощи всех этих средств.
> В итоге что выходит - програмисты пишут софт для того, чтобы писать программы, но не пишут сами программы.
> Во вам и замкнутость. И это не единственная область. Количество средств для разработки значительно превышает количество написанных приложений. Получается Open-Closed Comunity...
> 
> AP> только gdam-clients-gtk ... ей богу, я от монитора отшатнулся, когда
> AP> увидел ... :(
> А я сначала не понял что это.... и для чего :)

А я до сих пор не знаю :-)))
Не просветите? :-)

> 
> AP> Вот и надо лечить. 
> Надо. Нужно собирать инициативную группу  :) И возможно даже такой не программист как я поимеет опыт участия в OpenSource разработке :)) 
> 
> AP>Интуиция мне подсказывает, что те же Cakewalk и  Cubase если и будут портированы на Linux, то только в самый последний момент.
> Я думал над этим вопросом.... Что в первую очередь интересует того, кто продает софт? Наличие спроса на рынке. Пока не станет ясно, что юзеры Линукса способны и хотят покупать комерческий музыкальный софт или пока кто-то из компаний не решит продвинуть на рынок относительно дешевую рабочую музыкальную станцию под Линукс, софта не будет. То есть когда он будет, это и будет для нас с тобой один из последних моментов  в жизни :)

Вах, как печально ...

Однако жду комментариев по поводу Брамса :-)

Михаил, и от Вас, по возможности, тоже :-)))

--
А.П.