From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Note: This is my opinion on how to organize OSMs. You can do it however you want. But if you want me & perhaps other to read your OSM to help you out, then you need to make your OSM not a headache to read. There are some OMS that are a pleasure to read, such as the OSMs from trogluddite, Andrew J, etc. If it is organized well, the I can basically understand the OSM in in 5-15 seconds. Modules & connectors are named understandably, I know where the data & signal paths are going, & if I want to look for a particular sub-function, I can find it in a few seconds.
I have opened some OSMs that are a headache to try to read. If I have to spend a minute to understand basically what is going on, that is too long & I give up. Unless I'm getting paid to read those, or they have some amazing function, I usually close that OSM out & never reopen it again. Please keep in mind that no one else can read your mind, so they need to read your OSM.
Here are some common issues for me:
-too many modules & primitives all over the place
-nothing or poor labeling
-bad grouping of related primitives
(eg a Float number far away from the math it connects to)
-too many fancy curved links & can not follow the links
(I usually do not have the same curve preference set in SM)
-too many wireless links, so I do not know where they go
-knobs too removed from what they feed
(some try to separate logic from GUI, takes talent to do it well, & you need to keep all knobs at default range [0..1]. But usually I like the knobs inside or next to the modules they feed, so I can check ranges & test reactions)
-too many sub-modules/too deep
(SM's knobs are perfect bad examples; they are 7 modules deep, when you need only 3 deep max. So if you want to change or test the logic, you have to drill down dozens of times.)
-too simple of a module
(if all it does is "1-x=" does not need to be in a separate module)
I will show how I organize an OSM to make it more readable & do some reduction on the way next.
infuzion ·
Note: I make italic names of primitives & often modules.
Here is an OSM that I find too hard to read. So many wireless connections everywhere... not sure what feeds what.
I know that the original author does not like too many links, but there are the same number of connections, with out knowing where they go. I can click through & try to mind-read the author, but that will take more than 15 seconds. I am truly interested in this OSM; it works great & I may want to modify it later.
So after I ask him to replace most of the wireless links we get this:
OK, I can see the flow now!
It does look like too many blocks swimming in spaghetti, he did a great job in making the OSM organized already, so let us see how we can group up some areas to make sub-modules:
I think those groups will make great modules. I will work on the bottom left next post.
infuzion ·
These look like they should go together; let's make a module!
Wow, many links running outside.
So we go inside to see what Outs are duplicates:
There are a few duplicate-Outs, so I group them inside to help me to reconnect them outside.
infuzion ·
In the pic above, we see a few pairs of Outs for the same value(s). Only need 1 output per value, so we need to go outside of the module (Move to Parent/Page Up), and re-link some of the duplicate Outs so we only use one. Sometimes you have to worry about link order (see red circle, sometimes not):
How it looks afterwards inside the module is below, but before we get to that, time for a quiz! Can you guess what connector I had to add since I made it hide inside a module?...
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
it is a link!..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Gave up your guess?
So, next let us investigate the module with the Text Size input:
infuzion ·
Inside:
Just a few primitives, should be reduced. Inside the Typeface module:
Ewww Typeface Selector! I hate those; they lag due to reading your /Windows/Fonts directory, & you really should just make a single Text Font line. There are only 20 or so Windows fonts you can rely on being installed. Sometimes I use the Font primitive as well, & we have to here since the text size is dynamic. Here is what we have so far inside the "type size" module after some reduction:
infuzion ·
Now we will copy all inside the text sizer module, & paste into the parent module. I like to include all the Ins & Outs, to help figure out connections & link order:
I skip a small step here; I moved the 2nd module that was fed by the Area To Float Out next to it, since it was only a Float Multiply. Reconnect the Ins & Outs, delete the modules we reduced from, & we get this:
What do I notice? All these 2 modules did was to find a single float value, that needed to be hand-tweaked anyway! None of them are needed due to the hand-editing ("if you change this you will need to change the Text Size"). This is why I find module reduction important; helps you find errors & shortcuts like this. So let us find the end-value, and store it in a Float. We need to copy/paste the title/comment so we know what to do later:
infuzion ·
Copy then Pasting the Float that contains the result of all that math, then deleting the parts to get that math (since it only runs once) we get:
7 fewer primitives (actually more than that before reduction)!
I pull up on of the other modules, & notice I do not need that MAGIC NUM Wireless Link anymore if I directly wire that Float. I also notice an old Int S&H On Change I created years ago.
Well, Malc created an updated version of it with a Trigger Blocker, so we'll replace that.
infuzion ·
A little more re-arranging & we get this:
So we are done with this module. Let's look outside:
Ewww, what is that mess to the right? We can drag-select all that easy to make that a module as well:
infuzion ·
After some minor reduction and re-arranging of the links inside, we get a nice, orderly OSM:
That is all for now! Some of the discussion below was written as the tutorial was in progress.
Enjoy!
infuzion ·
infuzion wrote: dang, only 3 attachments per msg
infuzion ·
infuzion wrote: dang, only 3 attachments per msg
MyCo ·
infuzion wrote: -too simple of a module
(if all it does is "1-x=" does not need to be in a separate module)
I can't confirm this. If I use something simple a couple of times, I make it as module... 1-x is a good example.
But the simplest thing I make as module is a "dummy". That's nothing else than a input connected to an output. I use this very often when I have several connections into a single input connector. So I can overlay the connections (straight lines) and go in a different direction from there with a single connection:
stw ·
MyCo wrote: But the simplest thing I make as module is a "dummy".
But i can confirm this... 😀
mwvdlee's grouping modules from the missing link kit come in very handy here...
infuzion ·
MyCo wrote:
infuzion wrote: -too simple of a module
(if all it does is "1-x=" does not need to be in a separate module)
I can't confirm this. If I use something simple a couple of times, I make it as module... 1-x is a good example.
But the simplest thing I make as module is a "dummy". That's nothing else than a input connected to an output. I use this very often when I have several connections into a single input connector. So I can overlay the connections (straight lines) and go in a different direction from there with a single connection:
Well the problem with modules is that you cannot confirm what it contains unless you actually look inside or the output, both of which take time. & I have seen modules labeled "1-x" or "dummy" & they contain much more. For simple things I have a few OSMs that I copy/paste from, & I'm sure one can automate such things also...
I use dummies for converting to trigger or collecting many to 1 or sometimes, but to just make nice-looking routing, I find rearranging the primitives/modules just as good usually.
trogluddite ·
Fanstastic work, infuzion
stw wrote: mwvdlee's grouping modules from the missing link kit come in very handy here...
Yes, the custom 'skins' get around the problem infuzion mentioned earlier about having to peek inside stuff - you can just treat them as primitives because that's what they look like.
I find that groups are best used 'pre-emptively' - if you have many inputs into one primitive, stick a group in there anyway; saves a lot of effort later on if you suddenly discover that you need something 'extra' in there to process the shared input.
If you haven't stuck one in beforehand, then infuzions method of just creating a module works just as quickly.
Would be nice to have a modifier key to drag ALL the links from one input to another at once instead of doing them one by one, though.
lesobrod ·
Cool tutorial for a newbie (and not only!). (^_^)
How about wireless links inside module?
If module a big one, this could be a good thing!
infuzion ·
MyCo wrote: So I can overlay the connections (straight lines) and go in a different direction from there with a single connection:
Oops I missed this picture (in quoted post). Ok before:
It is great that is very well organized; makes it easy to see what to do to reduce.
Simply align everything that feeds the trigger & you can very easily eliminate the dummy module. I put the trigger-out on top to act like a column header. It also opens my eyes to minor reduction:
lesobrod wrote: Cool tutorial for a newbie (and not only!). (^_^)
How about wireless links inside module?
If module a big one, this could be a good thing!
Thanks!
I try to avoid wireless, unless it is a one-to-many relationship that for common preferences (eg have 10 knobs that all use the same information). Too many wireless links for data makes an OSM hard to read IMHO. I have used wireless in very complex modules, like the Multi-Stage Envelope. Even then I had to wired links to ensure activation order. Using Buss primitives can sometimes help use fewer connectors between complex modules. That is another tutorial.
--
I lengthened the tutorial, but still have more to go. I have to prep my laptop for Komplete, so I may be gone for a while...
trogluddite ·
infuzion wrote: Using Buss primitives can sometimes help use fewer connectors between complex modules
My psychic powers must have been good when I wrote this one...
Decluttering with Busses (Wiki)
infuzion wrote: Even then I had to wired links to ensure activation order.
Yes, this is one of the biggest shortcomings of wireless connections/ It has given me BIG problems in a few schematics before.
With normal connections it is easy to use the little 'ticks' on the links to adjust the trigger order to get things flowing right. There is no equivalent to this for wireless links - the order is determined entirely by the order that you created the wireless xonnectors, and there's no way to see what that was later on.
Cutting, pasting and moving modules into and out of the toolbox (or posting them on the forum for download) can mess the trigger order up even further.
To fix any wireless trigger order problems, the only way is to find and delete them all, and then laboriously remake every single one, - and get the order spot on this time. This is NOT easy - especially if you're not sure where to find them all.
So, the rule is, never use wireless if the trigger order matters!
DigitalWhiteByte ·
trogluddite wrote: So, the rule is, never use wireless if the trigger order matters!
Indeed,
I tend now to use them only for the assignment of constant values,
such as graphics or user setting for modules, but I try not to use them for data intensive.
indeed I tend now to use them only for the assignment of constant values, such as graphics or user setiing for modules, but I try not to use them for data intensive.
The result is a more spaghettoso, but I eliminate the randomness of the order of the various wireless
especially on complex graphics that I found on the redraw problems.
Or use the technique to have the value of wireless for zero or empty string, so you can adjust the phase of light trig to form only when the value is not different from zero or an empty string, but this course entails an extra working for the trig.
In short, it is now a long time since we ran into serious workarounds that we do not spend more in the work and nothing else.
sorry if sometimes they are OT. 😕
infuzion ·
Tutorial finished for now! Have fun 😇
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker