MIDI Filter based on dynamic list of MIDI CC# values?

that looks pretty benign to me. Is the stuff from the receives changing often? Is there anything else that might be causing the cpu spikes?

zl.rev -> route

Roman:

I original used zl.rev--> routepass (and also route) but had issues.

Routepass had an issue with an incoming MIDI CC message of "0 0". In testing, after receiving that "0 0" input, routepass would freeze for 4-5 seconds on the next input and then work properly. More significantly, route/routepass will route multiple places at the same time potentially yielding double MIDI outputs. For example, "match value 1" is 22 and "match value 2" is also 22. In such an instance routepass would pass through the value of 22 to midiout twice—once for "match value 1" and again for "match value 2".

I could not figure out how to thin a dynamic input list for route or routepass.

Is that possible?

Thanks,
Mike

Tyler,

I tested the patch independently from the larger device and by itself works fine. The patch increases CPU utilization by roughly 2%.

The issue is using multiple instances on a track. I typically use 13 instances on a track and CPU use is up around 30%. With multiple instances, device 1 extracts the MIDI CC#, matches it against the filer list, then outputs the filtered list to device #2....which extracts the MIDI CC#, matches it against a different filter list, then outputs to devices 3, etc. With 13 devices it does this 13 times for each MIDI CC received.

I thought my approach would be light enough to handle multiple instances, but from what I’m seeing perhaps not. I’m not very familiar with Max’s ability to generate efficient low-level code (in terms of CPU utilization), as I am a first time Max developer.

The receive objects don't change often at all, but the MIDI input the device is filtering does change quote often—especially when the MIDI CC is manipulated by a slow running LFO (at 1hz).

If I can’t figure out how to make this algorithm lighter on the CPU, my only other choice is to put the filtering feature in a different device—which would ensure the filtering is only done once per MIDI CC input (instead of 13 times with the multiple devices).

As I write this I’m thinking it was a poor design decision to put the filtering in each device. Maybe I should just put it in a dedicated device….

Any thoughts?

Thanks,
Mike

how do you know that it is the routepass object that freezes when it receives controller #0?

there are a few other suspects involved, from the host to the receiving device, and i would bet the max object is innocent.

I too would suspect that such a simple Max object that has been around for a while would be innocent. Certainly could have been the multiple devices interacting in some unknown way in some other part of the patch. I suspect additional testing would have yielded a different culprit.

I don't think any object is light enough to handle what I'm asking it to do. When using an LFO at 1 hz , 1000 MIDI CC values per second hit the filtering algorithm in each device. With 13 devices on the track, the filtering algorithm is being trigger 13,000 times per second. At that rate, CPU usage could be in play regardless of what object I use for the filtering.

To that end I feel it best to put the algorithm in a separate device. By doing so I can constrain the filtering boundaries such that [split] can do the filter (which I suspect would be even faster than routepass) and limit the algorithm triggering to 1,000 timer per second.

Would you agree with the approach?

I would avoid cascading midi 13 times in first place.
you say 1 hz lfo produces 1000 non repeating midi values per second
what waveform does so with 0 - 127 midi range ?

Many thanks SourceAudio.

You're right my math was off.

A sine wave whose depth is set at 100% goes from 0 to 127 to 0 every second which is 128*2 (256) non repeating values every second. So this is even stranger to me than I originally thought. 30% CPU use (per ableton) filtering 256 values 13 times on a track seems very high (based on my coding experience in other languages like C and VB). But then again this is my first Max patch and maybe this is just how it is.

I think this issue is not my device. In testing I hooked up a simple preexisting 8 encoder device (CC8) to an LFO running at 1hz. Running alone on the track, the CC8 causes Ableton to display 5% cpu utilization. Adding 13 instances of the default Ableton max MIDI effect, which just has a [midiin]-->[midiout] in it, causes Ableton displays CPU utilization as 10-15%. It seems that just the act of passing MIDI through a device takes a certain amount of processing power.

I agree 13 devices cascaded devices is probably not ideal to say the least. This is a potential use case because the device is designed (primarily) for use with the Push which has a 8 encoder display (without the use of buttons that can page through the display). I'm controlling roughly 100 parameters on an external device through MIDI CC which mandates roughly 13 devices on a track.Each device can be controller with MIDI CC# which mandates some type of MIDI filtering so the correct MIDI CC control values can goto the place in thedevice.

I wound up creating dedicated device to do the filtering which dropped CPU utilization from 30% to 20% (in the LFO use case I described).

That last 20% seems to the result of using 13 devices on the track which pass through MIDI (see my above post). I plan on bypassing those 13 devices by sending MIDI CC to a device at the end of the device chain using send->receive objects. That last device will dump the received MIDI CC to the track. I hope then is "problem solved".

We'll see....