Convert integer number of samples into fraction of delay time

#1

I feel really stupid, there must be a way to do this but I can't work it out.

I've got a timer measuring the interval between presses, this is giving me the number of k-rate samples*. I can multiply it by 16 to get the number of s-rate samples and I have the length of a delay defined as a constant elsewhere. I know what I would do to get the fraction of the total delay time if I was working with floating point, but I can't work out how to do it using axoloti's units. I need something like (64/totaldelay)*interval, but axoloti's options are somewhat limited when it comes to division.

D;

*There's a deliberate exploitation of execution order there by the way, I have that or gate acting as a 1 k-sample delay, so the button press actually stops the timer and then the gate starts it again 1 k-sample later.
I think I should be adding 1 to the resulting count to compensate, is that right?

Help converting rotary encoder input to dial input
#2

I think i'm searching the same thing and I was ready to post a new topic but maybe your problem is similar to mine.

I measure the interval between two notes and with that I want to control the delay time of a pulselenghtm object.

#3

Hmm, I think they're related up to a point, but I think the pulselengthm objects have a reverse 'musical' exponential scaling where 12 units doubles the time. The delay is a linear fraction to my understanding, so putting '32' into the delay read object of a buffer 256 samples long gives 128.

#4

I've still not worked this out, will have another look tonight but any pointers in the right direction would be much appreciated. Even if they're just posts pointing me to threads that help - I did some searches but I might have been using the wrong search terms.

#5

Converting semitone scaling to a linear scaling for the delay modulation input can be done with "conv/mtod". The correct tuning offset for "conv/mtod" is 7.53 semitones.
Converting linear scale to semitones, there is currently no object for this. You could approximate by :

#6

But how do I convert my large integer into a fractional value? I feel like I'm missing something here, like perhaps you're assuming something that should be obvious but isn't (to me) for whatever reason.

So what I currently have is a way of measuring the time interval in k-rate samples - output as an integer. I also have an integer constant storing the number of samples that make up the delay buffer. I can divide that by 16 or multiply the interval by 16 to get them in the same range.

Is there really no way to do this properly with the factory objects (which is what I gather from your post)? Given that the buffer size is a nice power of 2, it seems like the maths wouldn't be too nasty. 524288 is 8192*64, so (interval/8192)=fractional number in the range of 0.00 to 64.00 rounded to whatever the precision of a fractional number is internally.

#7

There is indeed no very convenient way to convert a green outlet with a certain scaling to a blue outlet, but here is one workaround:

This multiplies integer 4096 with fractional (1/128), result is 32.0 fractional.

#8

Ah, that's an approach I tried, but 524288 is too big I think. It didn't behave as I had expected at least, I think it might have been overflowing.

EDIT: Aha, but 524288/16 is not too big! It's not like I'd gain any precision by working with s-rate numbers anyway since my interval measurement is k-rate. I think this'll work. Thank you!

#9

You can also chain another "math/div ..." before the math/* to extend the range, if needed.

#10

I've ended up replacing it with a >> by 9, which is divide by 512 if my maths is correct. Either way, it scales 32768 down to 64.00 successfully!

p.s. I love that this board allows uploading of screenshots straight from the clipboard.

#11

@johannes I have a question regarding delays which doesn't seem worth making a new thread for. When the delay time of a given delay is set to 64.00, instead of getting the maximum delay time it seems to give the same effect as 0.00 - i.e. no delay. I assume this is deliberate, but what is the purpose of it? Is it simply the read index lagging so far behind the write index that it bumps into it again?

#12

If I recall correctly, this depends on the execution order:
If the "delay/read" is set to zero, but precedes the corresponding 'delay/write", you'll get a full length delay.
If the "delay/write" is set to 64.0, but precedes the corresponding 'delay/write", you'll get a zero length delay.

#13

Ahh! It'd hadn't occurred to me to try swapping them. I have pretty much always placed the write before the read because it just seemed to make sense to me. Thanks again!

EDIT: Seemingly the same result both ways round. It's not a problem, I just put my delay control signal through a min object that's comparing to a constant of 63.99.