А я впервые познакомился с MSX-компьютерами в пионерском лагере. Прямо в пионерской комнате они стояли. Хорошие компьютеры. На MSX, кстати говоря, сделали одну из лучших советских компьютерных игр по названием «Штурман».
А еще существовал музыкальный компьютер Yamaha CX5M. С его помощью дуэт Тихомирова и Родионова записал свою знаменитую пластинку «Пульс» в середине 80-х.
Спасибо! В статье я это отношу к «скрытому многоголосию», но быстрые арпеджио для имитации аккордов это, вообще говоря, основа 8-битного музыкального стиля.
График MIX это, по сути, простейший вид модуляции плотности импульсов (PDM). Я не знаю, реализовывал ли кто-то для Спектрума сигма-дельта модулятор. Насколько я понимаю, без разрывов в сигнале не обойтись (ведь нужно обновлять данные фреймов и т.п.), что не очень хорошо отражается на качестве PDM.
Спасибо за отзыв! О трекерной и сэмплерной музыке в целом, наверное, лучше написать отдельно. Ведь тема очень обширная. Впрочем, музыкальные трекеры не всегда основывались только на сэмплах. В 90-е годы существовало несколько интересных муз. программ, которые совмещали в себе как возможности трекерной нотации, так и программный синтез. Приведу два примера.
Очень хорошо, что Вы вспомнили эту замечательную книгу. На мой взгляд, все тексты Хэмминга отличаются доходчивостью и практической направленностью. Вот что еще издавалось на русском языке у этого автора.
Книга «Теория кодирования и теория информации» (Радио и связь, 1983).
Книга «Цифровые фильтры» (Сов. радио, 1980).
Также в замечательной книге «Лекции лауреатов премии Тьюринга» (Мир, 1993) есть лекция Хэмминга под названием «Одна из точек зрения на информатику».
Ч. Хоар в своей тьюринговской лекции сказал следующее: «Я пришел к заключению, что существуют два способа составления проекта программного обеспечения: один способ — сделать его таким простым, чтобы было очевидно, что недостатков нет, а другой — сделать его таким сложным, чтобы не было очевидных недостатков».
Визуальная структура программы имеет к этому прямое отношение. Мы бросаем взгляд на простой и регулярный код и сразу же убеждаемся, что понимаем, как он работает.
Вы достаточно абстрактно пишете о «текстурах кода», поэтому подразумевать под ними читатель может разное. Вот несколько примеров.
1. ASCII-графика. Есть программисты, которые не ленятся ставить лишние пробелы c целью создания более таблично-регулярной структуры исходного текста. Другие отказываются от такого подхода, справедливо указывая, что это мешает модификациям/факторизации кода. Конечно же, существуют и настоящие «картины кода»: dgopstein.github.io/articles/ioccc-ascii-art
2. Карты кода в текстовых редакторах, таких, как Sublime. Любопытно, что программист, привыкший пользоваться подобной картой, начинает делать в коде специальные пометки, видимые «с высоты птичьего полета».
3. Искусство, связанное с изображением древнего программного кода. Тут я ничего говорить не буду, просто посмотрите на эти картины: benfry.com/distellamap
4. Средства визуального программирования. Визуальное программирование до сих пор остается достаточно нишевой вещью. Возможно, это связано с тем, что применяется оно, в основном, на нижних уровнях иерархии программных конструкций (присваивания, условия и т.д.). Очень многое можно возложить на IDE: работа на уровне AST-представления, различные визуализации статических/динамических видов анализа (графы вызовов и т.д.). Помните Смолток и его многоколоночную визуализацию классов и методов? До сих пор, кажется, не было сделано в ООП-мире ничего более наглядного. В целом же необходимы мощные средства визуализации на уровне системы, в духе того, как это было в ТРИЗ: www.altshuller.ru/triz/zrts6.asp Ведутся ли разработки в этой области сейчас? Ведутся и ключевое имя здесь — Брет Виктор. Рано или поздно на хабре кто-нибудь опубликует перевод его нового проекта по Dynamicland, а пока я предлагаю ознакомиться с его работами на сайте worrydream.com
«Для каждой задачи свой инструмент» — это, разумеется, справедливо. Цитата же из Крэя примечательна тем, что трюизмом не является и продолжает вызывать споры до сих пор.
В английском оригинале учебника «Компьютерная архитектура. Количественный подход» Хеннесси и Паттерсона эта цитата приведена в следующем виде.
If you were plowing a field, which would you rather use: two strong oxen or 1024 chickens?
Seymour Cray, Father of the Supercomputer (arguing for two powerful vector processors versus many simple processors)
Эти слова были сказаны в начале 80-х и в то время векторные машины, которыми являлись знаменитые суперкомпьютеры Крэя, были более эффективным решением по совокупности характеристик, чем дорогостоящие кластеры из компьютеров общего назначения. Теперь времена изменились и, казалось бы, векторные системы должны быть давно забыты. Но, как ни странно, это не совсем так, несмотря на то, что компания Cray, уже после смерти ее основателя, перешла к традиционным кластерным MPP-системам (см. ту же Trinity из заметки выше). Знамя векторных вычислений подхватила компания NEC. Помните Earth Simulator? В начале 2000-х этот векторный суперкомпьютер был самым быстродействующим в мире. Совсем недавно стало известно о новом проекте «Tsubasa» этой же компании. Собственно, IBM Cell и популярные сегодня GPGPU-чипы это все те же «векторные волы».
Но касается ли цитата Крэя одних только векторных машин? Подход Крэя заключался в использовании небольшого числа мощных процессорных элементов с централизацией ресурсов (общая память, быстрые внутрисистемные коммуникации), гетерогенностью и специализированностью. Интересно, что Крэй незадолго до смерти в 1996 году занимался проектами построения суперкомпьютеров на базе реконфигурируемых систем (ПЛИС), которые вполне соответствуют изложенному выше подходу. Сегодня суперкомпьютеры с гетерогенной архитектурой и специализированными вычислителями на ПЛИС/GPU/… уже не являются экзотикой. Но, на мой взгляд, более интересно, что наметилась тенденция отхода от процессоров общего пользования и при построении кластеров. Посмотрите на лидеров Top500/Green500. 260-ядерный чип Sunway SW26010 и 2048-ядерный чип PEZY-SC2 — вот уж настоящие «волы»!
К слову сказать, мне довелось работать со своеобразными «цыплятами» — крохотными стековыми машинами с локальными связами между собой. На кристалле их были сотни. Такого рода системы могут использоваться в embedded для достижения малого времени отклика при обработки большого числа легковесных процессов. Но со временем, я перешел к архитектуре «барабанной» многопоточности в рамках единственного ядра-«вола».
Подводя итог. «Цыпленок» представляет собой простой процессор/компьютер, который не проектировался специально для задач суперкомпьютерных вычислений. Разумеется, системы на основе «цыплят» часто дешевле в разработке и эксплуатации. Но время от времени возникают требования, когда уместнее оказывается подход Сэймура Крэя.
Чем старые приключенческие игры могут быть любопытны разработчику? Дело в том, что в них часто использовались интерпретаторы виртуальных машин, задолго до jvm и .net. Это было в Zork (Z-Machine), у Sierra (AGI, SCI), у LucasFilm (SCUMM)… В 80-х хорошая игра выходила на целом множестве платформ и использование виртуальной машины позволяло упростить портирование. Разумеется, это касалось, в первую очередь, неспешных игр-квестов. (В самых старых текстовых приключениях, кстати, еще и интересные алгоритмы для сжатия текста использовались. См. игры Level 9).
Любопытный факт: в ранних версиях AGI от Сьерры картики хранились в «векторном» формате. Когда-то у меня была мысль написать утилиту, которая бы преобразовывала эти изображения в современный SVG. В реальности картинки хранятся в виде набора команд граф. редактора, используется инструмент заливки и т.п. То есть это не привычная векторная графика, а процедурный формат, который довольно-таки зависим от разрешения. Возможно, кому-то будет интересно повозиться с этим форматом :)
Для тех, кому интересны тех. трюки разработчиков старых игр, могу советовать недавно вышедшую книгу Retrogame Archeology.
Разумеется. По большому счету, было бы полезно иметь две версии игры. Текущий вариант представляет собой самый простой способ познакомиться с оригиналом. Я постарался, как смог, обеспечить максимальное соответствие с игрой 74 года. С точностью до алгоритма RND :) Это ведь важно для целей компьютерно-игровой истории-археологии. А вот вторая версия, для начинающих, еще ждет своего часа (и автора). Насколько было бы проще, если бы игра изначально была написана на Лого или Смолтоке! Но, что поделаешь, это языки в то время были «элитарными», ну а Бейсик — поистине народным :)
Увы, «дух» Бейсика все еще витает в коде. Собственно, третье переписывание кода на Питоне должно бы происходить уже без оглядки на оригинальный исходный текст. Но меня на этот этап не хватило. Много было потрачено времени на разбор оригинала на HP BASIC. Чтобы было понятнее, каким был оригинал, вот файлы: github.com/oubiwann/star-traders/tree/master/BASIC/HP-BASIC
wiki.multimedia.cx/index.php/Impulse_Tracker#Resonant_filters
Я знаю о следующих программах:
Csound (версия для MS-DOS вышла в 1991 году)
PURGE GB-303 Bassline (1995)
AudioSim (1996)
Analogic (1997)
dgcardenas.fpmit.com/cal/tutorial/cwt-syntax.htm
А еще оригинальная кассета с Wham (которую наш спектрумист, естественно, в глаза не видел) имела забавное оформление:
Описание: livet.se/mahoney/c64-files/Cubase64_White_Paper_by_Pex_Mahoney_Tufvesson.pdf
В Cubase64 используются техники программного синтеза/обработки, которые потом, как я помню, перекочевали и в другие демо для C64.
А еще существовал музыкальный компьютер Yamaha CX5M. С его помощью дуэт Тихомирова и Родионова записал свою знаменитую пластинку «Пульс» в середине 80-х.
А вот как звучал SAM на знаменитой презентации Макинтоша:
Вот еще один известный пример для Спектрума:
www.youtube.com/watch?v=bTtC8N4fthg
А вот как такой вариант звучит на PC:
www.youtube.com/watch?v=AiURTmwpX2U
P.S. Я так и знал, что тема по биперу станет самой популярной :)
График MIX это, по сути, простейший вид модуляции плотности импульсов (PDM). Я не знаю, реализовывал ли кто-то для Спектрума сигма-дельта модулятор. Насколько я понимаю, без разрывов в сигнале не обойтись (ведь нужно обновлять данные фреймов и т.п.), что не очень хорошо отражается на качестве PDM.
Кстати, неплохое руководство по приемам однобитного синтеза находится здесь: randomflux.info/1bit/viewtopic.php?id=21
AXS
www.youtube.com/watch?v=J8le0Zk16KY
Jeskola Buzz
www.youtube.com/watch?v=klQiIPo2w0Y
Сегодня же в данной категории одним из лидеров является отечественный SunVox
www.youtube.com/watch?v=J7U32h7Va1c
Визуальная структура программы имеет к этому прямое отношение. Мы бросаем взгляд на простой и регулярный код и сразу же убеждаемся, что понимаем, как он работает.
Вы достаточно абстрактно пишете о «текстурах кода», поэтому подразумевать под ними читатель может разное. Вот несколько примеров.
1. ASCII-графика. Есть программисты, которые не ленятся ставить лишние пробелы c целью создания более таблично-регулярной структуры исходного текста. Другие отказываются от такого подхода, справедливо указывая, что это мешает модификациям/факторизации кода. Конечно же, существуют и настоящие «картины кода»: dgopstein.github.io/articles/ioccc-ascii-art
2. Карты кода в текстовых редакторах, таких, как Sublime. Любопытно, что программист, привыкший пользоваться подобной картой, начинает делать в коде специальные пометки, видимые «с высоты птичьего полета».
3. Искусство, связанное с изображением древнего программного кода. Тут я ничего говорить не буду, просто посмотрите на эти картины: benfry.com/distellamap
4. Средства визуального программирования. Визуальное программирование до сих пор остается достаточно нишевой вещью. Возможно, это связано с тем, что применяется оно, в основном, на нижних уровнях иерархии программных конструкций (присваивания, условия и т.д.). Очень многое можно возложить на IDE: работа на уровне AST-представления, различные визуализации статических/динамических видов анализа (графы вызовов и т.д.). Помните Смолток и его многоколоночную визуализацию классов и методов? До сих пор, кажется, не было сделано в ООП-мире ничего более наглядного. В целом же необходимы мощные средства визуализации на уровне системы, в духе того, как это было в ТРИЗ: www.altshuller.ru/triz/zrts6.asp Ведутся ли разработки в этой области сейчас? Ведутся и ключевое имя здесь — Брет Виктор. Рано или поздно на хабре кто-нибудь опубликует перевод его нового проекта по Dynamicland, а пока я предлагаю ознакомиться с его работами на сайте worrydream.com
В английском оригинале учебника «Компьютерная архитектура. Количественный подход» Хеннесси и Паттерсона эта цитата приведена в следующем виде.
Эти слова были сказаны в начале 80-х и в то время векторные машины, которыми являлись знаменитые суперкомпьютеры Крэя, были более эффективным решением по совокупности характеристик, чем дорогостоящие кластеры из компьютеров общего назначения. Теперь времена изменились и, казалось бы, векторные системы должны быть давно забыты. Но, как ни странно, это не совсем так, несмотря на то, что компания Cray, уже после смерти ее основателя, перешла к традиционным кластерным MPP-системам (см. ту же Trinity из заметки выше). Знамя векторных вычислений подхватила компания NEC. Помните Earth Simulator? В начале 2000-х этот векторный суперкомпьютер был самым быстродействующим в мире. Совсем недавно стало известно о новом проекте «Tsubasa» этой же компании. Собственно, IBM Cell и популярные сегодня GPGPU-чипы это все те же «векторные волы».
Но касается ли цитата Крэя одних только векторных машин? Подход Крэя заключался в использовании небольшого числа мощных процессорных элементов с централизацией ресурсов (общая память, быстрые внутрисистемные коммуникации), гетерогенностью и специализированностью. Интересно, что Крэй незадолго до смерти в 1996 году занимался проектами построения суперкомпьютеров на базе реконфигурируемых систем (ПЛИС), которые вполне соответствуют изложенному выше подходу. Сегодня суперкомпьютеры с гетерогенной архитектурой и специализированными вычислителями на ПЛИС/GPU/… уже не являются экзотикой. Но, на мой взгляд, более интересно, что наметилась тенденция отхода от процессоров общего пользования и при построении кластеров. Посмотрите на лидеров Top500/Green500. 260-ядерный чип Sunway SW26010 и 2048-ядерный чип PEZY-SC2 — вот уж настоящие «волы»!
К слову сказать, мне довелось работать со своеобразными «цыплятами» — крохотными стековыми машинами с локальными связами между собой. На кристалле их были сотни. Такого рода системы могут использоваться в embedded для достижения малого времени отклика при обработки большого числа легковесных процессов. Но со временем, я перешел к архитектуре «барабанной» многопоточности в рамках единственного ядра-«вола».
Подводя итог. «Цыпленок» представляет собой простой процессор/компьютер, который не проектировался специально для задач суперкомпьютерных вычислений. Разумеется, системы на основе «цыплят» часто дешевле в разработке и эксплуатации. Но время от времени возникают требования, когда уместнее оказывается подход Сэймура Крэя.
«Если вам надо вспахать поле, то что вы используете: двух сильных волов или 1024 цыпленка»?
Любопытный факт: в ранних версиях AGI от Сьерры картики хранились в «векторном» формате. Когда-то у меня была мысль написать утилиту, которая бы преобразовывала эти изображения в современный SVG. В реальности картинки хранятся в виде набора команд граф. редактора, используется инструмент заливки и т.п. То есть это не привычная векторная графика, а процедурный формат, который довольно-таки зависим от разрешения. Возможно, кому-то будет интересно повозиться с этим форматом :)
Для тех, кому интересны тех. трюки разработчиков старых игр, могу советовать недавно вышедшую книгу Retrogame Archeology.
Увы, «дух» Бейсика все еще витает в коде. Собственно, третье переписывание кода на Питоне должно бы происходить уже без оглядки на оригинальный исходный текст. Но меня на этот этап не хватило. Много было потрачено времени на разбор оригинала на HP BASIC. Чтобы было понятнее, каким был оригинал, вот файлы: github.com/oubiwann/star-traders/tree/master/BASIC/HP-BASIC