Getting Started with Music Software

[Thad]

I found this on a long stretch of threads. I haven't seen it put so comprehensively as to what might make a creative community.

The original quest that lead me to this is that I am struggling hugely to understand music software. I have cakewalk sonar home studio 7xl. If anyone can respond with what worked at the beginning of their study I would thank you hugely but here's the page and the links in reverse order at the bottom.
___________________________________

Channel Guidelines IRC is a low-bandwidth method of communication, in comparison with physical presence. Many of the cues of physical communication, tone of voice, facial expression, hand movements, etc., are missing in IRC, since only text is transmitted back and forth.
Speakers in physical proximity with each other communicate quite a bit of emotional context via this extra bandwidth. This context enables them to avoid misjudging the intent of their conversational partners. It also functions as an unconscious negative feedback mechanism to reduce the incidence of emotional "firestorms" which tend to disrupt the efficient flow of conversation. Human beings look for this feedback and indeed they may be designed to require it. In the low-bandwidth world of IRC, they must get emotional feedback via the text they receive.
This process is subject to exaggeration. Small amounts of emotion become magnified in the perception of the observer. So, it is very important to keep channels calm. An informal conceptual measurement of the emotional content of a channel is its "channel temperature."
Think of a person's emotional state as kinetic energy. Enthusiasm, happiness, anger, frustration, all add to the energy level. The more emotion is experienced, the "hotter" the participant. The average emotional state of a channel is its temperature. Emotions in IRC become exaggerated and conveying them directly increases channel temperature. Pent-up frustration, in particular, is often released as a series of inappropriate, "high energy" outbursts. An important objective of the freenode channel guidelines is to avoid "feedback loops" in channel interactions by reducing channel temperature.
The guidelines which follow are designed with the benefit of years of experience with IRC, beginning during the 1993-1994 period when the design limitations of IRC began to become clear due to the increasing scale of IRC networks. Adopting the guidelines will help improve the quality of your channel.
We intentionally avoid drawing a distinction between channel operators and users. Everyone is a user, regardless of their privilege level, and each user has the ability to influence the usability of the channel.
Guidelines:

• Polish your catalyst skills. The catalyst role is key to keeping channel interactions friendly and efficient.
• Look for the best in people. If you assume people have no self-control, they'll confirm your belief. If you look for personal responsibility, and ask for personal responsibility, most people will respond well.
• Set a good example. Be what you want other people to be. If you want them to be calm, be calm. If you want them to be courteous and friendly, be courteous and friendy. The habitual behavior of people on a channel is the most powerful influence on newbies arriving on the channel.
• Be nice if someone messages you. They've gone to the trouble to seek out someone with the background to help them. You're it! Be flattered they've singled you out. If you think they'll get better support by asking their question on channel, just let them know.
• Don't keep channel operator privileges. Displaying these privileges on your nick with a "+o" attracts participants who are interested in gaining them and using them actively; it also attracts the attention of participants who react negatively to authority. Have your nick added to the channel access list and op yourself only when needed.
• Use channel operator privileges sparingly. Each time you use them you raise the channel temperature. Users will be pleased with you, angry at you, frustrated that you used them inappropriately, envious that you have control over the discussion. None of these reactions may be conscious on the part of other users, but all of them increase the channel temperature.
• Avoid highlighting and repetition. Words and sentences in all-uppercase, heavy use of highlighting, beeping (^G) on public channels, repeating the same lines over and over--all of these behaviors irritate people and raise the channel temperature.
• Avoid emotive speech. Slang pertaining to sex and sexual orientation, excretion and religious oaths is rarely used to discuss the applicability of those topics to your group's activities. In general, language with strong emotional content and only light meaning should be considered "emotive speech". It doesn't matter whether the language is socially acceptable or unacceptable. For example, use of the word "fsck" which does not refer to a Unix filesystem check is emotive. Similarly, use of the word "gay" which has nothing to do with homosexuality is emotive. Emotive speech raises the channel temperature.
• Avoid sensitive material. Some users on freenode channels, particularly on public channels, are quite young. Others are parents or teachers who might have young children nearby. As you type comments or ASCII art, or post URLs for others to view, please consider the age range of other users on your channel, and respect the right of parents and teachers to decide when and if to expose the children in their charge to material or language which might offend, confuse or raise difficult issues.
  
  Additionally, some of our users connect to freenode from corporate environments. Employers may be unhappy with the unexpected appearance of sensitive material on workplace computers. Please be considerate and avoid posting such material when you're not completely sure it's safe to do so.
• Avoid advocacy debates. BSD versus GPL, vi versus emacs, centralized versus decentralized, RMS versus ESR: these discussions are frequently religious and may not involve significant new ideas. They can also raise the channel temperature quite a bit. Certain advocacy discussions, such as those revolving around actual religion or politics, are almost guaranteed to raise the channel temperature to levels that make other conversation difficult.
  
  You might not get too worked up if you're arguing the relative merits of poll() or kqueue(), but if you walk into a discussion with a strong emotional need to "get your way," consider the possibility you are simply arguing preference or personal affiliation. Advocacy discussions are best held quietly, via /msg, or on channels especially created for the purpose.
• Take critiques to private message. Criticizing someone's behavior on channel holds them up to public scrutiny in a negative way. It's usually overkill. In your messages, don't address the subject of whether you have channel operator privileges; just be courteous. Request nicely that they change their behavior. In many cases you'll discover that problem user you are dealing with is merely inexperienced. An aggressive tone makes for a longer and more involved discussion, and pent-up frustration which will raise the channel temperature sooner or later. You can always use channel operator privileges, or have someone else use them, as needed; but with a courteous tone, you'll need to do that a lot less.
• Don't be elitist. Today's newbies are tomorrow's experts. A support channel is a place where people with knowledge lead by example. Is the example you want to set that technical knowledge is a hierarchy of control, or that people with knowledge have an inherent social advantage over people who don't? Please think before referring people to links such as this one, which combine suggestions for making support requests with a casual attitude of superiority over the newbie. Helping other people takes patience. It's better not to answer a question than to use the opportunity to emphasize the limitations of the person you're trying to help.
• Don't be caught by support burnout. It's nearly impossible to answer every technical question that comes to your channel. In many cases, the problem doesn't lie in the technical aspects of the question; cultural barriers may get in the way of communication, or it may be difficult to explain to a newbie just where to begin. When you try to answer every question, regardless of difficulty, you set yourself up for support burnout.
  
  Support burnout is nearly always accompanied by the feeling that you're losing control of your time, that the people you've set out to help are making unreasonable demands. The problem is that you're taking on too much responsibility; but it begins to appear instead that the problem is the end user who's asking for help.
  
  Different people react to support burnout in different ways. Some offer malicious advice ("rm -rf /" etc.) to newbies. Some insist that every question a newbie asks should be answered with a URL or by lists of manual references. When the staff of a support channel suffer from support burnout, they're likely to set arbitrary rules for participation; these might include prohibiting the use of certain phrases in channel, or disallowing the use of private messages to contact channel members. Staff might promulgate a lengthy, multi-page rules document ending with a special procedure the user must employ to be voiced in the channel (to make sure they've read the entire document before asking any questions).
  
  Such arbitrary rule sets tend to grow longer over time, because they don't solve the real problem. You can't answer every question, and you shouldn't try. Be gentle, be courteous, be flexible and be as patient and helpful as you can---but let someone else try to answer questions that you find too frustrating. Don't try to be a superhuman support machine.
• If you're considering publishing channel logs, think it through. The freenode network is an interactive environment. Even on public channels, most users don't weigh their comments with the idea that they'll be enshrined in perpetuity. For that reason, few participants publish logs.
  
  If you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging, and get permission from the channel owners before you start. If you're thinking of "anonymizing" your logs (removing information that identifies the specific users), be aware that it's difficult to do it well—replies and general context often provide identifying information which is hard to filter.
  
  If you just want to publish a single conversation, be careful to get permission from each participant. Provide as much context as you can. Avoid the temptation to publish or distribute logs without permission in order to portray someone in a bad light. The reputation you save will most likely be your own.

Copyright © 2002-2009 by Peer-Directed Projects Center.
Network date and time: Sunday, 10-Jan-2010 17:36:33 GMT.
Comments to email address: web at freenode dot net.

freenode philosophy: channel guidelines

Irc - Audacity Wiki

Audacity Wiki Home Page - Audacity Wiki

Audacity: Free Audio Editor and Recorder

Glad you asked.

First, who in the world doesn't strive to be conscious, with the exception of heroin addicts, suicidals, and that sort? Being conscious is one of the main reasons we get out of bed in the morning.

I'm not intending here to be argumentative or contrarian. I've been here for awhile; I've seen the term explained in the WaccoBB context a few times, and I still react to the term as being self-aggrandizing, elitist, and inherently insulting to anyone who doesn't consider themselves to be "conscious". If one isn't what you consider to be conscious, the implication is that they are "un" conscious - they are existing without conscious thought, or perhaps "sub" conscious - less-than-conscious, incapable of functioning consciously.

Anyone, especially online, has the freedom to call themselves whatever they want - "conscious", "enlightened", "righteous", "super-duper", "godlike", whatever. Just be aware that the process of doing so is going to come off as insulting to many who don't use that preferred terminology.

Perhaps, since you seem to want to build a community of a particular type of perspective, and might want to foster your perspective, whenever you use the word "conscious" or "conscious community" you might consider making the word a link to your definition of "conscious". It might be less potentially offensive to the non-initiate; it might dispel any non-conscious, un-conscious, sub-conscious visitor's possible tendency to be insulted by what they might see as another example of, albeit gentle and well-intentioned, liberal elitist arrogance.