Here's the first patch I've put together myself. It plays a random root note, which then gets combined with random harmonics, at a random tempo. Pretty basic, but it's fun.

There's a couple things I'd like to do with it, though:

1. How can I turn off the output from the random number generators so that I can manually control the variables via the number boxes? Right now, I can turn the randomness off, but then it just outputs zeros on the metronome beat. Which is boring.

2. Is there a way to control the attack and decay for each of the notes? Right now, I'm doing it with message boxes into vline~, but I'd like to be able to modify that stuff on the fly.

3. I know I could nice it up a little bit with subpatches and stuff, but I haven't quite figured those out yet. Any suggestions on the best way to learn how they work?

Thanks!

http://www.pdpatchrepo.info/hurleur/additive_random_synth_time_variable.pd

First of all, thank you for commenting your patch and making it clear what it is doing and what you want to change. It makes it so much easier to help when you do that. And so, I made some mods to your patch that should hopefully answer your questions.

http://www.pdpatchrepo.info/hurleur/additive_random_synth_time_variable.mmb-mods.pd

Thanks for the help!

Once I have a chance, I'm going to take a more thorough look to see how the subpatches work. I think they're what I'm looking for, though.

As far as the comments go, it seems like it's just good practice. I made this patch a few months ago, and when I came back to it (and was trying to explain it to a friend) I had forgotten what everything did. I figured if I wrote it down, at least it would make sense to me.

@Monona said:

As far as the comments go, it seems like it's just good practice. I made this patch a few months ago, and when I came back to it (and was trying to explain it to a friend) I had forgotten what everything did. I figured if I wrote it down, at least it would make sense to me.

Exactly. I think a lot of newbies don't realize this at first. I know I didn't. It really saves a lot of headache in the long run. I wish a lot of the abstractions included with Pd-extended were commented. It would greatly increase the educational value of them so they would be more than just utilitarian.

Comments are often a smell which indicate that some form of refactoring is in place... Extract method can be a good cure in this case: grouping code that belongs together in its own subpatch with a well chosen name. E.g. if you have some objects that perform millisecond -> bpm conversion, instead of adding a comment that says "millisecond to bpm conversion" just create a subpatch called something like ms2bpm. This will in the end lead to more modular code. Something that also helps is giving inlets and outlets a good name.

@domien said:

Comments are often a smell which indicate that some form of refactoring is in place...

I don't understand what you mean by this. What is refactoring?

I agree that grouping code in subpatches is important from an organizational standpoint, and that it makes patches more modular. And naming inlets and outlets is definitely overlooked to often. However, sometimes naming the subpatch after what it does isn't enough, because it doesn't explain how it's accomplishing its task. This can make reverse engineering an old patch or someone else's patch unnecessarily time consuming and laborious. This is especially the case when posting patches to a forum for help in debugging. A few comments explaining what the person is trying to do and where he/she thinks the problem is can expedite a solution.

@Maelstorm said:

What is refactoring?

Refactoring is an object oriented (oo) practice which optimizes the internal structure of code without changing its external behaviour. In the oo world, refactoring is something that is usually done when automated tests are in place - so you can quickly validate that you haven't broken anything in the codebase. I've been practicing this for more than 5 years now in my professional life and found out that it leads indeed to much cleaner code (especially when you combine it with test driven development (tdd) where you start coding by writing unit tests before writing any production code). If you want to learn more about this www.refactoring.com is a good place to start.

Many refactorings are only applicable in real oo code and not in pd but some are :

• "extract method" (putting bits of logical code in a new method/subpatch)
• "rename xxx" (give a clear name to your variables/inlets/outlets/subpatches...) will sure help others when reading your code, and also yourself when reading your code six months after you've written it.
• comments in code often indicate that the code is not expressing itself in the most optimal way.

The comparison is for sure not entirely valid, but you could draw a comparison between (oo) classes/subclasses and (pd) patches/subpatches. If you do so, the following refactoring also makes sense:

• classes/patches with too much code: try to adhere to the SingleResponsibility principle => a (sub)patch/abstraction should (optimally) only be responsible for 1 thing. E.g. a subpatch that opens a audiofile and reads it into a table should restrict itself to that and not also do some calculation that is needed elsewhere in the complete patch. It's then better to output the samplesize and do the necessary manipulations outside.

Ah, I see what your driving at now. That makes sense.