check out my video :
at 2min, I build first patch in about 60 seconds … the over next 5 mins or so extend it.
imho, a written doc would be a pretty poor way to describe how to use a visual patching system.
not only would it take alot of effort, but you wouldn’t be able to hear what was going on 
the ‘problem’ with tutorials for the percussa, is what users want to know varies tremedously, and thier previous experience (and so what needs explaining) varies alot too - thats kind of why MATTHS videos are so long, since he needs to explain many things to ensure they are ‘self contained’
as others said…the approach id suggest is quite simple…
- learn the basic patching workflow.
(select module, opening inputs, connecting other modules to those inputs)
- look at the modules that interest you ‘most’
- look at a few of the simpler demo patches to give you an idea, of what to do.
- start building patches from scratch … then rince repeat.
I think the only ‘tricky’ bit is polyphonic midi…
(shown in MATTHS video?, and is down in demo patches)
polyphonic midi is a bit ‘special’ ,the midi object only has one pitch/gate output…
so how can you do multiple voices (i.e. polyphony) ?
the answer is simple (but not obivous!) , you have to use multiple MIDI objects, each MIDI represents a single ‘voice’, and hidden/behind the scenes (the confusing bit) the SSP distributes notes across those objects…
lol - almost a perfect example of how the written word, makes it more complicated than it actually is in practice… simply create multiple MIDI object, connect to OSC, and you will SEE/HEAR how it works 
anyway, like any skill/learning something a little complex - there is no shortcut, you just have to do it…
the more you do, the more obvious it will become.
I think the concepts of the SSP and workflow are pretty straightforward - once you have created one patch, you pretty much know all you need to know!
hence my first patch example
this is why I recommend you write a patch from scratch rather than try to understand a demo patch - its easier to write a patch than understand someone elses!
I think from there, its just about learning how individual modules work, and what they do… which you do by trying one module at a time, seeing how it works… and the incorporating into your own patches.