KVR Audio

otristan · Post by **otristan** » Fri May 04, 2018 8:48 am

Standard range is 50 cents on a linear scale
Large range is 1 semitones with a ^3 scale
Both on each side of the played note so technically you need to multiply by 2 to get the full detune range
so std is 1 semi and large is 2 semi

Hope this clarify things.

liv · Post by **liv** » Fri May 04, 2018 10:44 am

Thanks otristan.
So essentially you should be able to create the same detuning with the analog stack, or are there more ingredients involved?

otristan · Post by **otristan** » Fri May 04, 2018 10:55 am

Yes.
You need to have the same stereo panning and start phase distribution as well though.
There is no magic happening there, just an easier way to set it up

c_voltage · Post by **c_voltage** » Fri May 04, 2018 4:32 pm

Otristan so what about that bug mentioned in previous pages ? Related with new fx.

Charlie Firpo · Post by **Charlie Firpo** » Fri May 04, 2018 4:40 pm

The freqshifter bug at program level was fixed in the v1.5.1 release. That was fast Uvi, thanks!

c_voltage · Post by **c_voltage** » Fri May 04, 2018 5:26 pm

Charlie Firpo wrote:The freqshifter bug at program level was fixed in the v1.5.1 release. That was fast Uvi, thanks!

Oh really

Not noticed before. Good.

c_voltage · Post by **c_voltage** » Sat May 05, 2018 3:22 am

Oh damn, did catch some freeze just now, helped only system hard reboot thru button. Its occurred when i use single Wavetable osc and turning Voices knob about maximum 8, during sounding voices at maximum release. But after reboot tried reproduce this - hmm, nope yet, all ok.
Well, if i will able to reproduce again then will try to detect pattern.

sircuit · Post by **sircuit** » Fri May 11, 2018 10:05 pm

I was trying to recreate the "tie" effect using the Step Line sequencer script. I am modulating the glide time at the program level with an envelope (the old trick with assigning a parameter in the oscillator to a program layer envelope then asigning that envelope to any parameter will result in retriggering the envelope with each note). The logic behind is that the envelope resets with each note and with carefully adjusting the attack, only the longer notes will give the envelope enugh time to rise and to affect the glide. Problem is, after few minutes of twesking, the glide parameter is becoming unresponsive. Even unmapping everything and adjusting it by hand does nothing. Most likely is a bug. Anyone managed to make a proper 303 sequencing in Falcon?

Edit: the slicer bug is still not resolved yet and it's annoying AF - when loading a loop in the slicer even if I specify the correct values for length (bars) and the correct bpm, only the bpm gets recalled when reopening the project (Falcon constantly detects all my 2-bar 120+ BPM loops as being 60+ BPM and 1-bar in length). Dear devs, this is a huge bug, the are virtually no sample packs with embedded bpm information on the market (except for rex files).
Also, I may want to drop drone sounds in the slicer and specify various BPM's and bar lengths in order to get different sounds. Please solve this, I just want the bar length and bpm properly saved within my logic project.

the3ug3reeder · Post by **the3ug3reeder** » Sat May 12, 2018 8:25 am

sircuit wrote: Edit: the slicer bug is still not resolved yet and it's annoying AF - when loading a loop in the slicer even if I specify the correct values for length (bars) and the correct bpm, only the bpm gets recalled when reopening the project (Falcon constantly detects all my 2-bar 120+ BPM loops as being 60+ BPM and 1-bar in length). Dear devs, this is a huge bug, the are virtually no sample packs with embedded bpm information on the market (except for rex files).
Also, I may want to drop drone sounds in the slicer and specify various BPM's and bar lengths in order to get different sounds. Please solve this, I just want the bar length and bpm properly saved within my logic project.

YES! i also find this totally annoying...
i think the problem is that falcon stores the slicing data in the actual sample.
this means that if you want your slice data saved with your program, you need to actually "save program and samples"...
it means that if you want several versions of one sample sliced in different ways, you'll actually need to save several versions of your sample (just to accommodate different marker positions).
--this gets even more annoying when you realize that in order to do this, you actually need to MANUALLY make copies of the sample.
if you simply duplicate a slicer keygroup, and then reposition slice markers, it'll work fine until you actually 'save program and samples' because falcon will simply overwrite the referenced sample several times leaving you with only one set of markers the next time you open your program.
WTF!

it also means that if you're using falcon in your daw project and slice a sample in falcon, you can't simply save your daw project because if you do, you're slice data will be lost.
if you're using the slicer, you always need to "save program and samples".
in my opinion, this is totally retro in a bad way.

a few pages back,

otristan wrote:In case of slice, you need to save the sample as those data are in the sample itself.
We figure that this is something that is not related to this keygroup but actually to the sample itself so it stays there is you reopen this sample in another keygroup.

respectfully, i disagree.

EvilDragon · Post by **EvilDragon** » Sat May 12, 2018 9:43 am

Slicing in Falcon is absolutely user unfriendly because of that. Slices should definitely be stored as part of the patch without needing to store them in the sample. Other samplers have no problems with this.

the3ug3reeder posts several good usecases where Falcon's implementation just fails and is extremely annoying. Please Olivier just make it so that slice data is stored in the plugin chunk/.uvip without needing to save it into samples. Have an option, if need be.

liv · Post by **liv** » Sat May 12, 2018 10:50 am

While on topic, add a grid option and/or a knob to set specific number of markers.

nordickvr · Post by **nordickvr** » Sat May 12, 2018 11:04 am

EvilDragon wrote:Slicing in Falcon is absolutely user unfriendly because of that. Slices should definitely be stored as part of the patch without needing to store them in the sample. Other samplers have no problems with this.

the3ug3reeder posts several good usecases where Falcon's implementation just fails and is extremely annoying. Please Olivier just make it so that slice data is stored in the plugin chunk/.uvip without needing to save it into samples. Have an option, if need be.

+++++++1

whyterabbyt · Post by **whyterabbyt** » Sat May 12, 2018 11:24 am

EvilDragon wrote:Slicing in Falcon is absolutely user unfriendly because of that. Slices should definitely be stored as part of the patch without needing to store them in the sample. Other samplers have no problems with this.

I'll second this. Patch-specific data should be in the patch. If the slice data for a patch is in the file, then duplication of the whole file is required for alternate slice arrangements.

Caine123 · Post by **Caine123** » Sat May 12, 2018 11:27 am

Yes from me too. It is so cumbersome... i hope uvi adds it

c_voltage · Post by **c_voltage** » Sat May 12, 2018 1:04 pm

Hmm, yes, +1. All changes should be save together with DAW project.

UVI Falcon - v4 = 2026 released - rumors, ads, praise, kindergarden, auto-sampling and off-topic inside!