А ощущение «мыльной оперы», «документалки» и «компигры» — это просто мозг мечется, не привычный к новому стандарту.
У меня есть предположение, что здесь ещё сказывается и отношение к декорациям: декорации, применяемые в кино в 70-80 быстро входили в контекст и воспринимались как «реальность» фильма. Те же самые декорации в театре воспринимаются именно как декорации и требуют отдельного перестроения восприятия под контекст.
Аналогично — при увеличении качества картинки и приближения её к реалиям, потребуется более тщательно относится к вопросу воссоздания кинореальности. При современных достижениях компьютерного моделирования это уже не должно быть большой проблемой, на мой взгляд.
И само собой — в немалой степени здесь сказывается привычка: вспомните, как воспринимались раньше фильмы Кинг-Конг, Терминатор, и классика жанра — Годзилла и прочие возвращения динозавров. :)
Это было восхитительно и пугающе реально. А нынче восприятие уже настолько привыкло к более сильным эффектам и кинореальности, что старые фильмы воспринимаются с улыбкой.
Следите за выходным уровнем на мастер-шине: не допускайте клипирования сигнала (превышение порога 0 дБ), а лучше сохраняйте дистанцию до порога (-2, -3 дБ).
Лучше оставить запас побольше: итоговый трек перед мастерингом обычно имеет запас по уровню до 6 (шести) дБ. Да и у многих профессиональных мастров звуковых дел именно 6 дБ фигурирует в качестве цифры хорошего запаса по уровню.
В любом случае на мастеринге фонограмму надо будет «плющить» как минимум максимайзером (если это не тихая песня в акустическом варианте), поэтому лучше обезопасить себя, и оставить запас чуть побольше: это позволит на мастеринге более комфортно работать с конечным миксом.
Для начала вам нужно определиться, что вы имеете ввиду, когда говорите «улучшить» звук живого инструмента.
Но вообще, самый простой вариант для того, чтобы «пощупать» звук: записать звучание инструмента сразу двумя микрофонами (в данном случае я имею ввиду электрогитару), при этом микрофоны снимают разный звук с динамика (например один установлен под углом и направлен на середину, а второй снимает мембрану чуть в стороне от оси). И после этого крутить баланс этих двух треков, выясняя, что именно вам нужно (вообще расстановка микрофонов — это отличный вариант изменить звук, но и редкостный геморрой при этом).
Если писать «домашний вариант», то треки пишутся в линию, а уже потом обрабатываются на компьютере, в зависимости от требований к звучанию. Тут вариантов может быть масса.
Но опять же — это в зависимости от звука и музыки, понятно, что для фанка вам потребуется одно (прозрачный звук гитары), а для метала — совершенно другое звучание (тут на помощь приходят даблтреки, а в экстремальных случаях и для достижение некоторых специфических нюансов — даже квадраплы для треков).
Поэтому внимательно анализируйте, сравнивайте и думайте, чего вам не хватает. Исходя из этого уже можно что-то предпринимать.
Как мне кажется, суть статьи не в том, что автор пробует силы в писательстве, а в том замечательном, на мой взгляд, подходе, когда правит бал содержимое, а всё оформление направлено на то, чтобы удобно и приятно это содержимое преподнести.
За такой доскональный подход и внимание к удобству читателя, автору почёт и уважение.
Меня конечно раздражает безграмотность, но в данном случае этот недостаток с лихвой окупается способом подачи материала. Мне так кажется. :)
А если внезапно в AppStore завернут приложение на ревью, с какой либо отсылкой на код, ну например в виде некорректного использования приватных фреймворков из iOS SDK?
В такой ситуации все вопросы к настройкам/версиям Air? Или существуют какие-то другие способы устранения подобных неприятностей?
Хм. А вот, к примеру, при подключении к Game Center от Apple получил предложение прочитать лицензию для начала. Если мне не изменяет память — 54 страницы.
Прочитал только первую страницу. Затем взглядом зацепился за количество страниц и со словами «ну и хрен с ним», закрыл соглашение.
Поэтому мой вариант: «Да, читаю местами». Не будем уточнять, какими. :)
А я не понимаю одного: неужели тролль, подавший иск, в случае проигрыша по необоснованной претензии, никак не должен компенсировать это? Например оплатить судебные издержки, и тому подобное.
Ведь если нет, то это просто дичайший невод для ловли компаний: закидываешь кучу исков, и хотя бы в одном-двух, но перепадёт что-нибудь.
А если заставить компенсировать расходы (а несидящих в тюрьмах — обязательно присутствовать на слушании, дорога — за свой счёт), то мне кажется многократно поубавиться желающих влезть в необоснованную тяжбу.
А в PHP достаточно такого: $a = (int|bool|array|string|object)$a;
Ну в этом-то и дело.
Сейчас ради интереса посмотрел в мануал по PHP: найти описание явного приведения типов намного проще, и легче запомнить, чем немаленькие таблицы неявных приведений.
Отсюда вопрос: кто будет сознательно использовать приведение типов через арифметические (строковые) операции?
Ну и в той же Java: ну кому, кому блин может придти в голову, намеренно преобразовать число в строку через конкатенацию числа и строки? :)
Ну я еще могу понять, когда появляются странные штуки при реализации логики, взаимодействия классов. Но вот такой хитровыкрученный пример — это явный «изыск».
Издательство, выпустившее книгу «BitTorrents for dummies» теперь подаёт в суд на пользователей, которые прочитали «BitTorrents for dummies» и распространяют «BitTorrents for dummies» через BitTorrent. :D
В принципе кардинальных отличий от других специальностей нет. В процессе обучения должны давать общую базу: алгоритмы, структуры. Другое дело, что очень желательно для налаживания стойких ассоциаций обучать и на конкретном примере. Например, как у механиков:
Получаешь знания о механизмах, о схемах, о проектировании, об инженерных рассчётах, о коэффициентах (прочности, запаса, упругости и проч.), о материалах и их свойствах. Но без практики — это ничто. Как минимум — нужны показательные лабораторные работы, для понимания даваемых принципов. Причём курсовой (дипломный) проект сам по себе, в отрыве от реального применения, даёт немного и немногим. Только те, у кого хорошо развито абстрактное мышление, чётко усиваивают материал и лишь потом, впервые столкнувшись на практике с механизмами, умеют определить требуемые ассоциации, что конечно весьма и весьма полезно. Не зря, например, для инженеров-механиков автомобилестроения в обязательном порядке даётся не только теоретический курс, но и практика вождения и ремонта (!). Не в объемах автослесаря, но вполне достаточно, для практического применения учебного материала.
Обычно на курс подготовки дают какой-нибудь ЗИЛ 130 и ВАЗ-2101. Исключительно для понимания общих принципов построения машины в целом.
И вот потом, если возникает необходимость разобраться с какой-либо другой моделью — то тут эта практика и пригождается: ассоциации позволяют провести параллели и применить известные принцимы для понимания.
— О, смотри-ка, у них двигатель находится в задней части, а по выполняемым функциям тоже самое! А, всё дело в организации передающей цепи! Извернулись, да…
И понятное дело, что для понимания механизмов работы современных нафаршированных авто-изделий придётся проштудировать мануал к ним, и разбираться с организацией электронного хозяйства. Но базовый принцип, закреплённый ассоциациями никуда не пропал — всё тоже самое.
Так вот, завершая это художественное отступление, замечу, что программисты, получавшие в процессе обучения практические навыки («хакерствуя», работая параллельно с учёбой, или учавствуя в различных проектах) вынесут для себя ассоциативные цепочки, которые позволят взглянуть на каждый новый язык (проект) абстрагируясь от конкретной реализации. И после этого — уже проще будет вникнуть в остальное.
Посему всякие руководства по языкам, начинающиеся с традиционного «Hello World!» даются легко и просто тем, кто уже имеет хоть какую-то практику программирования. А вот наглядного, пошагового введения в какой-либо конкретный язык — практически не бывает.
И если в процессе учебной подготовки ввести участие в довольно крупном проекте, который должен постепенно развиваться с самого начала (да пусть это будет написание своего, учебного фреймворка, или нафаршированного блого-движка, неважно), то эта практика позволит понять собственно сам принцип построения программных систем и их возможную (!) реализацию.
На хабре были несколько статей, где хабражители рассказывали о внедрении некоторых проектов в учебный процесс, и негативных последствий не наблюдалось. Кто хотел — учавствовал и получал дополнительные навыки, которые обязательно пригодятся даже при первом трудоустройстве.
Но как обычно, тут возникает другой вопрос: а на каком языке вести этот проект? На достаточно простом, чтобы въехало большинство, или на достаточно сложном, чтобы чётко дать понятие о важности чётком и внятном построении элементов программной системы? :)
Я склоняюсь к мысли о втором, обязательно компилируемом. Обязательна работа с репозиторием, чтобы всегда можно было отследить, кто и где допустил ошибку, разобрать её и на непосредственном примере исправить.
Вобщем небольшой проект в условиях, приближенных к боевым. Это непросто, но зато такой студент придёт на работу уже имея представление о командной работе и опыт программирования конкретного проекта с конкретной функциональностью.
Понимаете, тут приходится выходить на скользкую тропу взаимодействия с пользователем: сделать всё как надо — и придётся пользователю сидеть и внимательно смотреть, что за программа, чего хочет, почему.
Собственно проблема в том, что обычному пользователю это не интересно. Он покупает продукт, и хочет чтобы всё работало и его не спрашивало. :)
У меня года три-четыре назад была ситуация, когда у антивируса истёк срок действия ключа, и он отключился. Я остался сидеть за файрволом с хорошей функциональностью, который предупреждал обо всех левых движениях программного обеспечения и подозрительной активности. В таком режиме я просидел около полутора лет с использованием интернетов и ни одного прецендента с вирусами-троянами.
Моим способом защиты заинтересовался товарищ, и опробовал его. Хватило его примерно на три дня, после чего с криками «задрало оно меня!» он снёс к чертям этот продвинутый и надёжный файрволл и поставил старый добрый (и конечно крякнутый) антивирь.
Так что для антивирусных контор это также сложный вопрос баланса между хотениями пользователя и настоящей безопасностью. И это — помимо других проблем, которые возникают при написании антивирусов.
Слушания по судебному делу о сохранении файлов с YouTube.
Истец: Мы запретили сервисы для скачивания, но тут оказалось, что браузер хранит просмотренные файлы в кэше. В связи с этим мы требуем, чтобы производители браузеров выплатили нам упущенную выгоду от скачивания этих файлов.
Судья: Всех браузеров?
Истец: Ну что вы! Мы же не какие-то дикари! Только тех браузеров, которые сохраняют файлы в кэше.
Ответчик: Протестую, ваша честь! Кэши, которые мы используем, защищены патентами, и не противоречат законодательству. Таким образом этот иск не может быть удовлетворён без нарушения права собственности на эти патены. В этом случае Истец должен будет выплатить нам компенсацию за отказ от использования наших собственных патентов.
Судья: Хм, всех?
Ответчик: Ну что вы! Только тех, которые связаны с кешированием данных в браузерах.
Истец: Ээээээ… Подождите, как это? МЫ должны вам платить что-ли?
Ответчик: ну да. За ущемление законного права на использование патентов.
Истец: Так. Подождите, это какой-то странный вариант развития событий. Ваша честь! Мы хотим отказаться от текущего иска и подать иск на пользователей интернета, которые устанавливают браузеры, позволяющие кэшировать содержимое интернетов!
Ответчик с Судьей: Всех?
Истец: Не, ну почему? Только тех которые позволяют кэшировать наши файлы.
Судья: Список файлов, запрещённых к кэшированию у вас имеется?
Истец: Вообще-то нет. Но мы готовы его предоставить.
Ответчик: на все файлы?! О_О
Истец: Не, ну почему же на все? Только на те, которые нельзя кэшировать.
На самом деле закономерный и правильный (!) процесс. Мир меняется, и появляются новые возможности.
Кто придумает как правильно их использовать, чтобы получить допольнительный плюс, тот и будет на коне.
И также как и в прочих новых возможностях — сами по себе они ничто. Если музыка уныла и безвкусна, то никакие «фишки» её не спасут. Если же музыка интересна, то эти «фишки» могут сделать прослушивание более интересным, а также — позволят раскрыть какие-то дополнительные грани творчества.
Когда-то придумали играть на перегруженном усилителе. И туева хуча групп стала это использовать. Но — пробились лишь те, кто представлял действительно интерес.
Потом появились всякие хитрые эффекты, и все повально ломанулись туда, но и тут выжили только те, кто что-то стоит.
И пока кто-то пытается выжать максимум из старого проверенного подхода (который, тем не менее стал давать сбои в новом мире), те, у кого с творческой потенцией всё в порядке, ищут новые пути и решения. :)
Вы хоть читали топик? :)
Автор поехал работать по своему профилю, его всё устраивает, и это то, чего он хотел. Даже если он в приступе эйфории от того что всё получилось — это всё равно опыт и в конце концов — он сделал что хотел, а не сидел на одном месте плача о том, что ему плохо.
А зарплата… Главное — чтобы хватало. А кому и сколько хватает — это уже другой вопрос.
У меня есть предположение, что здесь ещё сказывается и отношение к декорациям: декорации, применяемые в кино в 70-80 быстро входили в контекст и воспринимались как «реальность» фильма. Те же самые декорации в театре воспринимаются именно как декорации и требуют отдельного перестроения восприятия под контекст.
Аналогично — при увеличении качества картинки и приближения её к реалиям, потребуется более тщательно относится к вопросу воссоздания кинореальности. При современных достижениях компьютерного моделирования это уже не должно быть большой проблемой, на мой взгляд.
И само собой — в немалой степени здесь сказывается привычка: вспомните, как воспринимались раньше фильмы Кинг-Конг, Терминатор, и классика жанра — Годзилла и прочие возвращения динозавров. :)
Это было восхитительно и пугающе реально. А нынче восприятие уже настолько привыкло к более сильным эффектам и кинореальности, что старые фильмы воспринимаются с улыбкой.
Лучше оставить запас побольше: итоговый трек перед мастерингом обычно имеет запас по уровню до 6 (шести) дБ. Да и у многих профессиональных мастров звуковых дел именно 6 дБ фигурирует в качестве цифры хорошего запаса по уровню.
В любом случае на мастеринге фонограмму надо будет «плющить» как минимум максимайзером (если это не тихая песня в акустическом варианте), поэтому лучше обезопасить себя, и оставить запас чуть побольше: это позволит на мастеринге более комфортно работать с конечным миксом.
Но вообще, самый простой вариант для того, чтобы «пощупать» звук: записать звучание инструмента сразу двумя микрофонами (в данном случае я имею ввиду электрогитару), при этом микрофоны снимают разный звук с динамика (например один установлен под углом и направлен на середину, а второй снимает мембрану чуть в стороне от оси). И после этого крутить баланс этих двух треков, выясняя, что именно вам нужно (вообще расстановка микрофонов — это отличный вариант изменить звук, но и редкостный геморрой при этом).
Если писать «домашний вариант», то треки пишутся в линию, а уже потом обрабатываются на компьютере, в зависимости от требований к звучанию. Тут вариантов может быть масса.
Но опять же — это в зависимости от звука и музыки, понятно, что для фанка вам потребуется одно (прозрачный звук гитары), а для метала — совершенно другое звучание (тут на помощь приходят даблтреки, а в экстремальных случаях и для достижение некоторых специфических нюансов — даже квадраплы для треков).
Поэтому внимательно анализируйте, сравнивайте и думайте, чего вам не хватает. Исходя из этого уже можно что-то предпринимать.
Как мне кажется, суть статьи не в том, что автор пробует силы в писательстве, а в том замечательном, на мой взгляд, подходе, когда правит бал содержимое, а всё оформление направлено на то, чтобы удобно и приятно это содержимое преподнести.
За такой доскональный подход и внимание к удобству читателя, автору почёт и уважение.
Меня конечно раздражает безграмотность, но в данном случае этот недостаток с лихвой окупается способом подачи материала. Мне так кажется. :)
А если внезапно в AppStore завернут приложение на ревью, с какой либо отсылкой на код, ну например в виде некорректного использования приватных фреймворков из iOS SDK?
В такой ситуации все вопросы к настройкам/версиям Air? Или существуют какие-то другие способы устранения подобных неприятностей?
Прочитал только первую страницу. Затем взглядом зацепился за количество страниц и со словами «ну и хрен с ним», закрыл соглашение.
Поэтому мой вариант: «Да, читаю местами». Не будем уточнять, какими. :)
Хм. А яблочко-то — с гнильцой! Не по джентльменски это как-то.
Ведь если нет, то это просто дичайший невод для ловли компаний: закидываешь кучу исков, и хотя бы в одном-двух, но перепадёт что-нибудь.
А если заставить компенсировать расходы (а несидящих в тюрьмах — обязательно присутствовать на слушании, дорога — за свой счёт), то мне кажется многократно поубавиться желающих влезть в необоснованную тяжбу.
Или не так?
Ну в этом-то и дело.
Сейчас ради интереса посмотрел в мануал по PHP: найти описание явного приведения типов намного проще, и легче запомнить, чем немаленькие таблицы неявных приведений.
Отсюда вопрос: кто будет сознательно использовать приведение типов через арифметические (строковые) операции?
Ну и в той же Java: ну кому, кому блин может придти в голову, намеренно преобразовать число в строку через конкатенацию числа и строки? :)
Ну я еще могу понять, когда появляются странные штуки при реализации логики, взаимодействия классов. Но вот такой хитровыкрученный пример — это явный «изыск».
Получаешь знания о механизмах, о схемах, о проектировании, об инженерных рассчётах, о коэффициентах (прочности, запаса, упругости и проч.), о материалах и их свойствах. Но без практики — это ничто. Как минимум — нужны показательные лабораторные работы, для понимания даваемых принципов. Причём курсовой (дипломный) проект сам по себе, в отрыве от реального применения, даёт немного и немногим. Только те, у кого хорошо развито абстрактное мышление, чётко усиваивают материал и лишь потом, впервые столкнувшись на практике с механизмами, умеют определить требуемые ассоциации, что конечно весьма и весьма полезно. Не зря, например, для инженеров-механиков автомобилестроения в обязательном порядке даётся не только теоретический курс, но и практика вождения и ремонта (!). Не в объемах автослесаря, но вполне достаточно, для практического применения учебного материала.
Обычно на курс подготовки дают какой-нибудь ЗИЛ 130 и ВАЗ-2101. Исключительно для понимания общих принципов построения машины в целом.
И вот потом, если возникает необходимость разобраться с какой-либо другой моделью — то тут эта практика и пригождается: ассоциации позволяют провести параллели и применить известные принцимы для понимания.
— О, смотри-ка, у них двигатель находится в задней части, а по выполняемым функциям тоже самое! А, всё дело в организации передающей цепи! Извернулись, да…
И понятное дело, что для понимания механизмов работы современных нафаршированных авто-изделий придётся проштудировать мануал к ним, и разбираться с организацией электронного хозяйства. Но базовый принцип, закреплённый ассоциациями никуда не пропал — всё тоже самое.
Так вот, завершая это художественное отступление, замечу, что программисты, получавшие в процессе обучения практические навыки («хакерствуя», работая параллельно с учёбой, или учавствуя в различных проектах) вынесут для себя ассоциативные цепочки, которые позволят взглянуть на каждый новый язык (проект) абстрагируясь от конкретной реализации. И после этого — уже проще будет вникнуть в остальное.
Посему всякие руководства по языкам, начинающиеся с традиционного «Hello World!» даются легко и просто тем, кто уже имеет хоть какую-то практику программирования. А вот наглядного, пошагового введения в какой-либо конкретный язык — практически не бывает.
И если в процессе учебной подготовки ввести участие в довольно крупном проекте, который должен постепенно развиваться с самого начала (да пусть это будет написание своего, учебного фреймворка, или нафаршированного блого-движка, неважно), то эта практика позволит понять собственно сам принцип построения программных систем и их возможную (!) реализацию.
На хабре были несколько статей, где хабражители рассказывали о внедрении некоторых проектов в учебный процесс, и негативных последствий не наблюдалось. Кто хотел — учавствовал и получал дополнительные навыки, которые обязательно пригодятся даже при первом трудоустройстве.
Но как обычно, тут возникает другой вопрос: а на каком языке вести этот проект? На достаточно простом, чтобы въехало большинство, или на достаточно сложном, чтобы чётко дать понятие о важности чётком и внятном построении элементов программной системы? :)
Я склоняюсь к мысли о втором, обязательно компилируемом. Обязательна работа с репозиторием, чтобы всегда можно было отследить, кто и где допустил ошибку, разобрать её и на непосредственном примере исправить.
Вобщем небольшой проект в условиях, приближенных к боевым. Это непросто, но зато такой студент придёт на работу уже имея представление о командной работе и опыт программирования конкретного проекта с конкретной функциональностью.
P.S. извините, разошёлся. :)
Собственно проблема в том, что обычному пользователю это не интересно. Он покупает продукт, и хочет чтобы всё работало и его не спрашивало. :)
У меня года три-четыре назад была ситуация, когда у антивируса истёк срок действия ключа, и он отключился. Я остался сидеть за файрволом с хорошей функциональностью, который предупреждал обо всех левых движениях программного обеспечения и подозрительной активности. В таком режиме я просидел около полутора лет с использованием интернетов и ни одного прецендента с вирусами-троянами.
Моим способом защиты заинтересовался товарищ, и опробовал его. Хватило его примерно на три дня, после чего с криками «задрало оно меня!» он снёс к чертям этот продвинутый и надёжный файрволл и поставил старый добрый (и конечно крякнутый) антивирь.
Так что для антивирусных контор это также сложный вопрос баланса между хотениями пользователя и настоящей безопасностью. И это — помимо других проблем, которые возникают при написании антивирусов.
В конце концов «социальная инженерия» и ленивые сотрудники еще не перевелись.
Слушания по судебному делу о сохранении файлов с YouTube.
Истец: Мы запретили сервисы для скачивания, но тут оказалось, что браузер хранит просмотренные файлы в кэше. В связи с этим мы требуем, чтобы производители браузеров выплатили нам упущенную выгоду от скачивания этих файлов.
Судья: Всех браузеров?
Истец: Ну что вы! Мы же не какие-то дикари! Только тех браузеров, которые сохраняют файлы в кэше.
Ответчик: Протестую, ваша честь! Кэши, которые мы используем, защищены патентами, и не противоречат законодательству. Таким образом этот иск не может быть удовлетворён без нарушения права собственности на эти патены. В этом случае Истец должен будет выплатить нам компенсацию за отказ от использования наших собственных патентов.
Судья: Хм, всех?
Ответчик: Ну что вы! Только тех, которые связаны с кешированием данных в браузерах.
Истец: Ээээээ… Подождите, как это? МЫ должны вам платить что-ли?
Ответчик: ну да. За ущемление законного права на использование патентов.
Истец: Так. Подождите, это какой-то странный вариант развития событий. Ваша честь! Мы хотим отказаться от текущего иска и подать иск на пользователей интернета, которые устанавливают браузеры, позволяющие кэшировать содержимое интернетов!
Ответчик с Судьей: Всех?
Истец: Не, ну почему? Только тех которые позволяют кэшировать наши файлы.
Судья: Список файлов, запрещённых к кэшированию у вас имеется?
Истец: Вообще-то нет. Но мы готовы его предоставить.
Ответчик: на все файлы?! О_О
Истец: Не, ну почему же на все? Только на те, которые нельзя кэшировать.
Интернет-пользователи: *facepalm* ИДИОТЫ!
Истец, Ответчик и Судья: Что, все?
Кто придумает как правильно их использовать, чтобы получить допольнительный плюс, тот и будет на коне.
И также как и в прочих новых возможностях — сами по себе они ничто. Если музыка уныла и безвкусна, то никакие «фишки» её не спасут. Если же музыка интересна, то эти «фишки» могут сделать прослушивание более интересным, а также — позволят раскрыть какие-то дополнительные грани творчества.
Когда-то придумали играть на перегруженном усилителе. И туева хуча групп стала это использовать. Но — пробились лишь те, кто представлял действительно интерес.
Потом появились всякие хитрые эффекты, и все повально ломанулись туда, но и тут выжили только те, кто что-то стоит.
И пока кто-то пытается выжать максимум из старого проверенного подхода (который, тем не менее стал давать сбои в новом мире), те, у кого с творческой потенцией всё в порядке, ищут новые пути и решения. :)
Это хорошо!
Автор поехал работать по своему профилю, его всё устраивает, и это то, чего он хотел. Даже если он в приступе эйфории от того что всё получилось — это всё равно опыт и в конце концов — он сделал что хотел, а не сидел на одном месте плача о том, что ему плохо.
А зарплата… Главное — чтобы хватало. А кому и сколько хватает — это уже другой вопрос.
"… ЕСЛИ в РАО обратятся музыканты DP за своими авторскими отчислениями". :)
Схема весьма увлекательная.