No wonder Your brain hurts if You look for too long in that forest full of delays , ints, bangs, trolls, hobbits etc As first - what is that {< 0 } supposed to do ? there is no velocity lower than 0, and even if so, and one had the result 0 or 1, it is set to bang on whatever output... Where is sel 1 or sel 0 to trigger random object ? If You make such simple mistakes to start with, then It will get hard to do more complicated stuff... Your patch is set to produce 32 notes of same pitch, each fired after delay time which gets set randomly, so it is well possible that some notes would get triggered only few miliseconds apart from each other. That is never going to work properly, I mean the effect will be too weird, overlapped notes, cut notes, overloaded polyphony ... But that is not my bussiness, so I'll stay out of it, and I don't want to just criticise, but also to be of some help as well. You don't need that many things in there, one message containing pitch - velocity combo can be banged by any number of delayed or timed bangs, Then as next You need to decide how to deal with Note Off. Let's suppose that You want only Note On to create random delay times (means You fix that mistake {< 0} -> bang) Than we get a list with pitch and velocity, which receives all the bangs from different delays, or something better, let's leave that for later time. When Note Off gets in it could turn all delays which did not allready bang, by sending stop message to all delays. That would make retrigger effect till note off stops the note. Or if You want to hear ALL 32 delayed notes, then You could send Note Off (velocity 0) through pipe having value of (highest delay time + note length) in ms. Or anything else. Here is a patch with simplier approach : random values get stored in coll, highest delay time gets sent to line which counts in ms and so recalls delay times form coll which then bangs on each recall the message containing pitch - velocity. When Note Off gets in, it gets sent when line comes to the end of ramp, delayed by measured time of held note.

Wow, thanks for the detailed feedback. Very informative.

You're patch is definitely a huge improvement on my version. Although mine wasn't actually correctly portraying what i was actually trying to do.

I was trying to trigger a note 32 times with random delay values for each note, which i'm able to specify the range of, every time midi triggers. Now, as you stated, you get a extremely dense and sustained version of the note (because of the sustain time being stagnant throughout the 32 notes). I would like each note to have it's own sustain time, instead of one overarching one. For example, when i press a note for 50 ms, i get 32 randomly delayed 50 ms version of the same note. If i press the note 200 ms, i get 32 randomly delayed 200 ms version of the same note.

something like this:

My last addition was the velocity randomizing patcher, but it doesnt really function properly. Some notes keep sustaining. At least when using it with a long sustaining sample in ableton's sampler. What do you think?

That could maybe work if You would use Note Off to trigger the list of Pitch Velocity Duration and send it to makenote. Makenote has some modes to deal withe repeated notes. repeatmode 2 works a bit like in first patch.

But most synths will either retrigger repeating notes, or maybe go up to alowed polyphony, in any case I don't think that You can get that overlapped 32 notes of same length easy, maybe if You would use 32 midi channels

Thanks :) The makenote object is usefull, especially repeatmode 1, which basically does the right interval timing. But there are some things missing.

The sustain for example, does not follow the length of the played note. Just a small bang. Secondly, the note pitch is still stagnant because of the message trigger.

The patch i posted earlier actually does exactly what i want (except for some notes being sustained continously, probably because the note off messages enter the midiout object too quick to process), i just feel like the method i used is way too complicated.

Here is an audio example of my latest patch versus your latest one:

https://www24.zippyshare.com/v/vPBXkfcO/file.html

Any idea how i can simplify my latest patch and get rid of the constantly sustained notes?

You use pak to collect delayed pitch and velocity pairs. As pak updates its output on any input, that should in theory trigger 64 times note on and 64 times note off, but I am measuring 160 events. 128 + 32 which are random velocities The way You trigger random velocity is wrong - You do it on note on and note off, and that generated 32 velocities get sent through previous pipe times and trigger the notes, because You use pak, instead of pack. If You use pack and find a better way to randomise velocities ...

Alright. Indeed. Should check the console some more. I'm gonna let this one rest a bit and perhaps come back to it later. I realize that what i was trying to do, simply isn't possible in midi world, at least not in this manner, unless if i'd worked with 32 midi channels, as you stated before (I didn't get your point back then, now i do.) Thank you so much for your patience, instructions and activeness on the forum. It's been extremely helpfull! Most certainly coming back to this page in the near future.

I did not mean to discourage You to move on with this, but it is true that same pitched note -> single midi channel have some limitations. I did not actually understand properly what You were musically after, just looked at it technically. If it were some kind of tremolo, or strum over many strings it would have worked with retrigger mode. You could make oscilator based synth in poly and use 32 voices, that could work without any midi limitations

Definitely not discouraged :)

Just realized some things. Moving on to make a midi effect in the same spirit but different inner workings. I'll post it when i have an idea.

Thanks again, really helped a lot.