No, that’s part of the de-clicking algorithm actually. This is a pretty nice implementation that adds just a little bit of latency to remove all nasty clicks from re-triggering or stealing voices etc, while also retaining the response of the sound in its entirety. Other de-clicking algorithms often have a negative impact on the sound whereas this one is completely non-destructive, but requires a short window of latency.
I think 64 samples should be quite negligible for Live setups, it’s way less than just what MIDI adds for example. In 48Khz samplerate this adds 1.333ms of latency which is the same as standing ~35cm away from a guitar amp, so I’m confident that this shouldn’t pose any issues in practice.
But if this is detrimental to your workflow I’m all ears to hear why and I can think about some options!
(If it’s a problem with latency compensation then you can just switch that off, the notes will land 64 samples later but this is in a lot of cases not noticeable depending on the type of sound etc.)
Thanks for your quick reply! I agree that 64 samples is not too bad but the latency all adds up from other sources as well. And it wouldn’t be as crucial if my setup was synths only but I play live violin as well and I really need low latency monitoring to play violin well. Violin is such a fragile instrument because the pitch is adjusted by my ears so I really want to optimise all possible latency.
If there’s no much to do for the latency I guess I just need to weigh my options and maybe opt for different synth for this use case. I guess the de-clicking algorithm is nice as well but would prefer to have an option to turn it off for even low latency. Not sure if it’s easy to implement though and would the usability of the synth suffer too much.
But is it the overall latency for the project that adds up, say in your DAW, or are there other factors?
It’s not hard to add an option for the de-clicking but it really wouldn’t sound very nice unless you use a lot of voices and are a bit diligent with how they are triggered.
There’s also the alternative to add the option to not report the latency to the host, but I’m pretty sure you can switch that off for each plugin individually, right? Thinking in the use case of not affecting the low latency monitoring.
Is there a way to access the Opal CTL sequencer parameters? Maybe creating a router/bridge from OSC to max4live, and modify the opal ctl file to receive these messages? That’s what vibecoding told me xd
Would it be possible to make some sort of mappable randomize buttons? In Ableton, when you press Configure on the device window and try to map the Dice, you get all the parameters that the die affects – would be nice to have one target for MIDI that then randomizes all the parameters.
Not currently, no.
That’s one way to do it, but it’s a pretty involved process.
Possibly via MIDI mapping. Automatable parameters that directly control other parameters is a bit of a no-no for plugins, can wreak a lot of havoc.
I’m curious though, this comes up pretty often – but why is it desirable to automate or map to random in that way? I’m just curious, I’m not a big fan of random myself so I’m a bit out of that loop. Trying my best to add it in a nice way though!
Im not one of the mapping random crowd, but I will say I love a randomise button on software devices. it really helps make keyboard & mouse interface a more enjoyable experience. sparking new ideas with randomise, then adjust & tweak from there. big fan
I just want to roll the dice using MIDI it would be cool to, say, make a rough drum patch on Pivot, percussive envelopes and all, then sequence Pivot to trigger once every 16 steps, then automate the rolling of various dice before the next note. Voilá, an automated FM drum sound generator – nice to chuck a chain of 64 Pivot drums to an M8, or similar.
EDIT: and, of course, just to have a dedicated control for almost anything can be very nice in a performance/get stuff done setting
Does anybody else have issues with stuck notes using the latest Pivot 1.1? I’m pairing Pivot with a max4live sequencer and sometimes the notes get stuck and keep on ringing even after stopping the Ableton transport. Happens to me maybe few times a day. The wavetable synth receiving the same notes never got stuck.
It’s annoying because the only way to release the stuck notes is to reload my ableton project. On/off for the vst doesn’t release the note and loading a fresh vst instance would make me lose all my midi mappings.
I haven’t had any issues with stuck notes actually! If you have a project with that sequencer where this occurs regularly that would be super helpful for me to track the issue down. Please email that to hi@fors.fm
Regardless I’ll take a look at the MIDI handler and voice allocator to see if I can see some obvious areas that could improve.
EDIT: This also reminds me that I should add in that double stop on transport kills all notes.
Figured out why the note hanging occurs, it’s a very obscure bug but makes sense why I didn’t catch it. Hilariously has nothing at all to do with the voice allocation or MIDI handling, which is what I’ve been hacking at for some hours today – but just now when sitting around it came to me exactly why this occurs and how to fix it. Strange how the brain works sometimes.
I’ll wrap this fix up and then do the LFO X/Y and ADSR hit points fix and release a 1.11 update.
Will try to get this done within the next few days.
… Or tonight. Uploaded v1.11 on our website just now.
Pivot 1.11
Improvements
Click detection for ADSR handles is now more precise
Holding ALT/Option while dragging LFO Skew/Shape will now only change Shape
Bugfixes
In rare cases voices could get stuck in sustain phase
Nice catch! This is caused by an oversight on my end. Basically you can’t set volume to 0 and modulate it with distortion applied, it’ll just be silent. I know why this happens, and it’s a little annoying to fix but shouldn’t be too hard.
Since it’s not a major bug I’ll probably aim for fixing it in the next big update that I’m working on.
