Does this do what you want?

the melodicpoly subpatch:

And the main patch:

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:

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.

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) :

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.

melodicpoly:

top level:

reckon there should be a poly~ subforum

poly~ = ARRGGGHHH! :( /Ahhhhh :)

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...