on the last gig I had some peaks which were just related to the very first note. After some investigation I found out that it’s the u-he DIVA that causes that issue.
I can reproduce it anytime. I tried to switch on / off the multicore-settings in DIVA and Cantabile. I tried switching Cantabile to aggressive-mode. But nothing helps. I than tried to set the sample buffer to 512 (instead of 128). The peaks are still there, but won’t exceed 100% anymore so not audible. The preset is set to “draft”-mode.
The strange thing is, that it is just the very first note. After that I can play what ever I want… it stays way below 20%.
I use a skull canyon. Turbo boost is switched off and of course it’s glitch-free-configured (core-parking, power-saving-tweaks, and so on). The interface is a babyface pro.
Do I have to live with that or is there any kind of work around?!
create a Song->OnLoad binding to set Diva output level to 0
next Song->OnLoad bindings to send a note-on and corresponding note-off to Diva
then another Song->OnLoad binding (maybe with some delay to account for the sound tail) to bring Diva volume back up
Now your song will play a (silent) note on Diva when you load it, so by the time you play your first “real” note, your CPU load should be where it is supposed to be.
I’ve done similar things where a synth needed some setting up before I get to play my first note (example: a synth with a slow portamento that, without “priming” it first, would start where I don’t want it).
I know, this is a pretty crude brute-force workaround, but at least you’ll not get a glitch on your first note anymore
This really sounds crude. Anyway: I tried it but I can not get it working because I think the delays are not working correctly @brad.
I created two Rack OnLoad Bindings. The first one mutes the output-route of the DIVA. The second one sends a note to the DIVA like you explained. If I add a delay for the second binding, Cantabile simply ignores it and fires both bindings at the same time. I used 2000ms to have an audible and visible delay. The problem is, that you still hear the note that is fired by the second binding. I’d expect that Cantabile waits 2 seconds before firing the second binding / note…
I also tried adding a delay after the first binding is executed without any success…
I’ve had a look at this and believe it’s working correctly however there’s a couple of catches:
The activity indicator on the binding slot lights up when then binding is initially triggered - not when the target is invoked. You can confirm this by bringing up a MIDI monitor on diva and watching the note on/off events.
There’s a limitation in that while Cantabile is processing load event triggers, it suspends most user-interface interactivity. This is to prevent going re-entrant and allowing for starting another operation before this one is finished. The side effect is that enabled check box on the route that you’re enabling/disabling is not being redrawn until after all bindings have fired - ie: once the last binding turns it back on. So even though the route is being disabled and then re-enabled, you’re just not seeing it onscreen.
For point 2 - I’ve made a fix for this for 3502 that will allow repaint operations to happen during the load. I’m a bit reluctant about retrofitting this fix to 32xx because I want to keep that series as stable as possible now.
As for the original problem with note too loud - I’m not seeing that with the rack you sent me. First and subsequent notes all sound the same.
thanks for looking into this.
So you say that the route is muted although I do not see it on the screen. Is that right?
The rack that I uploaded should do the following:
1.) Mute the output route of diva (which I do not see)
2.) wait 2s and fire a note on to the diva
2s should be enough time for Cantabile so that I don’t hear anything from the diva. But I actually hear the attack of the note. I made a short video where you can see the output-meter peaking for a short amount of time when the NoteOn is fired. And this is what I do not understand. To me it looks like Cantabile waits 2 seconds, than mutes the route and fire the note at the same time.
And yes, the first note is not louder than all other notes.
//edit: I just wanted to try it out on 3502 on another computer which is Mac running Parallels. Cantabile 3502 crashes on start while 3278 worked perfectly fine for testing purposes.
OK, I think I can see what’s happening here. The problem is that enabling a route is a fairly involved process which starts an internal re-route batch which in turn might need to wait for other pending triggers to complete. This is an area I need to revisit at some point but right now I’m reluctant to touch.
For the moment, instead of disabling the route, adjusting its gain works better:
I think you get me wrong. I never said that the first note is too loud. Also in the quote you made I said that it’s not the case With peak I meant CPU spikes. Sorry for not being clear here.
I contacted u-he today and received a reply within 10min! They suggested to test the new beta and it seems that this solved the original problem. I’ll still need to investigate more on this. But for now Diva seems working okay.
GENIUS! I can use that! And it solves an issue I have with a little free ARP Pro-Soloist VST that has a bug on load that always messes up the first note I play.
That’s the kind of trick that would be good in a dedicated “Tips and Tricks” thread.
(Sorry it didn’t actually fix the original issue though).
meanwhile I added the method which Torsten & Brad suggested to my DIVA-rack.
Anyway: It looks like I have similar issues with some other plugins f.e. XPand!2. I’ll do some more tests and I’ll report back.
//edit: The guy from u-He told me that it sounds like not all cores are running and they will get activated on the first note. That’s why the CPU-peak (which is not a CPU-Peak because I talk about the % in Cantabile) happens. But I followed Brads advices from Glitch Free… I deactivated core-parking and set minimal performance to 100%, high performance-scheme, I tried different settings with hyperthreading enabled / disabled, I enabled / disabled turbo boost, but all of that doesn’t change a thing.
Maybe I forgot something?
As a test could you try disabling Cantabile’s multi-threading support and let me know if that makes a difference: ie: Options -> Audio Engine -> Number of Audio Threads -> “1 - Disabled” .
Also, could you try recording it with Cantabile’s recorder and see if the artefacts show up in the recording too.
I followed up on this today. But I need to say that I upgraded my system from an Intel Skull Canyon to an i7 7700k-core, which is a lot faster (almost double the speed).
I still have those peaks on first note… not only with DIVA, also with M1, sometimes with Blue3. I’m not able to figure out, on what this depends.
Let’s stay with the DIVA for now: When I boot my computer, load up Cantabile, load a single DIVA-instance and play a note the CPU-% in Cantabile rises up to 50-150%. Also here I can not figure out why it sometimes keep below 100% and sometimes goes above. When it goes above 100% I hear a “click” in the audio (also in the recording). After the first note (but continuing playing), the CPU-% goes down to 10-15% depending on the patch selected in DIVA. After that the peak never occurs again for this rack in this song.
This is weird. I again checked with another host (Brainspawn Forte). I don’t have those hearable clicks there. DIVA performs well with no dropouts. So it looks it’s something related to Cantabile…
I checked again my settings, core parking is disabled. The cores are running on 4,4GHz at any time. Intel SpeedStep is disabled in BIOS, Turbo boost is enabled, but disabling it, doesn’t change anything.
I’d really like to get rid of those peaks… but I don’t know what I can do or how I can help @brad to figure it out…
What audio interface do you use?? If you have a problem across two totally different systems that most people don’t seem to have, it seems to me the common factor in your case is your interface (even if it is also somehow related to interacting with Cantabile). And probably the accompanying driver. Maybe switch to ASIO4ALL temporarily and see if it has an effect?? I could be way off-base but, worth a try.
I use a Babyface Pro.
I can try with another driver like ASIO4All but since I use Forte with the same interface I’m not sure if this makes any difference. I’ll report back!
