Midi Trigger Woes

jd's picture

Hello Gang!! Have a Yamaha dd-55 Midi drum rig, have it sucessfully triggering movies based on Last Note Number using the Kineme Midi Follower Patch. (which ROCKS incidentally) this is good for a lot of what I need. BUT this method does not allow you to re-trigger the same clip over and over - The note # doesn't change till you hit another pad - then come back. so drum rolls re-triggering the same vid clip don't really happen the way I'd like.

I want to use the other Kineme Midi Patch that shows current Note On/Off status and current velocity, BUT, the way the DD-55 sends Midi notes is EXTREMELY quick with a Note ON plus Velocity, then imediately sends a Note OFF plus a 0 Velocity. Midi Monitor shows these events happening in that order, and at almost exactly the same system time. This happens far quicker than any of the Midi input patches (Apple Midi Notes too!) can reliably "catch" the incoming data.

Have tried storing numbers/pulses on change, but is just WAY too fast for the midi patches to pick up in the first place, so they cannot pass the info on.

I have several other keyboard style controllers that I have up and going perfectly, their Note On/Off happens much more slowly than the drum module.

any ideas on how to handle this?

I heard of a pc program called midi yoke that seems to intercept the incoming midi triggers, and supposedly can be configured to "HOLD the Note ON message" for x time so is long enough for some software to see that trigger happened. This kind of workaround may be the next path of investigation

Hopefully this makes sense, is the last tripping-up point to be resolved in having a really cool live performance rig.

thanks! jd

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
FTL (faster than light)

the midi patches currently record midi events as they happen, and apply changes as soon as they happen (not waiting for the next QC frame). So, I'm guessing that something like this takes place:

  • t=0; qc draws a frame
  • t=0.00010 midi note on -- patch sets output true
  • t=0.00011 midi note off -- patch sets output false
  • t=0.01666 qc draws next frame (with state set to off).

Work arounds:

option-click the QC preferences, and disable VBL sync -- this will make QC's framerate go up to as fast as the machine can go. This might capture some of the notes. Note that this will cause rendering to shear and look bad, so it's not a real solution, just a thought experiment.

real workaround: we'll have to modify the patch to latch on to on-ness until the next frame (where it'll get cleared). This will allow the composition time to capture the note.

Problems: the logical extension to this is, what happens if there are 2 note on/off pairs between a frame, and you want to know how many happened? This requires a big long complicated patch that feeds you all midi events from the last frame until present, probably in a structure.

I don't think we'll go as far as the last bit (timeline structure output), but latching notes shouldn't be too difficult.

smokris's picture
Other Triggers

jd wrote:
the way the DD-55 sends Midi notes is EXTREMELY quick with a Note ON plus Velocity, then immediately sends a Note OFF plus a 0 Velocity.

Some trigger modules allow you to set minimum gate time directly --- my DrumKAT does, and many of the Roland TD-series kits I've worked with also do.

But Chris's suggestion about note latching would be useful for other purposes, too, and would be trigger-independent. I'm thinking maybe the patches should have a "Latch Mode" input (when off, it behaves as it currently does).

One solution to the "2 note on/off pairs between a frame" issue might be to just queue them up and play them back exposing one state per frame (i.e., frame 1 = on, frame 2 = off, frame 3 = on, frame 4 = off). That way each note gets exposed fairly close to when it was originally triggered, and the user doesn't have to muck around with structures. Of course, this would only work for something relatively infrequently-triggered (such as the case proposed here), otherwise the queue builds up --- thus the option to disable this mode.

jd's picture
YES! * t=0; qc draws a


  • t=0; qc draws a frame
  • t=0.00010 midi note on -- patch sets output true
  • t=0.00011 midi note off -- patch sets output false
  • t=0.01666 qc draws next frame (with state set to off).

I think this is EXACTLY what is going on, OCCASIONALY QC will"get it" but most times not(99%), and is far too unreliable for use.

My DD-55 is a high end toy, with no access to the Midi gate time (but wouldn't that be cool)

OK here is another thought... preface: I do not have a good grasp of structures, in particular the parsing to get what I want. soooo. Having said that, I do have a structure setup I have built in this drum trigger quest, am able to parse/view the data down to a list of velocities for notes 1-128. Have gotten to where I can occasionaly see the hit being registered and get a velocity number and store it.

I noticed that everytime I hit a pad (or even the same pad) the Hex number at the top of the structure readout changes. (when holding mouse over structure's output node in editor) Is like a message or structure ID or header that changes with each hit. Maybe is a system time, and I have never seen it repeat, dunno, BUT it does change with EACH and EVERY hit, even if on the same pad or another. So it is updating the structure somehow on every hit.

If I can find a way to access that part of the structure, I can have QC do a ping-a-pulse-on-CHANGE thereby getting my "some pad has been hit" message. From there I could make that work a lil better for my purposes.

make sense? laugh on all you good programmers I'm cool with it.

thanks MUCHO for your ideas/help/and software!!!!


cwright's picture

I think that hex value you're seeing is the structure's address in memory. it updates because the midi receiver receives the hit, and updates the structure (even though it'll undo it a few ms later, in your case).

The problem with that is that sometimes the address may not change. Probably not in this version, but in a future version it might reuse the address as an optimization or whatever.

[the signal private patch might allow you to notice address changes -- or, the javascript patch will get executed when it changes, so you can write some logic in there to do what you can.]

I think latching is the way to go for this, seriously. What kind of timeframe are you on? are you able to commission this addition to miditools?

jd's picture

Ahh, I imagine it is the mem address, will look at it tonight to see. Will try the signal private patch/java ideas and see what I come up with.

Am on no particular timeframe, can donate lotsa time/brainpower/doc-writing/beta testing, but no $$ right now for this. If someone is eventually going back into the guts of these patches tho, then here is some food for thought.

a) A latch mode WOULD be useful. I read this as working something sorta like:

Frame 1

Hit pad / Note On Message / Note OFF Message / Patch shows Note "34" / Gate "True" / Vel "87"

Frame 2

Patch shows note "0" / Gate "False" / Vel "0"


Is that sorta/something like what you had in mind?

b) A "Hold These Values until flush/reset" could be useful too. maybe not, I figure I would be storing them anyways.

c) I personally dont see any need for the "history" of note On/Offs / Velocities etc. in-between each QC frame. Someone else might. sounds like a pain too. :)

jd's picture
Re: Midi Trigger Woes

Hey gang! two things, just wondering if anyone had gone into the Midi patch to do the "latch until next frame" fix on this yet. Just curious, I will finally be out of the "working too hard zone" and be able to get back to work on the fun stuff in Quartz soon.

Other totally unrelated stupid question. I see the Wiimote patchs, sounds like a extremely good controller for some of my upcoming projects/idea farming. So here is the stupid question... Can I use the Wiimote standalone, as in, can I just get a Wiimote (I see them at Walmart) or do I need the Wii Base station also? I got the impression they were a bluetooth kind of thing that may NOT actualy need the base station for Quartz work.

cwright's picture
Re: Midi Trigger Woes

haven't touched the midi patches much lately (dmx + snow leopard + kineme3d + secret projects have sapped most of our time the past few months).

the wiimote will work without a base station (the Wii Console) -- you just need the remote itself. However, the base station does come with the nice sensor bar attachment and a 1/4 mile cord, which is much more aesthetically pleasing than rolling your own. (you only need this for IR support though -- the motion sensor and attachments work fine without IR).