[Brian McCully]

ORIGINAL: grandaddy

I’m not a mac user but a couple of questions –

Do you have may effects enabled in the mixer?…that can increase CPU hit

Have you tried running the MIDI out on your TD-3 into the MIDI in on your TD-10? (make sure you have soft thru selected) I’m sure this wouldn’t have a huge impact but it would mean something else not running and maybe worth a try

Finally got to re-hook things up today, so that TD-3 was running soft thru. The TD-10 manual states:
“If this setting is not used, leave it “OFF” as the trigger response
of the pads will be faster.”
I was testing out my MacBook to compare to my G5 and didn’t have my MAX merger patch on the MacBook, so I figured I’d try this out regardless of Roland’s suggestion. The TD-10 output seemed to work ok, no added delay. I’m still feeling out the general overall quality of the response through the MacBook, but the latency issue seems to be better than with the G5. I tried a 256 setting and it even seemed somewhat snappy in response (unlike the G5). Need to try out some more things before figuring out whether the G5 needs a different or reduced role as something other than ‘the dedicated Toontrack machine’.

(also) Using TTS v1.1.2, S2.1, Jazz, Latin Percussion, Twisted
MacBook Intel Core 2 Duo OS 10.4.11, 2.16 GHz, 2GB RAM
TD-10 and TD-3 E-Drum triggering

[Brian McCully]

ORIGINAL: John

OK,

personally I’m using a Digidesign 96 I/O Audio interface and a USB MIDI interface/keyboard connected to my TD-12.
I have it set at 64 samples in Toontrack solo and load pretty big kits (2-3GB) and to me it’s quite playable and I do not get pops.
This is in OS 10.5.6 on a 4 Core Mac Pro with 8GB RAM.

Best Regards,
John

Seems that you’ve got a newer system that is more in line with what is required to get this application to work properly for E-drums. And G’daddy’s. I re-checked the listed system requirements for S2.0 and a minimum ‘dual G4 1.25GHz’ would probably be sufficient for playback only, maybe. That’s what I was using for EZ Drummer. While the recommended system states a ‘modern G5’, I think it’s going to be borderline – like in my case – for live triggering. I -think- I have plenty of RAM installed, but the answer so far is there’s no answer, as ‘systems’ are too variable, i.e. too many possibilities of hardware or software conflicts, etc. But I’m running it bare-bones. Quite possibly TT may want to re-consider or hone what the recommendations are (maybe they are posted elsewhere for TTSolo and live performance…), and address the TTSolo feature set, to allow for some system performance monitoring, which is a standard DAW feature (like a gas gauge on a car). And/or hopefully help me figure out why a stock 2.3GHz G5 can’t handle the performance. Bench tests? -Brian

[Brian McCully]

ORIGINAL: John
I’d check 2 things besides what’s been suggested:
1) your Audio/MIDI device driver, it may need updating
2) turn LOCAL=OFF in your module

Running @ 64 samples gets you a latency of 1,45 ms in TT solo(not considering the module’s latency and your D/A converters)
Running @ 128 samples will only add another 1,25 ms (totals=2,7 ms), which seems hard to imagine it should count as considerably sluggish compared to the former setting.

For comparison I switched from using the RME card to using a firewire MOTU 828 interface, plus updating all of the MOTU drivers. Still get the same results.
Latency settings: 128 is playable, 64 is better and tighter, but not usable for the occasional clicks/pops. 256 is barely usable for real time (I wouldn’t attempt this normally – I was just trying it) and 512 is definitely unusable, basically a slapback (and sanity check). Using the Apple Utility’s Activity Monitor I did notice about a 5% (maybe 10%) CPU usage decrease when I toggled off the Mix window meters and visual ‘hit’s in the Construct window. I have a Intel dual core MacBook that I will try soon with the VDrums and 828 – it’s about the same speed as the G5 (2.2.GHz), but it’s limited to 2GB max of RAM. I loaded up a full S2.1 kit with it and it seemed ok just mousing around.

[Brian McCully]

There’s no wireless. This G5 is off-line, not connected. Not even on a hub or router. No Airport, bluetooth, etc.
If I need to update the machine, I’ll stick the ethernet cable into it every once in a while. thanks,-Brian

[Brian McCully]

ORIGINAL: John

Hi,

I’d check 2 things besides what’s been suggested:
1) your Audio/MIDI device driver, it may need updating
2) turn LOCAL=OFF in your module

Running @ 64 samples gets you a latency of 1,45 ms in TT solo(not considering the module’s latency and your D/A converters)
Running @ 128 samples will only add another 1,25 ms (totals=2,7 ms), which seems hard to imagine it should count as considerably sluggish compared to the former setting.

Best Regards,
John

Yes – I did those checklist items. And I’m sure that your math makes sense, and I know that a couple of milliseconds don’t make a difference (below a detectable level) – but…I know for a fact that changing between 64 and 128 is a definite feel difference. I’ve been trying to convince myself otherwise, but…no luck so far in what I perceive. I wish it was my imagination and not this software/hardware combo. -Brian

[Brian McCully]

Let’s try to answer your question another way. what you perceive as latency is the time for a number of distinct processes to occur, from the ‘trigger to midi conversion’ in the module, the MIDI interfacing part, the audio processing inside Superior and finally output to sound card by solo. The buffer size inside solo only affects what happens after the MIDI reaches the program.

If you are significantly affected by the latency at a low buffer value then the issue must be before it even reaches solo. If you have tried to take the MIDI processing that sits, in software, in front of solo then your problem may be at your MIDI interface level. Have you tried turning your module(s) to ‘local off’ to minimize latency in front of your interface? update your MIDI drivers?

Regardless, I think that you should try to look for the issue in any background processes that may interfere with the audio processing first and foremost (hence my suggestion to discard the MAX processing). Turn off Airport and disable Bluetooth. These are known causes for CPU hangs and perhaps are what you are experiencing.

Thanks for all of the suggestions from everybody.
Since the buffer size inside solo only affects what happens after the MIDI reaches the program, and I know that 64 is fine and 128 is spongey, then it’s inside of TTSolo that is at question. If I could play at 64 with no clicks or pops (with a full kit loaded), I’d be ace. Anyway, I tried a number of things – I updated the system to OSX10.4.11, made sure the RME 9652 card driver was the latest, made sure that system prefs Energy Savings was for ‘Highest’ processer speed (it was), tried both TD-10 and TD-3 modules with Local off, and Airport and Bluetooth are long ago turned off (they were, although bluetooth doesn’t exist on this Mac). Still the same results, so far.

[Brian McCully]

The extra articulations will just take up more RAM and not have an impact on CPU.  Disabling bleeds will decrease CPU use. 

There would be no way of determining how much is too much….it’s very much dependent on the audio hardware / drivers and the system they’re installed in….plus any other stuff that may be running in the background….hardware conflicts etc. etc.

I have a dual core PC with 4gb Ram and RME 9632 card and can play my TD-12 live with a 3gb kit loaded ( all bleeds selected ) at the lowest 32 sample buffer setting with no clicks or pops whatsoever.

Most DAWs have a CPU ‘usage gauge’. TTSolo doesn’t. I did not see any CPU spikes register in the Activity Monitor application.
I’m using the RME 9652 card (2nd generation). I don’t know if it’s possible to set it to 32 samples – there is no menu selection for that low of a setting in its software, and Digital Performer only allows a lowest setting of 64 via this card (not sure about Logic or Cubase). But 64 in TTSolo seems to work for me for a latency setting. 128 seems to be ‘spongey’ for lack of a better term – it’s playable but not squeaky tight. Definitely a difference between the two settings, all else being the same.
It’s pretty amazing that you can load up all of 3GB of drum sounds, set latency to 32 and have no glitches…is everybody else experiencing this?

[Brian McCully]

ORIGINAL: Rogue

I think the first thing I would check is whether your MAX-DSP based MIDI driver play any part in your issue

I can assign just the TD-10 as the MIDI input (it is the trigger for most of the pads) in TTSolo and not use MAX, resulting in no difference in latency – i.e. there is latency at 128 regardless of whether the MAX patcher is involved or not. There is no latency at 64 (using MAX or not). Does the Latency setting affect MIDI triggering – I thought it was a sample related setting?

I also do not quite understand the ‘non trivial’ assessment – any host sequencer DAW will perform MIDI merging – and there is much more CPU headroom loss associated with booting a Cubase or DP or Logic, etc. than a simple MAX patcher. Is it recommended that users do not use a DAW/Sequencer to play S2.1 live?
I was only using TTSolo for just this reason.

Adding a hardware merger will definitely introduce latency. I have them, have used them. They definitely slow things down and also do not always work properly, depending on the type of data put through them. I’d rather avoid one more thing in line anyway.

Back to my original questions…
Is there an actual visual and quantifiable method of determining how much is too much, before the clicks and pops start?
Secondly, what is the exact suggested order to turning things off – to stop the clicks? Bleed, first? Less Articulations?

[Brian McCully]

ORIGINAL: grandaddy
Do you have may effects enabled in the mixer?…that can increase CPU hit

Have you tried running the MIDI out on your TD-3 into the MIDI in on your TD-10? (make sure you have soft thru selected) I’m sure this wouldn’t have a huge impact but it would mean something else not running and maybe worth a try

I have no effects enabled. Just using the default full kit as a testing ground while I try to figure it all out.
The MAX app only takes 1-2% of the CPU, which is a lot less overhead than booting a sequencer to host S2.1. It’s a very simple merge patch. I haven’t tried patching a soft thru – I’ll have to investigate whether the TD-3 output triggers anything in the TD-10 that I don’t want triggered (trying not to have overlapping midi note maps that work easily with S2.1 has been a royal pain to set up), as I’m using the TD-10’s 8 outputs and TD-3’s stereo audio as well, mixing it with the S2.1 output (via ADAT optical) to a separate console for 5.1 type monitoring – VDrums just sound a lot better when playing them in surround.

[Author]

Replies