Delay a midi note by its length

Like this?

depends where it is coming from.

if it is coming from within max, in an ideal case from detonate, you could read out the note on / note off data in NRT/uzi style and "convert" the loaded midi file into a detonate format file, which now includes the duration values as controller X value right before the note ons.

in realtime - aka the opposite of makenote - it is impossible. :)

if I can delay a note by its length, then I can know its length by the time it arrives.

no, you can't, unless you can see in the future.
note arrival - if you mean the moment note ON arrives.
At that moment you can use pitch and velocity for your articulation, but length will be known only after note OFF arrives.
Only if you read midi file or seq , you can read and collect all infos about notes and their length in advance, before starting playback.
In case of real time midi input, and in case that you want to output note AFTER note OFF arrived using measured note length, you need a coll or something similar in addition to borax to combine pitch, velocity and length.

example input :
note 48 120 ..... 48 0 1000ms later.
At the point when 48 0 arrives you send list 48 120 1000 to makenote.
makenote object would be handy because you can pass pitch, velocity and length to it.

If what I describe is what you need, it should be no big deal to combine couple of objects to do so.

Thank you everyone for the replies.

RE: SOURCE "output note AFTER note OFF arrived using measured note length"

This has been the general direction of my efforts so far, but all of my attempts have been missing "something" and generally end up convoluted.

My suspicion is that at least one of my current points of failure has something to do with with storing the midi note(s) until the off message (0) comes around.

Come to think of it, part of the problem likely has to do with the scenario that if the next note in the sequence is SHORTER than the one just fired (by its own off message), then the next off message (of the shorter note) will cut off the currently currently playing note.

With that in mind, I could see how midi format might bypass this problem by using the duration inlet (from borax duration out).

. . . which leads me back to the issue of storing notes. I am familiar with coll, but I don't have much experience with updating it dynamically.

I will do some experimenting and report back.

>> if the next note in the sequence is SHORTER

yes, exactly, otherwise you might just use a bigger window such as 5 seconds and do the rest by waiting and recombining things per key.

recording midi events is quite possible with coll, but detonate would do the delta time stuff for you automatically, plus has tracks and channels.

>> bigger window such as 5 seconds and do the rest by waiting and recombining things per key.

I have also come to this conclusion. For now I'm trying to avoid the recombination as it would still likely involve some sort of note queue (the thing that I'm currently not doing right). I've had my eye on detonate as a performance capture feature anyways so maybe. . . two birds with one stone.

But in the spirit of contingency, I welcome any thoughts on recombination. Specifically in the context regarding a queue of some type.

this process would be very similar to keeping track about running notes for othgehr purposes, and there should be some example patchers in the forums or even in the examples.

i would probably use a coll with fixed index names from 0 to 127 and write 0 for free, 1 for note on, and X for note off behind them.

or why not use [pak] with 128 inlets?

then you have split the incoming stuff per key adn wrote a busymap into a list like this:

0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 1 1 0

the conversion itself simply means to measure the time between velocity nonzero and velocity zero. [timer] is the object you are looking for.

the most difficult part is to add a proper start/stop mechanism around it.

You don't need to worry about retriggering of allready held notes when using makenote.
It has repeatmodes which can be adjusted to your likes.
check the help file for that.

here is one option with coll.

cellblock is added just to monitor what happens, you can remove it.
if you want to keep notes in coll (not remove them after note off)
remove underlined part of this message.
merge $1 $2, $1, remove $1
next note on will replace it anyway.

SOURCE, I was experimenting with your makenote solution, but something is still missing.

I took a screenshot so I may offer you my interpretation before I end up deleting/starting from scratch. It's thrown together but allow me to offer an explanation.

note* I am using midiformat just before the unpack, but in the context of this screenshot/experiment I am staring with unpack. Also, I'm handling velocity performance elsewhere in the program so in this case it is simply a 1 or 0 (note on/off).

From the unpack, I'm sending velocity to the if statement. If it is equal to 0 (note off) then it sends a 1 (note on). This will simultaneously fire a note on message and last stored note in the message box below (40*). The message box to the right of the if statement is the duration from borax, sent at the note off . At this point, all three integers should be hitting the makenote at the same time. Makenote does its magic, while also sending the channel number (2*) to midiformat.

To be clear, this does not work.

If you can offer any insights or interpretations, I would greatly appreciate it.