Someone else.I never had access to one to get locked up. Point taken about the freq/amp convention for controls, I thought ARP also did this. I think I have seen it on some panel before in a photo, when all I had was library books to learn from. I can't remember whose it was though. What ARP definitely did share with you was this neutral position thing.
It's a good idea. Especially in Phase Modulation synth coding. PM or FM synths have a minimum parameter count of maybe 150 controls, easily rising to over 2000 in the case of Yamaha's FS1R or any multitimbral synth based on even simple FM. Fortunately digital storage as 'Init Voice' was Yamaha's way of easily resetting to defaults. I first came across the idea in a library book! And the ARP2600 was the synth specifically used to illustrate it. This is an excellent starting point in any system like this, because the question of why a position is considered neutral always arises, and the answer for each case is usually simple, and quickly guides a person in use of the control in other positions. What's more, main signal flow becomes apparent the moment you look at the few controls whose 'neutral' or 'zero' positions are in any state that is not either off or minimum.
In short, I think you raised what might be the most important way to start. I remember that this neutral or zero position thing was my fastest way to learn a synth when I finally got one, without getting lost or breaking something. (Speakers and amps, like scan mirrors, CAN be broken by the early synths, which often run 'hot' (SCI Pro One for example, has a raw 15V on its output!))
One thing I can add: When coding my own PM synth I found that the best way to write what will eventually become its manual is to write my notes as I discover or create stuff. If I wait till it's old hat, it will be unreadable nonsense more likely than not, to anyone new to it! One antidote to this risk is to write from memory in direct answer to a question (as Ash did just now), but the best of all is to take notes when it's actually new to US, whoever we are, whatever our level of experience is. That's the best shot at them making sense to another newcomer, AND the best shot that they'll make sense to the writer who looks at their own work months or years later. I did badly at school many years ago because I learned too late how important it is to take good notes at the time! The reason I can code a complex instrument now, is that I learned to correct this error. When exploring, DRAW YOUR OWN MAPS.It's usually the best way, because after all, who else is with you? If you're exploring, chances are you're in limited company, or alone. Later on, a manual can be more easily written, but by that time you won't be a writer, so much as an editor... At this point, hindsight is very useful. There may be other methods, but the way I see it, this one is the one that will save me from having to field the most questions if I ever get my work into a publishable state.
One other thing I can add, from an artistic point rather than technical: Use of SLOW speeds... With my only laser show ever done for an audience, all I had was two sinewaves, each variable in frequency and amplitude, four knobs in all. And I could have any colour I wanted so long as it was argon blue. At fixed intensity. 20mW. This is so minimal that if you took one knob away all you'd have left was a 'liquid sky' effect at most! it quickly became apparent that at one extreme the beam could be waved slowly like waving a hand in the air, or at the other extreme, a frazzling aray of fast Lissajous stuff with non-integer relations for crazy 'randomlike' effect. The only remaining question was: how inventive could I get between these extremes while at least attempting to fit with what the DJ was playing? Fortunately the answer was: enough to get people off their bar stools and make them dance, AND make the DJ start paying attention as well. Good enough for me... One important aspect of SLOW motions is that with fast scanners you can cut between lots of them, giving the illusion of many slow things happening at once. To get the best of this principle some degree of clever multiplexing will be needed, and likely plenty of 'travelling salesman' optimisations, so this may end up being something LSX might do, rather than being done by any analog console. I mention it though, because I think it might allow some new forms of display that I haven't seen in any videos yet.