Will Pickersgill

It may have to do with "in" acting differently than receive or inlet. 

(sorry, away from computer, so can't look at patch) The help file for 

ADSR~ uses a monophonic synth. As such, there is only one instance to 

send values into. However, if you scale it up and add more copies, the 

values go in only the inlets of the copy that is active! (unless you 

do the appropriate target message beforehand)

While the help file for ADSR~ is definitely useful, I think it's 

slightly misleading, as the expected behavior is that all copies of the 

synth would receive the same values if you were to add more copies, and 

that doesn't seem to be the case. The workaround is to use sends and 

receives. I'd also recommend using the "float" object to store the new 

values in the right inlet, and then pass them on to ADSR~ on the next 

note. (unless you want to adjust the current sustain level)

It may have to do with "in" acting differently than receive or inlet.  
(sorry, away from computer, so can't look at patch)  The help file for 
ADSR~ uses a monophonic synth.  As such, there is only  one instance to 
send values into.  However, if you scale it up and add more copies, the 
values go in only the inlets of the copy that is active!  (unless you 
do the appropriate target message beforehand)

While the help file for ADSR~ is definitely useful, I think it's 
slightly misleading, as the expected behavior is that all copies of the 
synth would receive the same values if you were to add more copies, and 
that doesn't seem to be the case.  The workaround is to use sends and 
receives.  I'd also recommend using the "float" object to store the new 
values in the right inlet, and then pass them on to ADSR~ on the next 
note.  (unless you want to adjust the current sustain level)

adsr-for-step-sequencer

I would like to be able to change the sustain for each note really. I am sending the velocity info through an outlet to the adsr~ so I am not using the "IN" object as used in the adsr~ help file. I am basically going off the polysynth example they give but I am still encoutering problems.

Hi, Will, give this a try. (I haven't filled in everything, but it 

Hi, Will, give this a try.  (I haven't filled in everything, but it 
should give you enough to work off of)

That seemed to do the trick. I also added a delay on my velocites as they werent being packed at the appropriate time.

> That seemed to do the trick. I also added a delay on my velocites as

> they werent being packed at the appropriate time.

You will get into trouble if you try to order messages by delaying them. 

Now its time to really learn how to use the trigger object and how Max 

is ordering messages. You need to understand that, its very essential 

and a bug caused by delaying messages will be hard to find. Avoid it if 

possible. Objects to look into are also buddy, swap...

As I remeber you could easily strip down your patch approximately by a 

factor of 100 simply by using colls instead of hundreds of subpatchers. 

I posted a coll with all the chord information recently on the same 

thread, try to understand it and you'll trash a big portion of your 

Actually your [p octave 5] was filled with wrong numbers... Making 

functional subpatchers with a rule will save you a lot of patching time 

as well. Though in this case I believe a single coll could also be a 

You are on a good path Will, keep going and learn to be lazy in terms of 

patching, and busy in terms of learning and experimenting, try to find 

If a patch grows big always consider: "there must be an easier way to do 

Do not hesitate to trash a lot of work, even if its done already and it 

works. Always go for the more elegant solution. Later if you forgot how 

you did it and have to come back, you will appreciate it.

Will Pickersgill wrote:
> That seemed to do the trick. I also added a delay on my velocites as
> they werent being packed at the appropriate time. 

You will get into trouble if you try to order messages by delaying them. 
Now its time to really learn how to use the trigger object and how Max 
is ordering messages. You need to understand that, its very essential 
and a bug caused by delaying messages will be hard to find. Avoid it if 
possible. Objects to look into are also buddy, swap...

As I remeber you could easily strip down your patch approximately by a 
factor of 100 simply by using colls instead of hundreds of subpatchers. 
I posted a coll with all the chord information recently on the same 
thread, try to understand it and you'll trash a big portion of your 
patch...
Actually your [p octave 5] was filled with wrong numbers... Making 
functional subpatchers with a rule will save you a lot of patching time 
as well. Though in this case I believe a single coll could also be a 
more clear and effective solution...

You are on a good path Will, keep going and learn to be lazy in terms of 
patching, and busy in terms of learning and experimenting, try to find 
different solutions for the same goal.
If a patch grows big always consider: "there must be an easier way to do 
it"...
Do not hesitate to trash a lot of work, even if its done already and it 
works. Always go for the more elegant solution. Later if you forgot how 
you did it and have to come back, you will appreciate it.

  [][]  [][][]  [][]  [][][]
[][][][][][][][][][][][][][][]

         Stefan Tiedje
         Klanggestalter
     Electronic Composition
               &
         Improvisation

            /~~~~~
     \   /|() ()|
     ))))) )|  |  |( \
     ///     _/)/ )))))
             ___/   ///

-------------------------x----
--_____-----------|-----------
--(_|_ ----|-----|-----()----
-- _|_)----|-----()-----------
----------()------------x-----

14, Av. Pr. Franklin Roosevelt,
94320 Thiais, France
Phone at CCMIX +33-1-57 42 91 09


Thanks Stefan for the help and encouragement.

I know someone would pick me up on the delay trigger :-p I knew it was a sneaky and very temporary way round the problem.

You mentioned you posted a coll with all chord information in, do you happen to know what thread that was in or were you reffering to a thread I had started in which case I will go hunting.

About coll: If I enter information into the txt editor of coll and save it, it stays there till i reload the patch. The coll you posted I take it remembers what was enter into the coll previously? is this just done by loadbang it a txt file already containing the relevant note(chord) info ?

P.S Cheers for the heads up on p octave 5. Hadnt really programmed anything that high pitched in my matrix yet :)

Thanks Stefan for the help and encouragement. 

I found the thread you were talking about in which you showed how chords could be put into a coll and retrieved and played as midinotes.

I fully understand what you have done to achieve it, but in my case as I am using "getcolumn $1", which is responding to the tempo counter, I am only getting a list of cell values (0,1). So if I make a coll with all the relevant information in it I will still need to map the column information into corresponding coll list values.

Wont that method essentially be what I had before but instead of routing the cell vaules to subpatches (for their midi note values) I would be routing them to a coll list value then on to the coll to retrieve it? (hope thats clear)

> but in my case as I am using "getcolumn $1", which is responding to

> the tempo counter, I am only getting a list of cell values (0,1).

As I don't know what information you send to that ultralong unpacker, 

its hard to point you to a more efficient retreival method.

I am sure "there must be an easier way to do it" but probably before 

> Wont that method essentially be what I had before but instead of 

> routing the cell vaules to subpatches (for their midi note values) I 

> would be routing them to a coll list value then on to the coll to 

The coll I sent did have lists, which then have to go to iter to achieve

(By the way to embed a coll there is an inspector with a checkbox)

Will Pickersgill wrote:
> but in my case as I am using "getcolumn $1", which is responding to
> the tempo counter, I am only getting a list of cell values (0,1).

As I don't know what information you send to that ultralong unpacker, 
its hard to point you to a more efficient retreival method.
I am sure "there must be an easier way to do it" but probably before 
that ultralong unpack...

> Wont that method essentially be what I had before but instead of 
> routing the cell vaules to subpatches (for their midi note values) I 
> would be routing them to a coll list value then on to the coll to 
> retrieve it? (hope thats clear)

Yes, but without all these subpatchers.
The coll I sent did have lists, which then have to go to iter to achieve
the same as your subpatchers.
(By the way to embed a coll there is an inspector with a checkbox)

What I basically have going into that ultralong unpacker is the column information from my matrix.

I have a tempo object connected to a gate object which in turn is connected to a "getcolumn $1" message. I am then sending that information to the unpacker so I can get the cell info for each column. The reason i am doing that is because I have my matrix in bpatcher so that I can shift octaves (a la Reasons Matrix). So the matrix in there is pretty big and then I have different pixel offsets to move up/down.

I then have that info routed to numbers related to items in a coll (I used your method there). It seems to work quite well with coll and flush but it seems that my note is receiving the velocites before the note and then going back to zero so not sounding. This may have to do with the fact that the velocites are also sent to a coll and read out with tempo to note.

I tried fixing it with a combination of swap and buddy but could figure out how to get them to trigger at the same time.

I would post that main patch but it contains quite alot of images and pictrl's.

I then have that info routed to numbers related to items in a coll (I used your method there). It seems to work quite well with coll and flush but it seems that my note is receiving the velocites before the note and then going back to zero so not sounding. This may have to do with the fact that the velocites are also sent to a coll and read out with tempo to note.
I tried fixing it with a combination of swap and buddy but could figure out how to get them to trigger at the same time. 

> What I basically have going into that ultralong unpacker is the

I am just guessing, but you might find a more elegant solution with 

Will Pickersgill wrote:
> What I basically have going into that ultralong unpacker is the
> column information from my matrix.

I am just guessing, but you might find a more elegant solution with 
funnel/spray...

I can still not find a way round this. The velocity still seems to be received too early no matter what I change, or what configuration of swap and buddy I use.

I am starting to think implementing a real time delay would be an answer to just have to work out from the bpm and 16 what the time for 1 step is and have it delayed by that.

I can still not find a way round this. The velocity still seems to be received too early no matter what I change, or what configuration of swap and buddy I use.
I am starting to think implementing a real time delay would be an answer to just have to work out from the bpm and 16 what the time for 1 step is and have it delayed by that.

ADSR for Step Sequencer