[Гитаристам] GTP Linux
Есть ли аналог Guitar Pro, чтоб открывал табулатуры в формате gp3-gp5 для Линукса?
gp5 лично под ним открывал.
TuxGuitar (Осторожно, Java) или Guitar Pro под вайном (работает, но без звука, возможно руки такие).
Под вайном открой и хватит дурковать.
Гуйтар Про фигня по сравнению с TuxGuitar
0_o. А я даже и не заметил что жаба.
tuxguitar прекрасно с этим справляется. (увы, Java)
tuxguitar открывает все gtp*
то что java — не страшно, как ни странно, даже не тормозит.
ну и гитарпро под вайном отлично идет.
а вобще, снимать надо, а не табы гуглить :))
[troll_mode]табы не нужны, ноты — наше всё[/troll_mode]
По теме — раньше, до TuxGuitar, юзал kguitar
tuxguitar еще пилить и пилить.
можно на Guitar Pro поставить RSE и будет со звуком
Лучше купить нормальную звуковуху и скачать из интернета приличные банки. А если компьютер мощный, то и софтсинтез будет работать — можно будет обойтись встроенной карточкой.
и зачем? я эти программы использую только как смотрелки табов, просто со звуком удобнее. если играть — то лучше купить комбик + педальку
Источник
Гитаризм для линуксоида — why not?
Один мой хороший друг однажды сказал: — Линуксоидам проще научиться играть на гитаре. — Потому что они привыкли, что сначала долго мучаешься, но потом наслаждаешься результатом.
Он, безусловно, прав. И ниже я хочу рассмотреть некоторое ПО, призванное помочь линуксоиду-гитаристу на его нелёгком, но невероятно интересном пути.
TuxGuitar
TuxGuitar позволяет записывать партитуры и редактировать табулатуры. Поддерживает форматы Guitar Pro — .gp3, .gp4, .gp5 — и Power Tab Editor — .ptb. Есть и собственный формат .tg, хотя по умолчанию предлагается сохранение файлов в формате .gp4. Также можно работать с MIDI.
В Сети можно найти табулатуры в одном из поддерживаемых форматов почти для каждой достаточно известной композиции. У меня, например, лежит каталог с табулатурами для всех песен группы Metallica — постепенно знакомлюсь.
На некоторых системах TuxGuitar может не проигрывать звук и выдавать ошибку «Unavailable Soundbank Error». Решение данной проблемы описано здесь.
gtkguitune
Гитарный тюнер. Также известен как KGuitune и QtGuitune — это просто версии, использующие графическую библиотеку QT, вместо GTK. Снизу отображается играемая нота. Если кто не помнит, в стандартном строе ноты для открытых струн выглядят так: electric brain goes down any error (от первой до шестой). На моей гитаре, кстати, тюнер показывает ноты немного точнее, если переключиться на один из синглов (а не на хамбакер). А на акустической гитаре замечал хинт с пользой небольшого изменения взаимного расположения гитары и микрофона при настройке двух последних струн. Итак, надеюсь, строй держится и можно переходить к последней на сегодня программе.
А вот и программная примочка под Linux. Этакий «soft distortion». Для Linux’а, в принципе, есть несколько программ такого рода, но эта отличается тем, что очень сильно опережает все остальные.
Во-первых, само качество выдаваемого звука очень на высоте — присутствует реверберация и прочие эффекты, так приятные при игре с перегруженным звуком. Разумеется, для записи этого качества недостаточно и не может быть достаточно — для «настоящего» звука потребуется всё же железка, будь то комбик или, скажем, ламповая педаль. Но тут, кстати, проявляется другое преимущество Extreme Effect’а: можно играть и слышать перегруженный звук и в то же время записывать чистый. На практике это даёт возможность записать нужные партии и, впоследствии, «перегрузить» их на железном оборудовании. Можно также записать и перегруженный звук.
Другое, самое главное преимущество этой программы — отсутствие задержки. То есть мы берём медиатор, извлекаем звук и сразу же слышим его перегруженным. Кому-то, возможно, будет даже интересно покопаться в исходниках и посмотреть на реализацию этого «real-time механизма». Кстати, редкий случай, когда программу настоятельно рекомендуется запускать под суперпользователем, то бишь root’ом — это позволяет задать процессу достаточно высокий приоритет, чтобы сэкономить пользователю массу нервов.
Фактически, мы получаем, наверное, идеальное решение в ситуации, когда есть только гитара и компьютер. Ведь не все, кто покупает гитару, сразу покупают и примочку (потому что гораздо лучше купить хорошую гитару и через какое-то время хороший комбик, чем среднюю гитару и сразу средний комбик), а кроме того, можно представить ситуацию, когда человек берёт с собой куда-то ноутбук и гитару, а комбик уже никуда не лезет — и тогда спасают именно подобные программы.
Источник
Пора завязывать использовать пробелы вместо табуляции в коде
Этот топик — ответ на топик «Пора завязывать использовать символы табуляции в коде».
Я хотел было ответить к комментариях, но в силу объема и желания независимости от исходного топика решил создать новый топик.
Итак, под катом — почему табы лучше пробелов, самые значительные заблуждения касательно табов и как ими правильно пользоваться.
Начнём с того, что большинство людей (по крайней мере на Хабре) предпочитают табы.
По ссылке есть очень классный комментарий от GreyCat:
На самом деле странно то, что многие до сих пор не отличают indentation и alignment. Ну, вот это — indentation:
А вот это — alignment:
Первое можно делать и табами, и пробелами, но когда делаешь табами — каждый может подстроить ширину indent’а на свой вкус и ничего никуда не едет. А второе — строго пробелами.
В IDE есть опция Smart Tabs для этого:
Если правильно использовать табы (а именно — только для indentation) — можно без проблем менять размер табов не нарушая стиль программирования.
2 пробела на таб:
5 пробелов на таб:
9 пробелов на таб:
Так каких проблем мы лишаемся?
1. Каждый программист может настроить длину табуляции под свой вкус. Всегда работает на практике. Когда код с большой вложенностью — можно поставить ширину табуляции в два пробела, иначе — в четыре.
2. Легче работать с посторонними библиотеками. Какие-то библиотеки поддерживают стиль с шириной таба в два пробела, какие-то с шириной в четыре пробела. Только использование табов не накладывает ограничение на стиль.
Процитирую пару мыслей из предыдущего топика:
Тяжело работать с проектами, где используются библиотеки, содержащие в тесте табуляции. Предположим, в одной библиотеке табуляция равна 3 символам, в другой 4 символам. А вы в проекте используете 2 символа. В результате какая-то часть кода у вас будет отображаться в редакторе со сбитым форматированием.
На самом деле в проектах, которые используют табуляцию таких проблем нету — так как табуляция безразмерна, а вот поддерживать одновременно пару библиотек с разным размером пробело-табуляции становится проблематичным, т.к. уже нельзя пользоваться tab (чтобы IDE заменяла табы на пробелы). Конечно, есть шанс решить такую проблему разными проектами с разными настройками, но это тот еще костыль, да и башку все-равно сносит от разных размеров вложенности.
Легко пустить козла в огород. Скажем у вас табуляция равна 4 пробелам. Кто-то что-то чуть-чуть поправил, используя другой размер табуляции или явно вставив пробелы. У него все смотрелось нормально, а у вас строчка кода куда-то уедет.
Аналогично, табуляция — безразмерная. Такая проблема есть только в проектах, которые используют пробелы. Там где используются табы — они могут быть хоть 2, хоть 10 символов шириной.
Надо постоянно настраивать различные редакторы под нужный вам размер табуляции. Даже если вам нужно просто посмотреть код не правя. Иначе все разъезжается. Особенно это не удобно, когда приходится что-то делать со своим кодом на сторонней машине.
Допустим, я открываю Kate, чтобы по-быстряку поправить код в каком-то файле. Оппа, размер табуляции два пробела. Надо лезть в конфиг. А в соседнем файле из другой либы — четыре пробела. Придётся пользоваться пробелом вместо таба для отступов, ужас. С табами такой проблемы нету.
Лишние сложности тем, кто работает одновременно с проектами, где по стандартам кодирования требуются разные отступы. Если стандарты требуют использование табуляции, то это ещё тот вечно ноющий зуб. В случае пробелов опять-таки все намного проще.
Как выше разобрали, такая проблема есть именно с проблемами, а не с табами.
А еще дополнительно у пробелов есть такие недостатки, как невозможность быстрого перемещения стрелочками клавиатуры (щёлкает каждый пробел, а не через блок), возможность допустить ошибку (поставить в одном месте 3 пробела вместо 4, чем порушить дальнейшую структуру), увеличение размера файла и куча всего ещё.
Вывод
У пробелов нету ни одного существенного преимущество по сравнению с табами, при этом мы не сковываем программиста в рамки и не заставляем его мучаться с слишком маленькими (или слишком большими) для него табами.
Главное
Не так важно, что именно вы используете. Важно, чтобы вы следили за порядком своего кода и всегда придерживались одного и того же стиля. Включите отображение табов/пробелов, иногда меняйте размер табуляции на другой и пробегайте глазами код, чтобы удостоверится, что у вас где-то не вставились пробелы вместо табов или табы вместо пробелов.
Источник
Tab, spaces, GitHub
Есть небольшой проект, при создании использовались табы размером в 4 пробела (настройки IDE).
Теперь хочется выложить на GitHub, но там размер таба — 8, и всё становится неудобочитаемым. Как правильно сделать?
1. Заменить табы на пробелы, повесить на IDE плагин, улучшающий работу с пробелами как с табами (backspace стирает до ближайшего «таба», позиционирование курсорными клавишами по «табам» и т.д.)
2. Не менять, добавить .editorconfig указывающий размер таба
За табы в коде надо увольнять с волчьим билетом.
Мне кажется, для людей, которые не понимают, чем плохи табы в коде — отлично подойдут какие-то професси вне IT — например разносчик пиццы, продавец в евросети, дворник в конце концов. Но в IT им не место. Как впрочем и в любой другой области, требующей напряженной работы в команде.
Низкопробный похапист несёт светлую правду в тёмный мир IT.
Все верно сказал. IMHO, использование табов в коде довольно четкий критерий, выявляющий разработчиков не способных к работе в команде.
Любому нормальному человеку будет совершенно насрать, какие там у тебя табы и всё такое. Да хоть вообще без форматирования. Потому что если кому нужно посмотреть в код и чтоб красиво было — у тех есть indent которым можно сделать как нравится.
А так вообще — используй стиль сырцов ядра, да и всё. Будут вопросы — посылай нафиг и показывай средний палец.
Традиционно эти позиции располагаются каждые 8 знакомест, в колонках 1, 9, 17, 25
In practice, settable tab stops were rather quickly replaced with fixed tab stops, de facto standardized at every multiple of 8 characters horizontally.
Ну да, я выбрал, конечно. И в кучу текстовых редакторов лично Я это значение по умолчанию запихнул.
Есть куча вариантов, каким должен быть размер табуляции
Можно примеры не выставленные вручную?
Традиционно эти позиции располагаются каждые 8 знакомест, в колонках 1, 9, 17, 25
In practice, settable tab stops were rather quickly replaced with fixed tab stops, de facto standardized at every multiple of 8 characters horizontally.
Ну да, я выбрал, конечно. И в кучу текстовых редакторов лично Я это значение по умолчанию запихнул.
Я вот попробовал погуглить по «tab size» и увидел дополнение «2 or 4». Так что про 8 все давно забыли, кроме, разве что linux code style, который придумали тоже очень давно.
Можно примеры не выставленные вручную?
А кто-то еще пользуется табом в 8 пробелов?
попробовал погуглить по «tab size» и увидел дополнение «2 or 4»
где увидел? так 2 или 4? ты сам определиться не можешь, а лезешь опровергать, что 8 — по сути стандарт.
табуляция в 8 позиций гарантирует, если это целенаправленно не менять, что текст будет выглядеть везде одинаково и не уползёт за требуемое по code style число символов в строке.
ты точно читал текст темы ТС?
Верно, если вы про команды умственно отсталых похапистов. Обычные программисты никаких проблем не испытывают.
Ставишь курсор на начало int, нажимаешь Backspace, а «умное» IDE сносит 8 пробелов. Бесит.
Забинди вызов clang-format на хоткей и забудь этот онанизм как страшный сон. Пиши хоть в строку, хоть в столбик, машина расставит всё по своим местам и сделает это быстрее и качественнее любого WYSIWYG-мартыхана.
расставит всё по своим местам и сделает это быстрее и качественнее любого WYSIWYG-мартыхана.
ОРУ просто в голос. clang-format — и качественнее? Лол.
Качество — это uncrustify. Но оно не умеет в C++11.
Пиши хоть в строку, хоть в столбик, машина расставит всё по своим местам и сделает это быстрее и качественнее любого WYSIWYG-мартыхана.
У машины странное представление о качестве. Вот как её заставить сделать
Она либо всё гонит строкой, обрезая по ширине, либо переносит на каждой запятой. А надо, чтобы данные, которые относятся друг к другу были на одной строки, а остальные на отдельных строках.
Ничего не делать, к слову. Какая разница, как оно выглядит именно на сайте.
Неудобно ревьюить, коментить мердж-реквесты?
x, y, z свернуть в один тип и готово. Заодно они не перепутаются местами.
А кто-то еще пользуется табом в 8 пробелов?
те, кто пишут на golang
x, y, z свернуть в один тип и готово. Заодно они не перепутаются местами.
В смысле, вместо set_data(10, 42, 69, o, «ok») предлагаешь писать set_data(new coords(10, 42, 69), o, «ok»). Хотя как это поможет не перепутаться местами? И надо не забыть внутри set_data сделать delete.
Человеку, делающему отступы пробелами, неплохо подойдет работа начинающей секретарши (опытные-то уже умеют форматировать).
Давай уж разверни про табы. Впрочем, я сам их не использую никогда из-за религиозных фанатиков, которые могут и рожу начистить за ересь против ветхого завета вроде pep8.
Передавай структурки по значению. Лень проверять, но ЕМНИП в Intel ABI структура из double-ов будет передаваться эффективнее, чем отдельные аргументы, т.к. поля структуры упакуются в один XMM-регистр.
Так её всё равно придётся на стеке сначала заполнить. А при передаче по значению она ещё раз скопируется. Или покажи код, что ты имеешь в виду.
Например, сделать тип Cartesian, чтобы вместо x, y, z тебе не приехали rho, phi, theta. Например, сделать типы Rect, Point, Size чтобы вместо x1, y1, w, h тебе не приехало x1, y1, x2, y2 или x1, x2, y1, y2 или ещё что-нибудь. И т.д.
unique_ptr temp = make_unique (new temp);
Ты бухой что ли?
Он вроде лиспер.
Имелось в виду Itanium ABI
Точнее, AMD64 SysV ABI.
У clang-format очень мало опций.
человеку не соблюдающему код стайл группы и рекомендации по нему от разработчиков языка даже такая работа не подойдёт, ибо нормальное форматирование в офисных пакетах осуществляется стилями, а не табами
Например, сделать тип Cartesian, чтобы вместо x, y, z тебе не приехали rho, phi, theta.
Так в set_data вообще координаты не геометрические. Просто некоему набору измерений приписываются данные. И какая разница, как называется тип, который используется всего лишь для группировки аргументов?
Или претензии к семантике, а не к синтаксису?
там размер таба — 8, и всё становится неудобочитаемым. Как правильно сделать?
По-простому это означает, что таб в 8 пробелов никому не нужен. Но, ты конечно будешь продолжать упираться, что отступы должны быть только табами и их размер должен быть только 8 пробелов.
IMHO, отступы можно делать пробелами или табами, но пробелы «просто работают», причем всегда одинаково, а с табами внезапно временами возникают неприятности типа той, что описал ТС. Поэтому разработчики с опытом (если они не упертые бараны) предпочитают пробелы (в командной работе), чтобы каждому члену команды не приходилось настраивать размер таба в каждом приложении (не только IDE), в котором приходится смотреть код хотя бы раз, а также бороться с приколами типа скопипастили код, в редакторе, который при копировании заменит табы на пробелы (например, во время быстрой правки в том же GitHub или другом редакторе, вместо настроенной на табы IDE) и после этого получаем смешение отступов табами и пробелами (в результате чего код выглядит как говно). Еще есть шанс, что код с пробелами придет в виде pull request, а очень не многие рецензенты будут загружать его в IDE и править отступы, чаще просто нажмут кнопку «Принять» в веб.
Отступы табами — удел зеленых студентов с избытком образования и недостатком опыта, которым на лекциях сказали как «правильно» делать (они и делают, пока не наберутся опыта и не поймут, что делать надо как удобнее, причем всем в команде, тут удобство рассчитывается исходя из соотношения полезности/ценности для проекта и требуемых затрат, а «правильность» — это чисто субъективное мнение человека, причем у разных людей «правильно» может быть разным). В реальной разработке есть более актуальные задачи, чем борьба с косяками типа описанных ТС (а они будут проявляться регулярно).
Отступы табами, выравнивание пробелами — это вообще диагноз. Признак упертого барана, которому плевать на всех кроме себя. Признак человека с подходом: есть два мнения — мое и неправильное. Такой кадр будет лезть в бычку по поводу любого решения в команде, если оно не не совпадает с его мнением и бодаться до тех пор пока не прожмет свое мнение как единственно правильное. Такие перцы неспособны к работе в команде, а потому как разработчики профнепригодны.
Если коротко, то суть в том, что можно выравнивать табами, можно пробелами, но пробелами надежнее, а бороться с косяками типа описанных ТС в реальной разработке некогда (да и не нужно, если использовать пробелы), есть более актуальные задачи.
А теперь расскажи, зачем ты выбираешь выравнивание табами и топишь за размер таба в 8 символов (что вообще никто сейчас не использует)?
Забинди вызов clang-format на хоткей и забудь этот онанизм как страшный сон.
И займись настройкой clang-format.
IMHO, выравнивание — это визуальный способ сделать код более читаемым и понятным для человека, а потому именно человек должен решать какое должно быть выравнивание. Машина лишь помогает в этом, а потому AutoIndent нужно вызвать вручную в IDE и визуально контролировать результат. QtCreator у меня код с лямбдами автоматом превращает в говно, я его исправляю в (полу)ручную. Если какой-то clang-format вызванный автоматом испоганит выравнивание, да еще и эти строки (не относящиеся к изменениям в очередном diff-set) появятся в очередном diff’е, потому что там изменилось количество пробелов и рецензенту придется на них отвлекаться, то нафиг такой инструмент.
x, y, z свернуть в один тип и готово. Заодно они не перепутаются местами.
Абалденно! Поменять API, чтобы машине было удобнее, потому что по-другому она не умеет, а у оператора слишком крепкие заморочки, чтобы отказаться от них.
А кто-то еще пользуется табом в 8 пробелов?
Да, у чуваков, когда они изобретали UNIX, C, Linux табы были 8 символов, с тех пор, когда они пишут стандарт, там указана эта цифра. У всех остальных 4, реже 2 (есть любители 3 и, даже, 5), но не 8. Эти динозавры все еще полезны, за это их и держат (хотя даже динозавры часто бывают более гибкими и способными к адаптации, чем многие студенты, которые так и живут с синдромом утенка).
Лучше ты скажи, где я заявлял, что отступы должны быть табами? Я считаю, если не оговорено codestyle, что отступы должны быть пробелами. А вот если используется табуляция, как например, принято в ebuild файлах, то табуляцтя должна переносить курсор на позиции кратные 8 — по крайней мере это позволит соблюдать ограничения на длину строки, если таковое есть.
Вы больны синдромом Дауна? Табы для того и нужны, чтобы спокойно работать в команде, а не трахаться с «единственно верной» хотелкой лавсанчика, желающего отступы в 11,5 пробелов.
Ну зато те что есть, работают. (Почти все.)
Источник
