“Tip: This is what a feedback loop looks like.”
2 Likes
The A4 MK2 manual explains the LFOs on page 88. The right column has a mistake when discussing the first DST parameter; it says “DST (LFO1 Destination A)” where it wants to be “DST (LFO2 Destination A)”.
And just to be sure: are the two LFOs identical? If so, a better, more high level solution might be to have ONE explanation, with an introductory sentence saying that it applies to both LFOs.
Seeing the two columns immediately made me think that there must be some sort of difference between the two, which I couldn’t find. It seems redundant and misleading.
Hope I didn’t misunderstanding anything 
the green INPUT box says INTPUT too
Thanks for bringing this up and I totally undertstand your reasoning. I will put this on my “have a deeper look into this” pile. Meaning dont expect this to make it in to the manual in the near future unfortunately, since there is a lot on my desk at the moment. But you are right and in a bigger sense this is a “problem” in other places in our documentation that it is not user-centric enough,
2 Likes
A suggestion : maybe you could open source the documentation and make it possible for users to participate with merge requests?
Or start a new kind of “quick answer”/“workflow” documentation with examples? Maybe also with some users participation…
As helpful and welcoming this place can be, managing to centralize and homogenize the user knowledge would be a strong asset, IMO.
1 Like
As someone who does technical writing as part of their job, and who appreciates the quality of Elektron documentation (even as I feel there should be more redundancy for the benefit of newcomers), I disagree with this suggestion. I think a single author taking corrections and suggestions is important to maintain consistency of style and structure. @eangman is clearly listening, thinking, and reacting quickly where possible. I find it hard enough to write a technical paper with a few co-authors (I had eleven once, for something done at a workshop, that was a nightmare). If someone wants to mock up some possible paragraphs, that might help (or it might not).
6 Likes
A sub-optimal link there indeed 
Thanks for letting me know! I will fix that and link to the right place in the manual
2 Likes
Intput schmintput! OK, dont have any good excuse for that one Will fix. Thanks!
3 Likes
seems like you have at least some freetime after weeks and month of writing that Syntakt manual – good to know your done with it 
1 Like
Nice try… 
1 Like
I understand.
But between total unsupervised mess and a single person output, there might be a middle where user input is actually collected and updated.
My suggestion do suggest that there still is supervision (merge request would be accepted or amended).
What I have in mind would be simple workflow examples with
context ⇒ goal ⇒ actions to get there
A structure to accept suggestions would be mandatory to ensure some homogeneity.
And of course a few examples would set the tones/structure.
I’m not saying it would simplify @eangman’s position ^^
3 Likes
Yes, this idea has been floating around like forever, and though I see the benefits of it, I can also see problems with that, both on the technical side (with our currest setup for creating manuals), but also when it comes to letting “other people” outside the company creating what will be official Elektron documentation. However, Im personally all for the open source idea and essentially I agree with you. I will keep this idea in mind when it is time to have a bigger overall look at our total documentation output.
3 Likes
I agree that something like this is possible and would help. I just don’t know about adopting the open-source software model. Software is a very different beast.
1 Like
Open source is not software only ^^
For a “user workflow” documentation to emerge, you would definitely have to find the right tool (or maybe develop one) to make it possible to
- write a suggestion that respects a usable format/structure,
- make the discussion possible, with other people ideally, so that the suggestion gets refined
- accept/reject the suggestion
- enable feedback on an already accepted entry
- put tags/metadata on the entries to enable research
As long as a participation/entry would be supervised by you (or Elektron in general) before being published, I would think it’s not really a problem to have the Elektron stamp on it.
And I would see it as a different kind of documentation, a “user workflow” oriented one. Maybe documentation is not the right word. But well done, it would definitely be an asset to
- aggregate users knowledge
- consolidate such examples
- offer centralized help, and pointers when people ask for help in the forum
- demystify the machines
- show potential customers how helpful the community is ^^
- answer simple questions for beginners
I don’t think such a thing exists nowadays, all the information is scattered in brand forums.
Managing to lead this to some level of realization would be quite innovative, I believe.
Excuse me if I’m just dreaming aloud and hijacking the thread ^^
2 Likes
I think Elektron manuals are excellent, amongst the best I have ever used, I do think that I prefer technical manuals (like they are) rather than “dummies guides”. Elektron user manuals are like theory of operation style manuals, I don’t really like the quickstart manuals personally.
However, I do think the proposed idea is a good one, not as a replacement for the existing manuals but as a supplement to them.
I think @eangman concerns about keeping them in the Elektron style is valid too, often fan created or 3rd party guides don’t hit the mark, it can get too rambling and messy IMHO.
Maybe it would be cool to have “field guides” with various different tips, workflows and how to’s, with user contributed content sent in and properly formatted and edited to be in keeping with the other manuals. (Possibly with links to and from the main manual eventually)
I’d happily contribute some ideas and tips picked up over the years, I can think of quite a few other knowledgable users who probably would too.
4 Likes
Yes … starting with one on how to avoid losing everything on your model:cycles or model:samples by not understanding exactly how and when things get saved.
EDIT: See What and when M:S autosaves, if it does? - #30 by bibenu
One thing I really appreciated when I first got a Polyend Tracker (not that Polyend can hold a candle to the excellence of Elektron manuals) were the linked videos clips in the online manual showing the various features in less than a minute or two. A video series of short clips from Elektron showing each feature would be amazing imo.
4 Likes
As a graphic designer myself, I know where that comes from
V and T often appear in my text boxes on indesign or whatever other design software i might be using
1 Like
There, now I have updated and uploaded a handful of manuals based on your excellent feedback. Thanks again, your input is invaluable!
9 Likes
