wevans@elec.gla.ac.uk

I have made a relatively simple Max 5 patch that plays back sample buffers (monophonically) according to incoming MIDI notes. The response from a MIDI controller is too slow, though. Roughly, I'm about 10-20ms behind.

Can someone please suggest how I might increase the performance?

My settings: IO and Signal Vector sizes are set to 128. (The audio interface is a Mac-based Firewire device, so the buffer size is set from Max.) The samples are 150 MB total, and fit in RAM. Dual 1.8 G5; 2.5 GB RAM; Leopard and Max 5 (latest versions).

Given that I am simply playing back small, monophonic RAM-based samples, I don't see any way to make this faster.

Below is a VERY simple version of the patch. Most of the original has been removed; this is the basic algorithm for playback:

(The stuff in the left-hand corner is just for getting the buffer names.)

faster-realtime-midi-sample-triggering

You can tighten the responsiveness of Max by opening the DSP Status panel and trying:

For good measure you might drop your Signal Vector to 64

Try making a latency measurement patcher by converting raw MIDI bytes to audio clicks so you can isolate the problem (hardware, max setup, your code).

I can't look at your patch as I'm still using 4.6. But instinctually when you said Mono, I wondered if there was a envelope fade time to kill previous notes before bringing new notes to full volume. This would add a few ms.

Interfaces like the Echo AudioFire series have undocumented safety buffers (in the audio driver) that increases the latency by ~5ms.

WiFi should be adopted by all hardware manufacturers with OSC as the transport protocol. That'd get us past this silly MIDI stuff.

In the meantime good luck. You can easily get good performance out of Max.

Max Scheduler in Overdrive (On)
Schedular in Audio Interrupt (On)

Interfaces like the Echo AudioFire series have undocumented safety buffers (in the audio driver) that increases the latency by ~5ms.  

WiFi should be adopted by all hardware manufacturers with OSC as the transport protocol. That'd get us past this silly MIDI stuff.  

Sorry I still don't have Max 5 so I can't open your patch.

Just one silly thing: have you cut the silence at the beginning of the audio files that you use in your sampler? If you are on Windows, the "Silence Remover" software is great for doing this:

(On OS X, I didn't find any equivalent freeware).

Just one silly thing: have you cut the silence at the beginning of the audio files that you use in your sampler? If you are on Windows, the "Silence Remover" software is great for doing this:
http://www.noisetime.com/silrem.html

Hello, thank you for taking the time to consider this issue.

I've got Overdrive on, and tried the other setting both ways. I didn't seem to notice any difference. My patch is very simple; my instinct is that these settings (based on threads) would have no bearing in my case.

> For good measure you might drop your Signal Vector to 64

Anything below 128 is bad news for my test machines...I think a buffer size of 256 should fine, based on other instruments. Perhaps I really don't know...

> Try making a latency measurement patcher by converting raw MIDI bytes to audio clicks so you can isolate the problem (hardware, max setup, your code).

That's a cool idea; thanks. The hardware turned out not to be an issue; about 3ms. In terms of my patch, I can't foresee any faster algorithm for triggering samples in Max. Nor can I think of any possible changes to the Max environment.

> I can't look at your patch as I'm still using 4.6. But instinctually when you said Mono, I wondered if there was a envelope fade time to kill previous notes before bringing new notes to full volume. This would add a few ms.

Very true - I had a 1ms LINE ramp. In the patch I posted, though, I even eliminated that, and the latency is still too high.

> Interfaces like the Echo AudioFire series have undocumented safety buffers (in the audio driver) that increases the latency by ~5ms.

That interesting...never heard of that, but it's obviously true. (I used to write audio drivers for commercial audio interfaces.) The Presonus doesn't have a feature, though you can enable one in Logic, oddly enough. Thanks for the heads up on this; it certainly may be a tech support issue I will have to deal with.

> WiFi should be adopted by all hardware manufacturers with OSC as the transport protocol. That'd get us past this silly MIDI stuff.

Agreed...I had high hopes for MLAN, but that seems like ages ago...

> have you cut the silence at the beginning of the audio files

Indeed, though this is certainly the sort of thing that one can forget in the midst of looking for high-tech problems.

> You can easily get good performance out of Max.

I thought so...hopefully I don't know what I'm doing. :)

> Max Scheduler in Overdrive (On)
> Schedular in Audio Interrupt (On)

RESOLVED: I removed these things from patch:

2) Sample playback rates other than 1 (sig object).

3) Pass-through of signal through Tap.Tool's shift object. (I did not modulate the tuning.)

PS: Regardless of any issues I heartily recommend the Tap.Tools objects; I can't imagine making patches without them.

1) All send & receive objects.
2) Sample playback rates other than 1 (sig object).
3) Pass-through of signal through Tap.Tool's shift object. (I did not modulate the tuning.)

PS: Regardless of any issues I heartily recommend the Tap.Tools objects; I can't imagine making patches without them.


Faster Realtime MIDI Sample Triggering?