ADSR for Step Sequencer


    Apr 03 2006 | 1:23 pm
    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)
    Peter McCulloch

    • Apr 04 2006 | 11:33 am
      Thanks Peter,
      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.
    • Apr 04 2006 | 4:14 pm
      Hi, Will, give this a try. (I haven't filled in everything, but it
      should give you enough to work off of)
      Peter McCulloch
      max v2;
    • Apr 04 2006 | 6:57 pm
      Thanks Peter,
      That seemed to do the trick. I also added a delay on my velocites as they werent being packed at the appropriate time.
    • Apr 05 2006 | 8:52 am
      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
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      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
    • Apr 05 2006 | 11:01 am
      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 :)
      Will
    • Apr 05 2006 | 12:22 pm
      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)
      Will
    • Apr 05 2006 | 6:24 pm
      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)
      All the best
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      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
    • Apr 05 2006 | 8:39 pm
      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.
      Any suggestions?
    • Apr 06 2006 | 8:45 am
      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...
      Stefan
      --
      [][] [][][] [][] [][][]
      [][][][][][][][][][][][][][][]
      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
    • Apr 06 2006 | 3:15 pm
    • Apr 13 2006 | 1:44 pm
      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.
      Pretty stuck on this one.
      Will