HI forum,

I am currently using a pd patch to take incoming MIDI values from a drum pad, manipulate them, and pipe them into another program for sound generation. Unfortunately, my drum pad seems to be constantly sending MIDI clock information. Here's a screenshot to view incoming MIDI messages to my system.

In my patch, I use a custom abstraction to "learn" MIDI notes coming into pd. Basically, when I enable my abstraction to "learn", I tap a note on my MIDI keyboard or drum pad and it instantly becomes mapped to that abstraction. It's basically a really easy way to set the arguments for [notein], [ctlin], etc. However, this MIDI timing signal is screwing everything up. Now when I try to "learn" a MIDI note, the note "0" from channel "10" keeps triggering before I even have a change to tap my keyboard or drum pad.

Any idea how I should filter this out? I would like to just ignore all messages from channel 10, but that's where all my actual note data comes in as well.

@rjp9 Hello.... I think it likely that your profire2626 is generating the clock, and that you have it connected (or it has been connected) to some other software that has told it to do so?

The edit button has moved..... it is now under the blue "cog" at the very bottom left of your post.
David.

It's usually best to first find out where the the unwanted messages are coming from and, if possible, disable them at the source. Filtering after the fact is doable but it's still a waste of control bandwidth and process cycles that can affect timing etc.

I would tend to doubt that it's coming from the Profire as there aren't too many sound cards with built in midi clock generators (thou it's not a bad idea if it's a real hardware midi clock) thou I can't confirm that as I can't find a manual for it online. More likely it's coming through the Profire's midi interface from this unnamed "drum pad" you speak of -- is this really just a dumb trigger pad, or something with a built in clock or sequencer (i.e. Roland HandSonic)?

If you really can't turn it off and you don't have a midi hardware filter handy, then there's a couple of options on the software side. The first is to use a third party app connected between the Profire and Pd (such as midi patchbay on the mac, qmidiroute on linux etc). This is the method I use to get rid of active sense messages from an old cheap MidiMan USB controller that lacks a disable option. I prefer this so Pd doesn't have to deal with any of it.

You can also use a simple patch from within Pd to do this, but as you haven't been specific about how your patch works I'm not sure where you could insert it. It sounds like you are taking raw input from a midiin object. If that's the case, you can simply connect the midiin output directly to the inlet of the patch below and connect whatever else you have to the output.

midirealtimefilter.pd

@whale-av said:

I think it likely that your profire2626 is generating the clock, and that you have it connected (or it has been connected) to some other software that has told it to do so?

@NoDSP said:

More likely it's coming through the Profire's midi interface from this unnamed "drum pad" you speak of -- is this really just a dumb trigger pad, or something with a built in clock or sequencer (i.e. Roland HandSonic)?

Hi guys. Thank you so much for you input. The drum pad I am using is my buddy's ancient Yamaha DD-55, a ubiquitous consumer drum pad from like the 90's:

I did some reading in the online manual, and here's what I found:

So it does look like this is outputting MIDI clock data, when set to "internal" mode. I'll try your suggestion @NoDSP of trying to eliminate these messages at the source, because it looks like I can either set the clock to "external mode" or reprogram all the drums pads so that they send messages on channel 1 instead of channel 10, and then just ignore channel 10. And if that doesn't work, I will implement your abstraction.

Will report back soon

@NoDSP said:

You can also use a simple patch from within Pd to do this, but as you haven't been specific about how your patch works I'm not sure where you could insert it.

It's this one here: http://forum.pdpatchrepo.info/topic/9172/learn_midi-an-easy-way-to-learn-a-midi-note-controller-or-program-change

Ah yes that '90s era Yamaha consumer gear. I resurrected an old PSR-320 that somebody left in a pile of rubble around here. There's no way to stop it from sending clock if the sequencer is activated. It would be OK with the sequencer stopped if it didn't then start spewing active sense messages, which can't be stopped at all. Fortunately my midi interface has it's own filtering options so that stuff never reaches the computer (though I can't do that with USB midi devices, hence my need of the software filter for the midiman).

As you can see that patch is very simple, it just uses the greater than operator to strip out any bytes above 248, which is where the realtime messages reside. To give credit where due I didn't even put that together myself I just copy pasted the filter section of Alex Norman"s sysex2list patch.

Let us know how it goes. I think I DLed a copy of that patch you're using some time ago but haven't had chance to mess with it yet.

Edit: BTW midi system reatime messages are transmitted globally i.e. no channelization, so trying to change and filter channels won't help you here.

I took a look at that patch you are using, and I don't think the filter patch is going to help.
None of those midi input objects should be passing realtime information to begin with. It is possible that Pd's midi input buffer is being flooded, but it's hard to say as Pd's midi realtime implementation isn't really the greatest ATM. Active sense messages may be even more of a problem than clock and it's possible that the devs didn't take A.S. into consideration since normally A.S. messages have no place in computer midi (and very little place in straight midi hardware as well)

This is why I use external filtering apps to remove A.S. messages before they can reach Pd. Interestingly, I noticed that even though the Qmidiroute input monitor will show A.S. messages coming in, it lists them as "Unknown" -- which to me suggests that the developers didn't even know the midi standard well enough to define them. This may be the case with Pd as well -- which might explain why they would reek all sorts of havoc once they got in.

@NoDSP I think you are spot on. I tried your filtering solution in-patch to no success. Every outlet of every MIDI-in object was being triggered at "Active Sense" rate.

My temporary solution has been to set the device's MIDI clock settings to "external" so that it looks for an external signal but still outputs MIDI data. I have encountered some latency that way, although I'm not sure that has anything to do with the external clock setting as much as it does the fact that I am routing this MIDI data from pd into another program for sound generation via the built in IAC MIDI bus on OS X. When I have time I'll give midi patchbay a try.

Thanks so much for your insight!

Definitely try Midi Patchbay. IAC has had lots of issues and I usually just keep it disabled when using the mac. It's particularly bad on my mac setup since it's completely out of date -- I'm mostly on linux and don't use the mac for much besides routing network midi through the mac-connected midi interface. Midi Patchbay will do anything IAC will do and more -- probably better

@NoDSP said:

It is possible that Pd's midi input buffer is being flooded,

I got weird "warning: FIFO overflow" messages in the console, so that's probably what that means?

In any case I just wanted to report back and say that MIDI Patchbay is amazing and solved my problem. Thanks!

Glad to hear it. Thought that would help. Pd Mac and Windows midi implementation is really an unfinished hack ATM (hopefully that will change in the next version, thou linux is ok) and It's often necessary to use some third party app to get around the current limitations, but I always cringe when anybody recommends using IAC.

I can't say for sure if the A.S. stuff was causing the FIFO error, but yes, it would seem likely.