14 bit pitch bend automation (vst)

don’t know what pitch bend threads in the forum exactly adress the issue i have, so i post this maybe again

aside from the fact that i could (the song allows to do so) lower the pitch bend range in the vst…, the ~8 bit (-100% … 100%) in renoise isn’t enough.

i just had it sound too high at -74% and too low at -75%. i wish i could enter 74.5%. if i’m correct 14 bit gives +/- 8192, so one digit after the point should be doable? or entering the actual values, would be even better

ps: even better, let me enter the range (there’s no vst2 opcode to ask the plug-in, is there?) into the automation device, and then enter/display cents

Correct, MIDI pitch bend has a maximum of +8191 and a minimum of -8192 with 0 as centre.

The problem here is Renoise currently rounds the pitch bend valueto the nearest integer which it shouldn’t as that’s really unmusical.

I agree there should be a change so it let’s you type in the precise value itself between +8191 and -8192 or allow us to use decimal percentage values that round to 8191/-8192 accurately.

Such stuff is still a Stiefkind in renoise. Sadly. I think this is because renoise evolved from an oldschool tracker philosophy, where midi played no big role in similliar progs in the past.

I found the full 14bit accuracy can and will be used, however. I guess you’re talking about the instrument midi device, and the pb slider? Firstly it will display no fractions. But you can actually enter fractional numbers by doubleclicking the value, and though it’s not displayed (the percent value is actually a rounded representation of the real value currently in use!) I’ve checked with a midi monitor, whole 14bit range is used. I.e. renoise uses a floating point value, and converts to integer with full range and accuracy when transmitting midi. At least for the midi out, for plugins this can’t be checked easily, but I guess it does the same there.

As for automation, you probably don’t want to use pattern effects. Controlling the inst.midi device via pattern commands limits you to 8bit, and the dedicated pattern pb commands have the downside the fx commands will also have, you can only update once per line giving very steppy glides in usecases without real high lpb resolution. The automation graphs are usable tho, in line/curve mode will update the value each tick I think. Automation graphs work via floating point values, and you can input exact numbers with fractions to your liking for each point.

As for remapping - each vst will have it’s own pitchbend handling. I don’t think there’s a way of signalling to the host which range is actually used, but you should be able to know when using the plugin and configuring there? I’ve experimented with the formula device, with this you can write some tiny lua code that will remap the used pitchbend range to your very liking. I.e. you could use one before the inst midi device, and make it translate data in ways that a general 12st pb is remapped to 7 up and 2 down, or whatever. It just needs to be within the range the plugin actually uses. By remapping you pitchbend wheel to a general cc (going down to 7 bit resolution) or by using the duplex keyboard tool (makes pitchbend and aftertouch midimappable to any parameter) you can map them to the input of the formula device translating the values, and record that action to automation graphs etc. I just found that the center value of the wheel (64 of 0…127) will be slightly above 0.5 as center, but could fix this in the rangestuff with a formula device also with calculations compensating it.

Let’s hope somewhere in the next renoise versions there’ll be dedicated handling for springcentered midi controllers and 14bit inputs.

I found the full 14bit accuracy can and will be used, however. I guess you’re talking about the instrument midi device, and the pb slider? Firstly it will display no fractions. But you can actually enter fractional numbers by doubleclicking the value, and though it’s not displayed (the percent value is actually a rounded representation of the real value currently in use!)

I’m surprised. It’s true, it’s there.

Though, what’s saved in the Song.xml confused me in the end.

I entered 4 PB automation points, them being 57% 57% 56.6% 56.6%

that gave

11264,0.784090936
11520,0.784090936
11776,0.782999992
12032,0.782999992

but then I tried getting the last point to 57% by just clicking and hitting enter. But the value in the Song.xml stayed. Somehow ok to me. Then at that last point I entered 56% and then I entered 57% and actually that 57% should be the same 57% as the others. But instead the value (last point) went to this:

11264,0.784090936
11520,0.784090936
11776,0.782999992
12032,0.785000026

In other words, I don’t understand it.

But it apparently is usable to some extend and good to know it goes to the plug-in with 14 bit, thanks a lot for the clarification on this subject.

The other (hex) things to control it are out of my mental reach so to say.

it would be nice if they could have a native device to handle this.

it sounds like it may need a higher resolution sub pattern at a much higher tick resolution.

you’d also need a graphical interface which makes it easy to handle all that. could be a tall order.

can’t say i’ve tried driving renoise sample instruments from another DAW and applying PBend.

I’d assume that’s the condition Redux will be operating under when it appears.