PowerPC vs Intel Stand-alone Build Issue
I have a mono sample-playback patch that has been built as a stand-alone application. I am observing a curious performance phenomenon between it's performance on my PowerPC and (Mac) Intel machines.
My patch needs to change samples very rapidly and precisely according to incoming data. Specifically, incoming MIDI notes are held (in the patch) until the next note enters. The desired effect is a continuous sound.
On my ancient PowerPC Dual 1.8GHz G5, it works very well. (Tip o' the hat to the Max engineers!)
On my two Intel Mac Laptops, there are very short (silent) gaps between the notes. I can't hear them, but all the trained musicians I'm working with can.
Does anyone please have any thoughts on this?
Specs: All machines are running 10.5.5 with sufficient RAM and identical Firewire audio/midi interfaces. (I tried a different MIDI interface and built-in audio on the Intel machines; there was no difference.) In the patch, Overdrive with interrupts is on (though I tried combos); vector sizes are set to 128. (Are these settings all carried over into the built app?)
Below is the patch; it will not produce sound without its samples. I'm guessing, though, that folks (if so inclined) would simply want to look at the patch. (Please let me know if otherwise.)
As always, thank you for your consideration.
Bill
It looks like you have one groove~ object and you're trying to change the buffer~ that it references in order to change the sound that it's playing. This is really not the best way to go about it. I can't speak to why this works well on a G5 and not on an Intel, but there are other ways to do it that will guarantee that it will work on any machine.
I would suggest having two groove~ objects. One of them will be playing the current sample. The other one will have the next sample already pre-loaded. When you get the midi event trigger, you simply crossfade between them, and pre-load the next sample into the inactive groove~ object. It'll take a little more logic to facilitate the toggling back and forth, but it shouldn't be that hard.
Perhaps an even easier way (although probably not the most CPU-efficient) would be to have a separate groove~ object for every buffer. It doesn't look like you have that many buffers in your patch, so this should be feasible. Then, instead of having to tell the groove~ object to switch buffers mid-stream, you'd just have to trigger the correct groove~ object to start playing, and tell the last one to stop playing.
Thank you for your reply.
I tried the buffer crossfading a while back. It appeared that the musicians could play faster than I could crossfade in my patch. I tried several algorithms to no avail. In particular, the gswitch seemed to go nuts, appearing to switch randomly when operating at high speed. There certainly may be a workable way that I did not try, but I moved on. (As I recall, Chris Muir advised me not to use the gswitch, though I can't be certain.)
I haven't tried your other suggestion, though. It sounds brilliant! I love this forum!
Thank you,
Bill