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

Вс Мар 17 02:39:00 MSK 2002

On Sat, 16 Mar 2002 15:58:42 +0300

AP> Пока не столкнутся люди схожих интересов и не начнут делать что-то одно.
AP> Что столкнуло Джоди Голдберга и Мигеля? А вот поди ж ты, Гнумерик
AP> получился ... :-)
Ага,ага...чую брожение в умах :))

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

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

AP> сетке виндовые и линуксовые машины потому что "так надо" - весьма
AP> геморно. Это называется зоопарк.
Нужен зоопарк. Докель сущетсвуют задачи трдно решаемые под Линуксом нужны винды, если мы исходим из 
положения "софт под задачу".

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

AP> сказал "Фи, в этом лЮниксе не поддерживается даже MIDI для emu10 ...",
AP> однако ж господин ROmul' в этом джеме варится и, судя по всему, получает
AP> от этого достаточное удовольствие. :)
Интерес и любознательность он сила :)) Кроме того я человек для которого идеи важны...люблю красивые идеи 
:)) гуманитарий, блин...

AP> Я эту тягомотину к чему опять завожу - надо анализировать уметь.
Это не тягомотина. Такая тягомотина в итоге я надеюсь приведет к:
- Пониманию ситуации
- Выработке позитивной программы
- Определенным действиям по ее осуществлению.
Когда я тут и в ru.linux заводил разговоры о музыкальном софте я имел в виду именно эти цели.
раз есть комьюнити, в ней найдутся заинтересованные люди...только нужно чтобы проблема была осознана 
не одним человеком.

AP> заметные глюки - один, второй, третий ... Компания начнёт терять
AP> авторитет вместе со своими клиентами и в конце концов разорится.
Спорная линия...Во первых на плаву проприетарные компании держатся, во многом за счет очень грамотных рекламных акций. Во вторых все зависит от организации процесса разработки. Грамотный мэнеджер 
проанализировав удачную схему разработки в опен соурс сможет спроецировать ее на проприетарное 
решение. 
Хотя еще более грамотный менеджер попытается заюзать те ресурсы, которые есть в комьюнити, для того, чтобы разработать то что ему нужно...И не факт, что это в конце концов будет открытым решением... Как пример StarOffice.

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> не от компетенции разработчиков оной программы. 
Идеальная формулировка. Более того, не только "забить" с клавиш, но и ввести мышкой в виде нотного текста (который можно распечатать в читабельном виде) или "колбасок" в pianoroll (matrix в Лоджике). Так же нужны редакторы специально для ударных, рисование мидиконтроллеров прямо по треку в секвенсере кривыми безье. Идеально отлаженная синхронизация миди и аудио. Настраеваемая квантизация (чего я не нашел в линуксовых секвенсерах, а это база.) ну я перечислять могу еще час...

APAP> вызывает пока только Anthem). Если не с MusE, то с anthem вполне можно
AP> работать.
С anthem нельзя... в нем нет нормальных редакторов вообще и даже базовых функций. 
Смотри выше.

AP> клавишной партией в один демо-трек. А сложность обработки PCM сигнала
AP> будет определяться уже не фичнутостью самой программы, а ПЛАГИНАМИ, 
Как ни странно и фичнутостью тоже. Потому, что такая программа должна представлять из 
себя аналогию студийного микшера и иметь возможность по разному роутить аудио сигналы, 
по разному включать обработки в поток и прочее...

AP> ночи. Плагинового интерфейса в Linux что ли нет? А LADSPA что такое? :)
AP> Они уже часть VST'шных плагинов конвертнули. В сизифовом пакете этих
AP> плагинов 36 штук.
Да? Какой пакет?

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

AP> Samplitude или хотя бы одной из софтин от Soundforge - всё равно, что
AP> похоронить идею заживо.
Забыл про 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, то только в самый последний момент.
Я думал над этим вопросом.... Что в первую очередь интересует того, кто продает софт? Наличие спроса на рынке. Пока не станет ясно, что юзеры Линукса способны и хотят покупать комерческий музыкальный софт или пока кто-то из компаний не решит продвинуть на рынок относительно дешевую рабочую музыкальную станцию под Линукс, софта не будет. То есть когда он будет, это и будет для нас с тобой один из последних моментов  в жизни :)

-- 
---
	ROmul,
	    The rubberheart... <-Exit project->
HOMEPAGE: http://exit.webzone.ru	    