Multi-Timbral Synths?

[ensconced]

7 hours ago, abacab said:

Well duh! Cakewalk went out of business in November 2017. Those products are no longer for sale.

https://help.cakewalk.com/hc/en-us/articles/360021858293-What-happened-to-Cakewalk-SONAR-What-happens-to-everything-I-paid-for-

 

No 'swoosh' for you then

He might get it now.

[JoeGBradford]

I wouldn't be too sure ?

[Skyline_UK]

On 1/28/2020 at 4:29 PM, msmcleod said:

If a VSTi supports multi-threading, it means can use all of the CPU's cores. The majority of VSTi's do not support multiple cores (i.e. they'll just use the one).

Cakewalk's plugin load balancing won't help here, as it only applies to VST effects.

If you've got  the Performance module enabled in the control bar, and the first core is showing much more activity than the others then its a good indication that your VSTi's (or at least some of them) aren't able to use more than one core.

To get around this you can use multiple instances of the VSTi - e.g. for a 16 part piece on a 4 core CPU, use 4 instances where the first instance uses parts 1-4, then second instance 5-8 etc. This should more evenly spread the load across your CPU cores.

 

That's exactly what I discovered yesterday with Sample Tank 3.  For years I've used SampleTank 3 by loading one instance of it and directing all my MIDI tracks to it, loading samples across as many slots in ST3 that I need and directing all my MIDI tracks outputs to that single instance.  I recently replaced my 9-years old PC with the powerful spec shown in my signature and was disappointed that the latency performance is lower than that in my old clunker PC.  Did I perhaps shoot myself in the foot by buying a 14-core to replace my 8-core?  

Using SampleTank 3 as described above to provide sounds for 14 MIDI tracks I have to set my RME Aio PCie interface sample rate to 2048 or above - precluding the use of a guitar processor plugin.  Noel on the Jan release thread has told me that the best way of using SampleTank 3 is to load multiple instances of it, which seems counter intuitive given ST3 is multi channel/multi timbral, but that works.  With 14 MIDI tracks spread across samples loaded in four instances of ST3 I can go to 256 samples with no crackling.

Is the 'fault' with ST3?  Should it support muiltiprocessing?  (Thinks...does SampleTank 4 support it?)  Do any multi timbral samplers support it?  Why can't DAWs handle all multiprocessing?

PS: I found on the Studio One FAQs a support comment that says it's best to keep sampler libraries on a disk drive other than the OS or the one where the DAW software is, as loading of samples will be faster.  Is that the case with Cakewalk?

   

[msmcleod]

2 hours ago, Skyline_UK said:

That's exactly what I discovered yesterday with Sample Tank 3.  For years I've used SampleTank 3 by loading one instance of it and directing all my MIDI tracks to it, loading samples across as many slots in ST3 that I need and directing all my MIDI tracks outputs to that single instance.  I recently replaced my 9-years old PC with the powerful spec shown in my signature and was disappointed that the latency performance is lower than that in my old clunker PC.  Did I perhaps shoot myself in the foot by buying a 14-core to replace my 8-core?  

  

Probably not, unless the core CPU frequency on your 14 core is slower than what you had on your 8 core.  But even then, you'll get much better performance using effects - it's just VSTi's that can only run on one core that will be affected.

2 hours ago, Skyline_UK said:

Is the 'fault' with ST3?  Should it support muiltiprocessing?  (Thinks...does SampleTank 4 support it?)  Do any multi timbral samplers support it?  Why can't DAWs handle all multiprocessing?

Yes, the fault is with ST3. And from what I've read, ST4 is no different. Do a google search for "SampleTank multi core" and you'll see plenty of posts on forums from users of other DAWs complaining about exactly the same issue you have. From what I gather though, this only affects the VST version - running it standalone seems to work much better.

2 hours ago, Skyline_UK said:

One FAQs a support comment that says it's best to keep sampler libraries on a disk drive other than the OS or the one where the DAW software is, as loading of samples will be faster.  Is that the case with Cakewalk?   

This is a general recommendation for any sampler, so it holds true for Cakewalk as well. When streaming samples, the sampler needs to be able to read the data as seamlessly as possible. Because the OS drive is constantly being used by other processes, having your samples on your OS drive can interrupt the streaming process. This situation is much worse on a traditional HDD, and worse still if the data is fragmented, as the disk head has to physically move from one location to another.

[Noel Borthwick]

On 1/29/2020 at 12:28 AM, bvideo said:

Useful info here!

But just to clear up my understanding about scheduling VSTi's?

Normally there's just one VSTi serving any audio (synth) track. That is to say, the "synth rack" for that track  only has one item in it, not a stack. This is clearly different from the case where an FX rack with multiple audio effects serves a single track (or bus). My understanding of plugin load balancing is that each audio effect in such a rack could get a thread simultaneously. That per track concept of load servicing does not even apply to synths.

Your last paragraph implies a slightly different concept for synths; it doesn't sound like there is anything preventing running simultaneous threads on individual synths in the synth rack (it's global). In this sense, doesn't it make sense to say there is load balancing among the synths in the synth rack (and there probably always has been)? In this view,  for a synth instance that has multiple parts, a single thread has to serve all the parts, even if the parts are directed to separate audio tracks (i.e. for the majority of VSTis, not supporting multithreading). Are there situations where Cakewalk would do multithreading to a VSTi that supports it?

That would clear up most of my question (post 5?) about "overhead" of stacking synths. RAM is another part of the equation. For a VSTi that can support multiple ins & outs, how much difference in RAM does it take for multiple instances each with a single voice vs. a single instance with multiple voices. The code part should be shared. For a sampler, if samples can be shared between instances, I imagine there is relatively not a whole lot of difference. But how about for a synth like TTS-1? Does it wind up using a lot more memory for multiple instances?

@bvideoYou can read more about our patented plug-in load balancing here. A fundamental requirement of load balancing is for there to be 2 or more serial plugins that can be processed in parallel. Synths in the synth rack are SOURCES. The synth audio processing must take place individually for each synth before any further signal processing in the downstream circuit is performed. i.e. synths get fed MIDI data not audio and produce audio which is then sent to the tracks sourced by the synth. Its no different from recording audio or input monitoring in that regard. So load balancing doesn't apply here.

Any parallel processing for synths has to be done within the synth itself by parallelizing the processing of its voices. This cannot be done by the host since it requires the plug-in vendor to do this. Its a double edged sword even for the plug-ins that attempt to do this however, since the threads in the plug-in start to compete with the DAW's threads and this can lead to other performance problems. I had a proposal many years ago to solve this problem but it requires cooperation with plug-in vendors to implement.

For now the best way to do this if the synth doesnt support parallel processing internally is to have per channel instances of the synth and make one instrument track per channel. This way the DAW will manage the parallel processing since each synth voice will be farmed out to its own core. Of course this is a trade off between RAM and CPU performance because inserting multiple instances can take more memory depending on what samples are loaded etc. Hopefully the synth vendor internally optimizes this and shares samples between multiple instances of the synth. For TTS1 the extra memory would be negligible. TTS1 is pretty lightweight so I don't think it would be necessary to split into multiple instances typically.

 

[Skyline_UK]

Thanks again Noel.

I've just done the following which bears out what you say, and my incorrect use in the past of SampleTank 3!

 I  changed the Thread Scheduling Model settings, the results of which may or may not be useful to you.

 

The song at the moment consists of 15 tracks as follows:

1 - MIDI Drums  via Addictive Drums 2

1 - MIDI Strings via Halion Sonic

1 -  MIDI RealGuitar

1 - Audio 

11  - Other instruments via SampleTank 3  loaded   11 times, one channel for each MIDI track.

"System Memory Usage  29.2% (80%)"

 

Thread Scheduling Model : 2 

(1)  At  256 samples: no crackling.   Engine Load c.54.7%.  Late Buffers 0

(2) At 128 samples:   no crackling. Engine Load c.83%. Late Buffers 0

(3) At 64 samples:  a crackle or two every 15  seconds or so. Engine Load c.123%. Late Buffers   about 200 in the first minute.  About 160 if audio FX turned off (only some Pro Channel EQ on the single audio  track).

 

Thread Scheduling Model changed to  3 'Aggressive'.  CW exited and restarted.

(4) At 128    samples:  continuous crackling, Engine  Load different for different plays, but starts at c.112%, climbs to c.126% .     Late Buffers   about 120 in the first minute. 

 

Thread Scheduling Model changed to  1  'Legacy wait for single object'.  CW exited and restarted.

(5) At 128 samples:   no crackling. Engine Load c.89%. Late Buffers 0.  

(6) At 64 samples:  almost continuous crackling. Engine Load varied on different plays, c.117% then 143%. Late Buffers   about 200 in the first minute.  

 

Thread Scheduling Model changed to   0 'Legacy spin'.   CW exited and restarted.

(7) At 128 samples:   no crackling. Engine Load climbed from beginning of   the song from c.70% to stabilise at 95%. Late Buffers 0.  

(8) At 64 samples:  occasional  crackling. Engine Load c.132%. Late Buffers   about 275    in the first minute.  

 

Thread Scheduling Model  2 seems best for me.

 

Edited February 1, 2020 by Skyline_UK

[Jim Fogle]

@Skyline_UK, Thanks for detailing your test and posting your test results.  Excellent work and nice information for all interested users as well as the developers.