Can I use MidiFire to "explode" a Midi drumtrack on Auria?

Hi @david2,

Annoyed? No, not at all! That's all really helpful. First a couple of points:

1. I would disconnect the line between event monitor out and midifire in. That will result in the kick being doubled (assuming it was working, of course)

2. The event monitor (the part I can see) shows that only the kick events are coming from the Stream Byter, so we do know the filtering is working. Your rules look fine too. However, it would be worth checking that all pages of the events show only note C1 on and off events and nothing else. I'm pretty sure this will be the case but we should check.

Your shot of the setup for the armed track looks spot on; in theory, Auria should only be recording the events coming from the input you have selected, but I wonder if it actually is.

I think we should simplify things here and concentrate only on the kick to debug further:

- disconnect all lines in MidiFire coming from the MidiFire source to all the Stream Byters *except* the kick one
- record a source track with just a couple of kicks and say the snare (something other than the kick)
- send that source track to midifire and then create a new armed track with midifire as source (kick)
- record play and then examine the newly recorded track in detail.

Assuming both the kick and snare events are in it, are any of these events doubled up?

Now, in the kick Stream Byter rules, comment out the NX 24 = XX +C line, leaving just the XX +B line. This will block all events.

Do the record test again. There should be *no* events in the resultant track.

There must be something basic we are missing. The above two tests might assist in pinpointing where we need to look.

Regards, Nic.

Okay, so then I additionally connected the SNARE StreamByter to MidiFire1 (with an Event Monitor in between) and, after deleting the above-mentioned filtered Kick track that I’d previously recorded in Auria, recorded both the KICK and SNARE in respective tracks in Auria.

However, once again, both tracks, both the Kick track and the Snare track, recorded all events — no filtering occurred. The StreamByter for KICK showed all events for C only, while the StreamByter for Snare showed all events for D only.


I later recorded a new track (drummed again and recorded my playing in Auria) in which I hit all pads (all notes available on my drum set) and then I tried running that track through MidiFire and recording just Crash2 and the Ride simultaneously. No Event Monitors were used in MidiFire this time. In this case, filtering did occurr as only Crash2 and Ride were recorded (no events from other pads got recorded), but both tracks recorded all Crash2 and Ride events. The level meters moved identically in the two tracks and the resulting two recorded tracks were identical.

Going back, I disconnected the RIDE StreamByter and the associated MidiFire7 output port and was able to record just the Crash2 events in the Crash2 track, and then I went back once more, disconnected Crash2 in MidiFire, connected the Ride back up, went back to Auria and set that up to now record the Ride and not Crash2 and was able to successfully record the Ride events in a Ride track. In this manner, I went back and forth between the apps and recorded separate tracks for all 8 of my groups of pads (I’d really like 22 or so to get each available trigger a separate track).

So, I was able to dissolve the original MIDI track to separate tracks for each note (well, small groups of notes such as having both snare and snare rim in one group), but I had to do it manually. If I had a project of numerous 3 to 5 minute long songs with events spread through 20 notes (pad triggers) each, such method would take an inordinately long time

“One at a tie” = One at a TIME

So, then I re-did the test of also hooking up the SNARE StreamByter (plus an Event Monitor) and then trying to simultaneously record filtered Kick and Snare tracks in Auria.

Unfortunately, both tracks show all combined events (no filtering occurred in either of the resulting recorded tracks).

Going back to the MidiFire app and looking at the Event Monitor logs, I can see that the KICK StreamByter recorded only the appropriate ON and OFF C1 events (there were 4 kick hits in the test track, so 8 messages total), while the SNARE StreamByter recorded only the appropriate ON and OFF D1 events (there were 6 snare hits in the test track, so 12 messages total).

It seems MidiFire is filtering, but somewhere after the StreamByters the events are somehow getting recombined

"just reconfirm" = just TO reconfirm

Okay, I’ll look into how to contact Rim