note position filter

Comments (9)

• kfractal · March 18 2012
  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.
• kfractal · March 18 2012
  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...
• kfractal · March 18 2012
  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 :)
• kfractal · March 18 2012
  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.
• kfractal · March 18 2012
  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.
• kfractal · March 18 2012
  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.
• kfractal · March 19 2012
  and of course: pulling the notes-off forward works just as well...
• kfractal · March 19 2012
  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.
• kfractal · March 19 2012
  uploaded new version 1.3
  adds a table to allow specification of multiple notes/bins to pass.