Another problem with poly~! Please help!!

    Mar 10 2010 | 11:19 pm
    Hello everyone, this seems to be quite a common thread so sorry for appealing for yet more help regarding poly~!! Here is the patch itself:
    and here is the contents of poly~:
    What I want to happen is that when the first or second toggle at the top of the main patch are pressed, a note gets played out of the poly~, when the toggle is deactivated (and spits out a 0) I would like it to trigger a fade out for the sample that was just triggered within the same poly instance. Apart from sounding obviously wrong things seem to be acting a bit weird, I have hooked up the first toggle to a [mutemap 1] and a [busymap 1] message to see what is going on in the poly~ objects and it seems that two poly~ instances are being used every time a toggle gets pressed, you can see this being printed into the max window. I really am stuck on this one, any help would be greatly appreciated!!

    • Mar 11 2010 | 2:41 am
      Does this do what you want?
      the melodicpoly subpatch:
      And the main patch:
    • Mar 11 2010 | 8:16 am
      Thanks for your reply Chris, unfortunately the patch I'm working on has made life a bit more complicated than that for me! The [sel 1 2 0] object at the beginning of my main patch is integral. [sel] will receive either a 1 or a 2 followed by a 0 before another 1 or 2 (and consequent 0) is received. As you can see from the main main patch i posted I have tried to store the "48" and "55" numbers as they are triggered by the [sel 1 2 0] object into an [i] object, that object then awaits the arrival of a bang from the 0 output of the [sel 1 2 0] object. The intention was that the [t 48 1] and [t 55 1] object would bind the 1 to the note numbers and then the [i] would bind the 0 to the same note number when it was consequently received. I thought that [_midinote] would filter out the repetitions but it doesn't seem to be working that way!
      Heres a slightly different version of my main patch, it better equates the input that the poly will be receiving:
    • Mar 11 2010 | 8:19 pm
      And of course that's the first thing I removed :-)
      I think the main issue with your control scheme is in your use of [pak]. This is causing a doubling of input to [poly~], one message when the velo byte comes in and one for the note. Changing this to [pack} removes this.
    • Mar 13 2010 | 9:47 pm
      Thing is that if I use [pack] i will have to feed the velocity into the left inlet to trigger an output as that is the element that will be changing, once this happens you'll end up with the same problem as before, two message being sent to the [poly~], the sample will trigger twice. I just do not understand why the [prepend midinote] message is not filtering out the double triggering of the note, I can't see how what I am sending it could be interpreted any other way but note on - note off! Just so that everything is current and not spread out over this thread here is the poly patch again:
      and here is the main patch (I noticed that I was using the Jasch object [_] instead of the [prepend] object, here it is with the standard objects only) :
    • Mar 13 2010 | 10:44 pm
      Voice allocation over MIDI is mostly unspecified. Assuming anything about how the voice allocation occurs is asking for trouble.
      The version of your patch that I'm using seems to work OK. I've added a bunch of print statement to show what is being requested.
      top level:
    • Mar 14 2010 | 11:40 am
      reckon there should be a poly~ subforum
      poly~ = ARRGGGHHH! :( /Ahhhhh :)
    • Mar 14 2010 | 10:36 pm
      ARRRRRGGGGHHHH - Ahhhhhh is right! You bollock around with poly~ for ages pulling your hair out trying to make it work (ARGHHH) then suddenly everything works (Ahhhhhh) and the world becomes a serene and happy place once again...