Bazille rev2435

[Tom Drinkwater]

Is there info anywhere about control rate vs audio rate?

I presume running everything at audio rate would be a problem for performance?

if there is going to be a separate control rate it would be good to know what the frequency is, how the control rate is clocked and what it is synced to, and a table of exactly which signals are calculated at control rate and which at audio rate.

some of my attempts to be clever have had rather unexpected results when I've tried to use control rate signals in ways that only make sense at audio rate. sometimes the results are useful, but regardless it would be great for the final manual to have a table all in one place of exactly what runs at what rate.

there's some other things that would be good to get clear too, eg the LFO saw wave will do an instantaneous return, but the ramp gen will not? is there a reason for this?

what about a scope mode that shows all the way down to DC so control rate signals can be viewed on it?

[Urs]

cables = audio rate, updated 2 or 4 times per sample
drop downs = control rate, updated every 4 samples

Exception: The CV busses that make cables available in drop downs have a control rate of every 64 samples.

[Tom Drinkwater]

it doesn't seem to be exactly that.

you can connect a cable from the LFO output to the audio out. When I do that with a triangle wave I get an aliased result that varies with sample rate. so even though it is on a cable it is not audio rate.

I think some modules are control rate (the ones that appear in the drop down?) regardless of whether they use a cable or not.

[pdxindy]

it doesn't seem to be exactly that.

you can connect a cable from the LFO output to the audio out. When I do that with a triangle wave I get an aliased result that varies with sample rate. so even though it is on a cable it is not audio rate.

I think some modules are control rate (the ones that appear in the drop down?) regardless of whether they use a cable or not.

LFO's, Env's are control rate. Also, mappers and ramps i think

If you want an audio rate LFO then use an Osc for it.

[Tom Drinkwater]

LFO's, Env's are control rate. Also, mappers and ramps i think

If you want an audio rate LFO then use an Osc for it.

that's what I had concluded.

the only things that actually generate an audio rate signal are the oscs. (tho I'm not sure about the sequencer.)

you can't modulate a map with an audio osc, except through the very low rate CV input.

you can use tapmap to draw a wave with the mapper, but you can't modulate a map at audio rate...

I'm not complaining, just clarifying what is and isn't possible, especially where it's different from ACE for example.

[pdxindy]

Thus the 4 Osc's... you can have 2 Osc and 2 audio rate LFO's (like ACE)...

it seems groups of 4 has something to do with coding efficiency...

i believe the sequencer itself is audio rate...

how bout a monophonic version of Bazille with everything audio rate

[Tom Drinkwater]

how bout a monophonic version of Bazille with everything audio rate

ideally, a per patch selectable control rate that goes all the way up to audio rate. ie 4 samples/2 samples/1 sample/2x oversampled/4xos(!!) Then if you turn it all the way up you may only get one note before the cpu gives up, but the flexibility would be there. When using control sources as "intended" turn it down. For some patches the control rate might not need to be even as high as it is...

when is audio rate 2x sample rate and when is it 4x? is that what the HQ switch does? does it depend on the host sample rate too?

i've been playing with using control rate sources as audio, got some cool lofi sounds, but of course they sound different depending on the host sample rate.

[xh3rv]

you can't modulate a map with an audio osc, except through the very low rate CV input.

you can use tapmap to draw a wave with the mapper, but you can't modulate a map at audio rate...

It's possible to use an oscillator with a TapMap waveform at 0hz here, and modulate phase.

I'm not sure I grasp subtle distinctions between a module's internal update rate and the audio-rate output, but I think this is a reasonable rule of thumb: If it appears in the drop-down menu it's not going to be 'correct' when cycling at audio rates. Alternatively, if it has an input socket (except CV) it's going to be 'correct'. TapMap oscillators are slightly more complicated but the current release is definitely improved, very nice here.

[thetechnobear]

Urs, every now and then in Poly mode I'm getting stuck notes.
(to remove i have to press the stuck note on and off, to wait for the right channel to be used to unstick it)

Im not sure if I can reproduce it, as its very infrequent, is there anything i can do to get you more info for a bug report?


Q (I keep forgetting to ask!) do the wired inputs for ModW, Breath, Xpress support 14 bit midi?

FR. could we have one (or greedily two) more CC outputs for wires.
(on an eigenharp, i use breath for breath, ModW for strip 1, Xpress for yaw… , Press for pressure (but thats limited to 7bit), and ideally id need another one for Roll, i currently use pitchW, but its not ideal if i also want pitch bend )

[Urs]

Too many questions at once

HQ indeed switches between 2x and 4x oversampling of anything with a cable input.

At the moment only Pitchbend is 14 bit. Once we have a proper preferences panel I assume we could add some more options.

I sometimes get few stuck notes too. It would be great to have a project for Logic/Live/Reaper/Anything that exhibits the issue. Maybe though it's related to preset switches or parameter changes. As it is, the voice management code is *the* are that's undergoing the biggest change at the moment. Bugs are expected and hints how to reproduce them are most welcome!

Cheers,

- Urs

[thetechnobear]

could you not assume 14 bits for the other inputs (breath/xpress/modW), as you don't provide access to other CC anyway, so no overlap of use…. so i don't think it needs to be configurable or a preference panel.
e.g. breath using 2 & 34 is pretty safe (if you don't get LSB you assume its 0 as per 14 bit 'spec')
(for me 14 bit is only incompatible when you want to use CC range 32-64 for further 7 bit messages, but u-he doesn't use anyway)

hmm, yeah I will need to be recording to have the stuck notes (I've not been so far), but even then with round robin and different timing, even playing back the same thing might not get stuck, but will try to 'force the issue'

[Urs]

could you not assume 14 bits for the other inputs (breath/xpress/modW), as you don't provide access to other CC anyway, so no overlap of use…. so i don't think it needs to be configurable or a preference panel.
e.g. breath using 2 & 34 is pretty safe (if you don't get LSB you assume its 0 as per 14 bit 'spec')
(for me 14 bit is only incompatible when you want to use CC range 32-64 for further 7 bit messages, but u-he doesn't use anyway)

hmm, yeah I will need to be recording to have the stuck notes (I've not been so far), but even then with round robin and different timing, even playing back the same thing might not get stuck, but will try to 'force the issue'

Well, if we assume 14 bits, then the maximum is 128 major steps + 128 minor steps. So, the highest value would be 127.00 + 127 * 1/128. That's almost 128 when both MSB and LSB are set to 127. If however LSB is always zero, then we never reach the maximum. That would screw up a lot of things

[EvilDragon]

But it's supposed to be calculated like (MSB * 128) + LSB, no?

[Urs]

But it's supposed to be calculated like (MSB * 128) + LSB, no?

Depends on the implementation. Inside our stuff it's always from 0.0 to 1.0

It doesn't change the outcome though.

Maximum 14 bit with LSB always 0 is 16256
maximum 14 bit with LSB 0-127 is 16383

Thus, one can't just assume 14 bit control

[thetechnobear]

good point (as always) , for MSB = 0 , you need to assume LSB=0 (to get 0 14bit) and for MSB=127, you need to assume LSB=127 (to get 16383) - so begs the questions... assume LSB=MSB unless you receive otherwise?
(i guess first receipt of LSB means you can assume it will continue to be received)