Device Details

I've been playing with this with downstream arps and other generators. I'm not sure if this device is at fault, but it appears that a pretty decent amount of latency builds up (like 1/2 of a 32nd or even approaching a 16th at times) if you chain a few midi tracks together.

E.g. one thing I do with this is to create a MIDI effect track with 4 chains. Each chain gets a NPF assigned to a beat. Then downstream effects in the chain shift scale, transpose, arp, whatever. To get that "recorded" I often send the result of this set of chains to another MIDI track. So I'm not often using the setup in a "live" fashion. Anyway I have noticed that the downstream MIDI track is actually showing the note-starts as coming in *before* they should. E.g. showing up before 1.1.1. I don't know what's causing this. I suspect Live's trying to account for latency here but I think it happens with other devices so I'm not sure it's to do with this device only.

In extreme cases if you're not careful this can cause problems later in downstream merging where some note-offs will come before the note-on they go with. Yeah, not good. Anyway it's easy to spot and if you're especially sloppy at the start you can avoid it altogether.

I'd like to hear people's interpretations of what might be going on here if noticed. Generally I can just re-quantize downstream and things snap up just fine.

1.1 fixes storage of parameters (duh, sorry).

i verified it loads and reloads those properly at least when you reload an entire live file.

working on verifying presets and automation...

presets work. (e.g. created ones for "1st 4th" "2nd 4th" so on).
sorry for the navel gazing. forgot about that last bit of spit and polish :)

something which i found to consistently thwart competing/out-of-sync note-on/note-offs as the streams merge downstream is to fudge the onset of each new note start away from any previous note-off by ~128th. this seems to work. it makes me nervous but i think i understand why it happens. i may work to build in a mechanism to do this automatically but for now... if you're trying to use this in multiple-chain scenarios (where it makes sense, actually) then do that little trick on your input material and if you desire on/offs to abut then re-quantize at the end.

uploaded 1.2

. added bias control (0.0% -> pick notes "inside" the bin, 100%-> pick notes "closest" to the start of the bin).

. added better ui coloring, grouping.

. added copyright inside.

the trick about pulling notes-on away from prior notes-off events works pretty well, actually. just wish i could be certain doing it programmatically would be viable.

grr... wish i could edit the previous post.

bias control is
0.0% -> pick notes "inside" the bin.
0.5% -> pick notes "closest" to start of bin (i.e. notes starting within a half bin/note size before or after the start of the bin)
1.0% -> pick notes "inside" the *previous* bin.

and of course: pulling the notes-off forward works just as well...

fwiw: if you're trying to capture "all within the beat" type of operations vs. "closest to the beat" then I find that a bias of 0.10% works well to avoid pulling notes to the prior bin which are starting right on the bin. at least at 90bpm anyway.

uploaded new version 1.3
adds a table to allow specification of multiple notes/bins to pass.