MSoundFactory 60% Off

[sarine]

On 3/27/2022 at 8:44 PM, User 905133 said:

For example, some manuals (and online documentation) simply state what the different buttons, knobs, sections, etc. do.

Those would be reference manuals, which are extremely handy when you want to look up what's what - and nothing more. Also called cheat sheets in other contexts, and similar to spec sheets (data sheets) which only specify technical characteristics - e.g. physical dimensions of a PC case or the pin layout and electrical characteristics of an integrated circuit - in that their purpose is to relay the most relevant information that would concern a user who already knows how to apply it, in a condensed form for the referrer's benefit, and any excess would be to its detriment.

As useful as they are, of course they're not a substitute for a user manual which is supposed to explain how to operate an appliance from a typical user's perspective in a way that is congruent with the skills and knowledge that can reasonably be expected of them.

So the actual question is: What is a reasonable expectation regarding average user's skills and knowledge?

In reverse: What is the knowledge domain that the user can reasonably expect the documentation to cover?

If I buy an oscilloscope, I don't expect the instructions to lecture me about electricity. Similarly, I don't think a user manual for a synthesizer is the proper place to teach the fundamentals of sound synthesis. They're not obliged to explain to the user what modulation or phase mean. Even if the documentation is written concisely and at "the reasonable" level of detail, some of that logic is inevitably going to be documented (implicitly at the very least) in descriptions of how everything is put together or usage examples.

That's not to say that a plugin vendor wouldn't benefit from producing teaching material in broader scope, but I wouldn't want it to clutter the operating manual.

 

On 3/27/2022 at 8:44 PM, User 905133 said:

I believe that creators of documentation and manuals really ought to take into account multiple learning styles.

This seems like an unreasonable request. How many fundamentally so different yet statistically significant learning styles can there be that producing a clear and thorough user guide necessitates attuning to the multitude of them, instead of just adhering to what are considered good practices and standard form and structure. It's (mostly) fairly mechanical machinery and deterministic processes that we're talking about, so I'd think there really does exist a single best way to document how it functions.

Now to translate the documented behavior of the system into effective prose that successfully communicates the experience of using it is a bit more open-ended problem, but I think the possible differences in workflows between different users, or the same user trying to achieve different things, would deserve more attention than individual learning styles. They're also more clearly defined and thus more manageable, because we can say some use cases are definitively unsane, and be dismissive of them. I bet that applies to some "learning styles" too and that sometimes the problem is not how the documentation is written, but how wrong the expectations were; the writer reasonably or unreasonably expected too much from the user, and vice versa. Bad documentation can also follow from (or in spite of) reasonable expectations, and good documentation from unreasonable (pessimistic) expectations.

 

On 3/28/2022 at 5:02 AM, Starship Krupa said:

I don't know how it is now, but 40-50 years ago, it seemed like one of the biggest insults you could give to a teacher was "how is this going to help me in the real world?" And sure, most of the kids who asked it were being confrontational, but to me, that's an opportunity to give a student motivation.

No, the biggest insult is: "You're wrong / your book is wrong." - followed closely by any of its less direct and/or friendlier variations, including accidentally enabling them to read in between lines that you don't recognize them as God and the classroom as their dominion.

When students/pupils question the utility of what they're being taught it's probably due to innocent frustration, but to avoid a patronizing answer it's best viewed as sublimation of rebellion spirit (domesticated anarchism). It allows the teacher to respect the challenger and their chosen rules of contest and to respond effectively and with the appropriate attitude (even easier to respect these days when waving a knife is increasingly considered to be a socially acceptable way of challenging the teacher). It's an opportunity for the teacher to justify the institution, their position in it, and the studies. Like you said it's also an opportunity to motivate the students, but one should be wary of inadvertently alienating them further. Even in responding to that one person you're really talking to the whole group, and it's really difficult to motivate someone without addressing them individually. I don't think knowledge and rhetoric have that power, and instead you need charisma and strong transference. Same goes for projecting authority. I think you're "born" with these traits and that they cannot be learned (although, practically speaking, effective imitation is learnable).

I've worked with pupils/students, done private teaching/tutoring/directing as well as for small groups, and I love when kids test, challenge and try to outsmart me. I especially love it when they're smart and push me to push myself, because when I win they get it, they earn my respect, I earn their respect, and I know that they know all of this. Smart kids who are upfront and confrontational are great to be around if you want to stay awake and alert, and I make sure to reward them for trying to best me (after kicking their *****). You also occasionally hear quite acute observations from them and they will quickly pick up on pretense and posing, so your only option is to be real, and when you've established with them that this applies in both directions, it simplifies the game of social interaction tremendously and frees those mental resources (yours and theirs) to be used for things that aren't trivial BS. Don't take yourself too seriously, don't expect anyone to respect you until you demonstrate why they should, and once you have; don't think that you've established yourself some immutable status, but be ready to prove yourself repeatedly and without warning. Be prepared to be humbled from time to time, should you forget your stature in this world. Your long-term reward will not be some arbitrary status, but the kind of solid mutual trust and respect that can only form under great pressure.

[Starship Krupa]

3 minutes ago, sarine said:

So the actual question is: What is a reasonable expectation regarding average user's skills and knowledge?

In reverse: What is the knowledge domain that the user can reasonably expect the documentation to cover?

These are questions where Meldaproduction's documentation and I differ.

The documentation for their products tends to overestimate an "average user's skills and knowledge."

What I expect from good documentation is that all features of the product will be described, and if any of them are extraordinary for products of the type then the use of those features will be described in greater depth. This includes if the features are standard, but accessed in unusual ways or use non-standard nomenclature.

Meldaproduction's website copy goes on about how everything they make is so much more advanced than comparable products from other manufacturers, and/or how a given product is unique, and for the most part, I don't disagree. It's all good, I just wanna know better how to access all that power. ? If it's unique, that means there's nothing else like it, so how can I have prior knowledge?

Another thing that makes their documentation less useful is the amount of coverage given to features that are common to all of the products, like the preset manager. Click the "?" button on any of their FX and at least half of the text that comes up will be about the preset manager. If I'm confused enough to click a help button, it's probably not going to be cleared up with an explanation of how to load and store presets.

Here's an example,  MLimiterX:

"A brickwall limiter increases loudness by reducing the ratio between the average and peaks in the signal, however the dynamics of the audio material is always sacrificed. MLimiter is simple to use. Watch the gain reduction meter ("R") to the right, and manipulate the Threshold. Decreasing the threshold increases the output gain and allows limiting up to 0dB. Care is needed as this can cause severe distortions if not used correctly. In most cases you don't need to worry about the edit screen, just simply focus on the easy screen, with its simplified 4-knob interface."

That's all it says about the product itself. Then follows 18 pages of boilerplate about the stuff common to all of their products. Couldn't find anything about Ceiling, which is there on all of the easy screens. Seems to me that for a limiter, at least one sentence on that is warranted.

There are exceptions, I'm a fan of bizarre FX whose features might not even be describable verbally. I have licenses for the entire Freakshow catalog, 11 of Glitchmachines' plug-ins, and a dozen Unfiltered Audio plug-ins. So not even don't I mind twiddling knobs and seeing what happens, I love doing it. But that's when I'm in the frame of mind of sound design, which is different from mastering or trying to get the kick and bass to play nice with each other.