Forums > MaxMSP

Question about subpatches (newbie)

December 15, 2006 | 8:56 pm

Hi folks,

I’m pretty much a newbie, so forgive me if this question is really basic! I want a main patch which includes certain subpatches which are then triggered by message boxes (numbered cues). The subpatches are really simple at the moment, just so I can experiment (just basic sinewave generators).

I created a subpatch within my main patch which contains a sel object. I have three messages (1, 2, 3) going into the left inlet, and sel receives these and sends them through its outlets to three bangs. Each bang is connected to a send object, and these connect to further subpatches containing the sine generators. But I’m unable to select these subpatches individually – when I send a message (either 1, 2 or 3 from within the main patch) I always get all three subpatches sounding together! Is there any way (I’m sure there must be) for me to select these subpatches individually using cues like this?

Hope this makes sense, and hope someone can help (I’ve uploaded the file).

Many thanks


December 15, 2006 | 9:09 pm

>
>I’m pretty much a newbie, so forgive me if this question is really
>basic! I want a main patch which includes certain subpatches which
>are then triggered by message boxes (numbered cues). The subpatches
>are really simple at the moment, just so I can experiment (just
>basic FM).
>
>I created a subpatch within my main patch which contains a sel
>object. I have three messages (1, 2, 3) going into the left inlet,
>and sel receives these and sends them through its outlets to three
>bangs. Each bang is connected to a toggle, and each toggle is then
>connected to a subpatch containing the FM synthesis. But I’m unable
>to select these subpatches individually – when I send a message
>(either 1, 2 or 3 from within the main patch) I always get all three
>FM subpatches sounding together! Is there any way (I’m sure there
>must be) for me to select these subpatches individually using cues
>like this?
>
>Hope this makes sense, and hope someone can help.

hi

teh trouble is not with the sel, but with the fact than you use your
bangs (or triggers) to click on the EZDAC object – this one switches
on the audio of all patchers.

I would recommend to use your trigger (0-1) to control the volume of
each sub-patch (going to the right inlet of *~ , preferably with a
line~ to avoid cliks) and then to send the audio of all sub-patches
to ONE ezdac

hope it helps

best

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com


December 15, 2006 | 9:23 pm

Thanks Kasper, I’ll try that. But this is really just a very early test for a piece I’m writing in which patches will be triggered at various points in the score (the patches will be much more complex, involving FM and FFT). So I would just want a cueing system, involving something like I’ve got in this patch. At least I presume this would be way to do it. I’ve also thought about using a midi keyboard to trigger patches. Any suggestions?

With thanks in advance


December 15, 2006 | 9:48 pm

One of the best things I learned from an electronics mentor is "It’s
always (at least) two things."

– ezdac~ on off state is global. You are trying to mute individual
sub-patches with their own copy.

– It’s easy for a check box to get out of sync if you’re banging it.

In this edit of your patch, I pushed the decision of whether to play
a cue down into the cues themselves.

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P message 100 140 14 196617 0;
#P message 80 140 14 196617 0;
#P user ezdac~ 181 184 225 217 0;
#P message 118 103 14 196617 2;
#N vpatcher 555 44 1099 254;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#N vpatcher 333 434 742 776;
#P button 224 113 15 0;
#P window setfont "Sans Serif" 9.;
#P flonum 146 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P hidden message 163 82 37 196617 0.25;
#P hidden newex 163 60 48 196617 loadbang;
#P window linecount 4;
#P comment 157 220 185 196617 Note that the cue ID stuff could be
handled more elegantly with arguments if the cues were saved as
abstractions instead of embedded as patchers.;
#P button 246 113 15 0;
#P window linecount 1;
#P newex 224 92 32 196617 sel 4;
#P newex 224 71 83 196617 receive cueEven;
#P newex 146 145 27 196617 f;
#P message 176 146 17 196617 0.;
#P user ezdac~ 39 247 83 280 0;
#P flonum 163 103 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 49 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 39 194 27 196617 *~;
#P newex 39 75 67 196617 cycle~ 1100;
#P comment 258 93 100 196617 < - this cue ID;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 14 0 2 1;
#P connect 2 0 5 1;
#P connect 15 0 7 0;
#P connect 6 0 14 0;
#P connect 7 0 14 0;
#P hidden connect 12 0 13 0;
#P hidden connect 13 0 4 0;
#P connect 4 0 7 1;
#P connect 10 0 6 0;
#P connect 8 0 9 0;
#P connect 9 0 15 0;
#P connect 9 1 10 0;
#P pop;
#P newobj 390 109 47 196617 patcher cue4;
#N vpatcher 333 434 742 776;
#P button 223 115 15 0;
#P window setfont "Sans Serif" 9.;
#P flonum 146 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P hidden message 163 82 37 196617 0.25;
#P hidden newex 163 60 48 196617 loadbang;
#P window linecount 4;
#P comment 157 220 185 196617 Note that the cue ID stuff could be
handled more elegantly with arguments if the cues were saved as
abstractions instead of embedded as patchers.;
#P button 246 115 15 0;
#P window linecount 1;
#P newex 224 94 32 196617 sel 2;
#P newex 224 73 83 196617 receive cueEven;
#P newex 146 145 27 196617 f;
#P message 176 146 17 196617 0.;
#P user ezdac~ 39 247 83 280 0;
#P flonum 163 103 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 49 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 39 194 27 196617 *~;
#P newex 39 75 61 196617 cycle~ 550;
#P comment 258 95 100 196617 < - this cue ID;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 14 0 2 1;
#P connect 2 0 5 1;
#P connect 15 0 7 0;
#P connect 6 0 14 0;
#P connect 7 0 14 0;
#P hidden connect 12 0 13 0;
#P hidden connect 13 0 4 0;
#P connect 4 0 7 1;
#P connect 10 0 6 0;
#P connect 9 0 15 0;
#P connect 8 0 9 0;
#P connect 9 1 10 0;
#P pop;
#P newobj 324 109 46 196617 patcher cue2;
#N vpatcher 333 434 742 776;
#P button 224 115 15 0;
#P window setfont "Sans Serif" 9.;
#P flonum 146 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P hidden message 163 82 37 196617 0.25;
#P hidden newex 163 60 48 196617 loadbang;
#P window linecount 4;
#P comment 157 220 185 196617 Note that the cue ID stuff could be
handled more elegantly with arguments if the cues were saved as
abstractions instead of embedded as patchers.;
#P button 246 115 15 0;
#P window linecount 1;
#P newex 224 94 32 196617 sel 5;
#P newex 224 73 78 196617 receive cueOdd;
#P newex 146 145 27 196617 f;
#P message 176 146 17 196617 0.;
#P user ezdac~ 39 247 83 280 0;
#P flonum 163 103 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 49 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 39 194 27 196617 *~;
#P newex 39 75 61 196617 cycle~ 880;
#P comment 258 95 100 196617 < - this cue ID;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 14 0 2 1;
#P connect 2 0 5 1;
#P connect 15 0 7 0;
#P connect 6 0 14 0;
#P connect 7 0 14 0;
#P hidden connect 12 0 13 0;
#P hidden connect 13 0 4 0;
#P connect 4 0 7 1;
#P connect 10 0 6 0;
#P connect 8 0 9 0;
#P connect 9 0 15 0;
#P connect 9 1 10 0;
#P pop;
#P newobj 160 109 46 196617 patcher cue5;
#N vpatcher 333 434 742 776;
#P button 224 113 15 0;
#P window setfont "Sans Serif" 9.;
#P flonum 146 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P hidden message 163 82 37 196617 0.25;
#P hidden newex 163 60 48 196617 loadbang;
#P window linecount 4;
#P comment 157 220 185 196617 Note that the cue ID stuff could be
handled more elegantly with arguments if the cues were saved as
abstractions instead of embedded as patchers.;
#P button 246 113 15 0;
#P window linecount 1;
#P newex 224 92 32 196617 sel 3;
#P newex 224 71 78 196617 receive cueOdd;
#P newex 146 145 27 196617 f;
#P message 176 146 17 196617 0.;
#P user ezdac~ 39 247 83 280 0;
#P flonum 163 103 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 49 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 39 194 27 196617 *~;
#P newex 39 75 61 196617 cycle~ 660;
#P comment 258 93 100 196617 < - this cue ID;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 14 0 2 1;
#P connect 2 0 5 1;
#P connect 15 0 7 0;
#P connect 6 0 14 0;
#P connect 7 0 14 0;
#P hidden connect 12 0 13 0;
#P hidden connect 13 0 4 0;
#P connect 4 0 7 1;
#P connect 10 0 6 0;
#P connect 8 0 9 0;
#P connect 9 0 15 0;
#P connect 9 1 10 0;
#P pop;
#P newobj 94 109 46 196617 patcher cue3;
#P window linecount 1;
#P newex 327 60 54 196617 s cueEven;
#P newex 30 59 49 196617 s cueOdd;
#P window linecount 0;
#N vpatcher 333 434 742 776;
#P button 223 118 15 0;
#P window setfont "Sans Serif" 9.;
#P flonum 146 167 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 0;
#P hidden message 163 82 31 196617 0.25;
#P hidden newex 163 60 48 196617 loadbang;
#P window linecount 4;
#P comment 157 220 185 196617 Note that the cue ID stuff could be
handled more elegantly with arguments if the cues were saved as
abstractions instead of embedded as patchers.;
#P button 246 118 15 0;
#P window linecount 1;
#P newex 224 99 32 196617 sel 1;
#P newex 224 78 78 196617 receive cueOdd;
#P newex 146 145 27 196617 f;
#P window linecount 0;
#P message 176 146 17 196617 0.;
#P user ezdac~ 39 247 83 280 0;
#P flonum 163 103 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 49 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P window linecount 1;
#P newex 39 194 27 196617 *~;
#P newex 39 75 68 196617 cycle~ 440;
#P comment 258 100 100 196617 < - this cue ID;
#P connect 3 0 1 0;
#P connect 1 0 2 0;
#P connect 2 0 5 0;
#P connect 14 0 2 1;
#P connect 2 0 5 1;
#P connect 15 0 7 0;
#P connect 6 0 14 0;
#P connect 7 0 14 0;
#P hidden connect 12 0 13 0;
#P hidden connect 13 0 4 0;
#P connect 4 0 7 1;
#P connect 10 0 6 0;
#P connect 9 0 15 0;
#P connect 8 0 9 0;
#P connect 9 1 10 0;
#P pop;
#P newobj 28 109 46 196617 patcher cue1;
#P inlet 327 41 15 0;
#P inlet 30 41 15 0;
#P connect 0 0 3 0;
#P connect 1 0 4 0;
#P pop;
#P newobj 66 200 62 196617 patcher cues;
#P message 22 164 14 196617 5;
#P message 39 119 15 196617 3;
#P message 66 73 14 196617 1;
#P message 140 141 15 196617 4;
#P window linecount 2;
#P comment 230 190 100 196617 Turn me on , then hit numbers.;
#P connect 8 0 5 0;
#P connect 2 0 5 0;
#P connect 3 0 5 0;
#P connect 4 0 5 0;
#P connect 9 0 5 1;
#P connect 1 0 5 1;
#P connect 6 0 5 1;
#P window clipboard copycount 10;


Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno


December 15, 2006 | 10:22 pm

Chris, thank you so much!! That’s just the kind of thing I had in mind… Very elegant.

Best wishes,
Chris


December 15, 2006 | 10:53 pm

Hi again,

Chris (Muir), you mention in your edit that the cues could be handled more elegantly as abstractions – I know what an abstraction is, but why would it be more elegant? Is that a general rule, or does it just apply in this patch?

Still learning…

Chris


December 15, 2006 | 11:40 pm

At 3:53 PM -0700 12/15/06, Christopher Melen wrote:
>Chris (Muir), you mention in your edit that the cues could be handled more elegantly as abstractions – I know what an abstraction is, but why would it be more elegant? Is that a general rule, or does it just apply in this patch?

For me, it’s a general rule. Embedded patchers and arguments don’t always get along too well. Plus, having one copy of a patch as an abstraction allows you to make wholesale changes easier than having to edit multiple copies of a patcher. I will use embedded patchers during development _ONLY_ if I only have one of them. If I suspect that I will be using more than one of a patcher, or if I think I might want to use it somewhere else I will save it as an abstraction.

First, save this cue patch someplace. Call it "cue".

#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P comment 266 188 100 196617 $3;
#P comment 254 174 100 196617 $2;
#P comment 242 160 100 196617 $1;
#P outlet 39 209 15 0;
#P comment 196 188 71 196617 3. Initial Freq;
#P comment 196 174 59 196617 2. CueBuss;
#P comment 196 160 47 196617 1. CueID;
#P button 190 97 15 0;
#P flonum 112 146 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P hidden message 129 61 34 196617 0.25;
#P hidden newex 129 39 48 196617 loadbang;
#P button 219 97 15 0;
#P newex 190 78 39 196617 sel $1;
#P newex 190 57 92 196617 receive $2;
#P newex 112 124 27 196617 f;
#P message 142 125 17 196617 0.;
#P flonum 129 82 35 9 0. 1. 3 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P flonum 39 28 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 39 173 27 196617 *~;
#P newex 39 54 75 196617 cycle~ $3;
#P comment 231 79 70 196617 < - this cue ID;
#P comment 187 144 100 196617 Arguments are:;
#P connect 9 1 10 0;
#P connect 9 0 14 0;
#P connect 8 0 9 0;
#P connect 10 0 6 0;
#P connect 5 0 7 1;
#P hidden connect 12 0 5 0;
#P hidden connect 11 0 12 0;
#P connect 6 0 13 0;
#P connect 7 0 13 0;
#P connect 14 0 7 0;
#P connect 13 0 3 1;
#P connect 3 0 18 0;
#P connect 2 0 3 0;
#P connect 4 0 2 0;
#P window clipboard copycount 22;

Now save this top level patch to the same directory as the cue patch. Call this one whatever you like.

#P button 120 46 15 0;
#P window setfont "Sans Serif" 9.;
#P window linecount 1;
#P hidden newex 119 130 48 196617 loadbang;
#P hidden message 119 149 26 196617 127;
#P user gain~ 121 165 24 100 158 0 1.071519 7.94321 10.;
#P newex 177 208 100 196617 cue 4 cueEven 1100;
#P newex 177 187 94 196617 cue 2 cueEven 550;
#P newex 10 216 89 196617 cue 5 cueOdd 880;
#P newex 10 195 89 196617 cue 3 cueOdd 660;
#P newex 10 174 89 196617 cue 1 cueOdd 440;
#P newex 175 114 54 196617 s cueEven;
#P newex 66 114 49 196617 s cueOdd;
#P message 161 83 14 196617 0;
#P message 81 83 14 196617 0;
#P user ezdac~ 120 301 164 334 0;
#P message 175 37 14 196617 2;
#P message 20 82 14 196617 5;
#P message 39 53 15 196617 3;
#P message 66 25 14 196617 1;
#P message 197 75 15 196617 4;
#P window linecount 2;
#P comment 166 304 100 196617 Turn me on , then hit numbers.;
#P connect 15 0 16 0;
#P connect 14 0 16 0;
#P connect 13 0 16 0;
#P connect 12 0 16 0;
#P connect 11 0 16 0;
#P connect 19 0 7 0;
#P connect 19 0 8 0;
#P hidden connect 18 0 17 0;
#P hidden connect 17 0 16 0;
#P connect 16 0 6 0;
#P connect 16 0 6 1;
#P connect 7 0 9 0;
#P connect 4 0 9 0;
#P connect 3 0 9 0;
#P connect 2 0 9 0;
#P connect 8 0 10 0;
#P connect 5 0 10 0;
#P connect 1 0 10 0;
#P window clipboard copycount 20;

>Still learning…

Aren’t we all.

-C


Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno


December 16, 2006 | 1:11 am

Thanks Chris, that’s immensely helpful. The piece I’m using this patch in involves acoustic instruments, an ensemble of 5 players. What I want to do is use processed samples from each instrument (just single pitches), which are then triggered by hand using this method. I don’t really want to try any fancy FFT stuff yet, just some FM or waveshaping. I’ve had a go using the samples that come with Max, but I’m not getting any sound out of the patch now. Can’t quite see what I’m doing wrong again, I wonder if you’d mind just taking a quick look?

Cheers,
Chris

P.S: Obviously I’ve uploaded it without the relevant soundfiles, but I’m seeing them in the patch. Just can’t hear them!


December 16, 2006 | 2:38 am

At 6:11 PM -0700 12/15/06, Christopher Melen wrote:
>Can’t quite see what I’m doing wrong again, I wonder if you’d mind just taking a quick look?

I don’t have time to debug this, but a quick look shows that your are multiplying by nothing before hitting the lookup~.

Also, all your buffer~s and lookup~s are called wavetable. They probably want to have unique names (another argument would be good here, although you could also cons up a name based on the existing arguments)

I don’t know if you’ve received the canonical newbie advice yet, but: you really should work your way through the tutorials.

-C


Chris Muir | "There are many futures and only one status quo.
cbm@well.com | This is why conservatives mostly agree,
http://www.xfade.com | and radicals always argue." – Brian Eno


December 16, 2006 | 5:08 am

Quote: SecretTheatre wrote on Fri, 15 December 2006 15:53
—————————————————-
> Hi again,
>
> Chris (Muir), you mention in your edit that the cues could be handled more elegantly as abstractions – I know what an abstraction is, but why would it be more elegant? Is that a general rule, or does it just apply in this patch?
>
> Still learning…
>
> Chris
—————————————————-

if a building block is an abstraction (an extra file on
disk) you only have to change it one time if you need to
update or correct a bug in 100 instances of it.

this is the main advantage of [foo.pat] over [p foo].

if there were no abstractions/calling other patcher files
in max i think i would stop using it.

it is still (relatively) easy to have 5 abstractions in
your main patch but start them with different settings
using ->arguments inside them.

-110 (the building blocks fanatic)


Viewing 10 posts - 1 through 10 (of 10 total)