First wave of changes

[bratpeki]

This first set of changes aims to finish all the "TODO" statements made in the manual, as well as make minor adjustments along the way. Once all the changes have been made, this PR is to be squashed and merged accordingly.

I ask the maintainers to not merge this until ready.

[fundamental]

I'm not proposing a change, but for elsewhere in the docs be aware that this is an overloaded term and may be used to talk about a whole scale in the microtonal sections of the app.

[fundamental]

That's the primary usage, but same as the last comment be aware that this gets overloaded to include a smaller contributing element within the add synth engine.

[bratpeki]

Could you elaborate on this? What changes would you propose?

[fundamental]

For definitions that have multiple usages I'd mention the options in the definition. e.g. voice in most synths is typically an instance of something producing a sound, but in zyn it also refers to a piece of add synth where each voice in an add synth instance features one oscillator and one modulating oscillator.

[fundamental]

I'm guessing that commenting these out is part of the WIP nature of this PR?

[bratpeki]

Yes, as I finish each part up, I uncomment the next one. Makes the PDF and TOC more managable, since the WIP content is always at the bottom and not somewhere in the middle of the doc.

[fundamental]

I think one of the plans with the automated screen capture wasn't recoloring, but making it semi-easy to draw bounding boxes around areas you wanted to highlight to users. I do not recall the status of that functionality however.

[bratpeki]

Understandable, thank you for letting me know! I won't force such a functionality, then.

[fundamental]

although the UI does use shoutcase (mostly for typographic reasons), I'm not 100% sure if it's the best for the manual.

[bratpeki]

Alright, I'll switch it back!

[fundamental]

I'd say this is something that should be discussed in another tutorial

[fundamental]

I actually am a bit worried about this documentation style. It's something that I've done in the past and sort of burnt out of documentation work. Enumerating everything in front of the user tends to make hard to read documentation and with something at the scale of zynaddsubfx it makes it an impossible task for you as the documentor. I'd drop some of these elements if you don't have something to tell the user about in a narrative sense.

[fundamental]

This is actually a typo in the original text, but since your diff touches this line "it's" -> "its"

[fundamental]

heh, I would have thought middle mouse would have worked here as well, but maybe that logic is missing.

[bratpeki]

If we implement precise input fields, middle mouse is out of the question.

[fundamental]

Ah, fair enough. There's only so many buttons at the end of the day.

[fundamental]

The main config is in ~/.zynaddsubfxXML.cfg if that's what you're asking about (yes, it's not in an XDG path)

[bratpeki]

I'm talking about the window you open with the top-left Zyn button, but that's great info, thank you!

[fundamental]

I wouldn't mention that view too much as the view that's accessible by clicking the logo is mostly stubs instead of a fully implemented part of the UI.

[bratpeki]

Thank you, I'll wait for your response on the question I've left, and then I'll correct everything!

[bratpeki]

There is a commented-out segment in the effects relating to the effect routing dropdown menu, this should be checked at some point.

[bratpeki]

Major changes to the file and TOC structure OTW.

[bratpeki]

Slowly starting work on this again, it's gonna move at a snail's pace until my Linux machine is up and running, but I'll try to lay the foundation for speedy work in the future!