Modules having different functions depending on patching is also true for eurorack. I started thinking about my current patch and the Sampling Modulator is clock, s&h and a trigger sequencer. I would draw three different blocks (and outline them with a dashed line if I wanted to underline All of the functionality coming from a single module).
I am not sure if i can follow…
If i would read your block diagram, do i need to know that clock, s&h, trigger sequencer are coming from the same module? Or do i need to know what is the nature of there connection (synced or free ?)
Let’s say MI Stages can be an s&h, trigger converter, LFO, AD, AR, Delay, Slew, etc…but for the block diagram it’s not relevant to know it came from Stages, right?
I agree. A block diagram is a simplified abstraction of the elements that are actually in use. You might mention the module’s name for memory’s sake, but there’s no need to make a laundry list of a module’s capabilities if you aren’t actually making use of them.
It’s not necessary to know that and that’s why I would draw the functions separately (even that the clock clocks the trigger sequencer which clocks the s&h even though there are no patch cables).
Depending on why I’m making the patch notes it might be relevant that all of the functions come from the same module. If I was making the notes for myself for later reference I would include that. Not maybe for sharing the patch.
The extra information doesn’t hurt though.
My point was not to make a laundry list of the module’s capabilities. All of the mentioned functions are used in my patch although my wording was not clear on that.
Omnigiraffe is Mac/iOS only.
How about draw.io? I’ve used it to describe patches before…
A few designers here at work have been using whimsical.co for dead simple UX flow charts. Pretty nice UI if you need to whip up something quick right in a browser.
This isn’t a software tool, but the Patch and Tweak book proposes, based on a number of forerunners, a common set of diagrams for modular functions. I’ve taken to using it to draw mine out.
So a library of these in something like Omnigraffle (or the one we are encouraged to use at work these days is Lucidchart) could be a solution.
what i hate most about technical writing is that you have to hide the whole spun-out process of discovering something and just present the final thing in linear form from premises to conclusions. that kind of hiding puts distance between yourself and the reader. worse, it can lead to a dangerously false sense of ego.
but if you present all your intermediate stages, all of the wrong turns and dead ends, people tend to learn a lot more from it, which was hopefully the point. that’s generally not possible except in person, but you learn acceptable ways of hinting at that stuff within the linear structure. and it recovers some humility.
same with patching, the process is: first, start with this very simple thing, then really listen to it, get inside the sound, tune everything properly, then add the next thing. that maybe doesn’t sound right, but then make a few adjustments, or try this other idea.
this is why I unpatch all the time, even to patch again the same thing – because the final sound is only “right” if i’ve retraced all the intermediate steps of listening to the results. sometimes i get a different inspiration and take a different path. but there’s also the value of repeating the same thing as a meditative practice… because it is never the same thing, something always changes even if it’s only yourself. in repeating the same patch there’s always something discovered, something revealed anew.
so i always thought presenting patches as a series of smaller patches building up to the final one (or tearing down as it may be) is important… as well as having space for text to describe intermediate listening/tuning stages. i almost never document anything but when i do i follow this style.
then again, you want to give the reader space to discover things on their own… so maybe less information is better. i’m just recalling what works in terms of notes to myself.
the “space for text” is perhaps the important thing here. I end up doing it as a latex document with omnigraffle diagrams.
That’s great, thanks for that!
my browser is too old for that… but looks good.
haven’t got a copy yet…is there a library with function diagrams?
I wonder how complex it gets with “modern” modules like Cold Mac to translate its functions to a simple block diagram. I started 20 years ago with Doepfer where the complexity of a system evolves by patching simple building block.
Cold Mac is really a bunch of simple analog circuits, cleverly arranged and normalled. It shouldn’t be too hard to diagram its usage (or the whole module) in a way that could be reproduced without it (probably less elegantly).
I agree with draw.io! It works great and integrates well into the google platform if you are part of that ecosystem.