Delay time units

#1

OK, another novice question. I know the answer is here somewhere but I'm not picking the right search terms, apparently... and I am sure a dozen people can probably answer instantly:

how do I make sense of the units on the delay/read interp dial in terms of time and/or k-rate samples?

The thing I actually want to do is sync up a delayed pulse object so that a pulse is issued at time that is a fixed interval of the time used in my delay line. I think I could probably figure this out brute-force by setting it up and twiddling dials and listening, but it's bugging me that I have absolutely no idea what the relationship between the number "6" on my read interp dial is to the number "44" on my delayed pulse dial (arbitrary numbers chosen here just to make the point).

thanks everyone... wow, there is such a lot of brainpower here and the more I play with the Axoloti and discover your work, the cooler it gets!

#2

consider the number as a 'percentage' of the buffer. (where % is 0..64 rather than 0..100%)

so if your delay is 1024 samples, and the dial is 32, then this means 50% of the buffer (i.e. 32/64 = 0.5 * 1024).

ps. the same convention is also used for table access.

#3

OK, thank you for the super clear statement, which helps me sort out a few things I'd picked up in a semi-confused way from forum browsing.

Ok... so I guess the other step I should just not be lazy about... in the delayed pulse object it displays the correspondence between time and dial units, and I should be able to use that and the k-rate to figure out what dial setting to use to send a pulse at some exact interval of samples corresponding to whatever my delay is doing. If I am wrong about this, let me know!

Thanks again.

#4

OK, I have more timing confusion. It relates to the delayed pulse and other timer objects. So probably I should make another thread since it's a slightly different question, but still related.

So, the timer objects have dials in them that run -64 to +64 and this seems to translate to a time range of 2.41 ms to 3.91 s. The numbers strike me as strange... how is a 2.41 ms delay even possible if k rate is 3000Hz and these objects are inputting and outputting at that rate? I get that there's some rounding somewhere for the display, but this makes me feel like I am just missing something.

I'd love to be able to tell the delay to basically output a pulse after a specific number of k-rate samples so I can tune it to be in sync with other things that are going on in the patch. I thought I could just figure out the scale and input the right value to one of the timer objects... but the scale obviously isn't linear. It is making me wonder if writing a new object might actually be a more reasonable approach.

Any insights, or other directions for doing something along these lines, would be greatly appreciated!

#5

ok, honestly this gets a little complex, and id also have to go check the code to be 100% accurate, but heres some basics :slight_smile:

if you look at a parameter, you will see if has a type, this type can have a mapping, that may not start at zero, and may not be linear. they are also 'generic' i.e. an objects use might not necessarily be 'accurate' ... or as you say may 'round'
the particulars of the timer id have to check again, its been a while, and using -param into mtof means something very particular (which I cannot remember off the top of my head).

ok, I'm not sure what you mean by 'k-rate' samples, there are samples, and k-rate cycle, i.e. 16 samples are processing in one k-rate cycle. (which is why we have 3khz, 48000 sample rate/16=3k)
control 'messages' (e.g. k-rate parameters/inlets) are processed at k-rate, i.e. k-rate code is called 3000/sec, and immediately before s-rate code, which is called once per sample for that cycle.

so are using saying you want a 'tick' every N k-rate?
if so, why not use a simple counter object? set it to N, and it will carry, every N cycles.

if you really want to do every N samples, then you have to do this at 'audio rate' (or sample rate hence S-rate code), but to do this effectively, you will need to create an audio rate pulse, i.e. within a pulse in an audio buffer, since if you want to trigger after say 18 samples, this is 1 k-rate cycle + 2 samples.... doing at k-rate you would be either 2 samples early, or 14 samples late.

but... I'm guessing you want it at k-rate, so a counter is fine.

sorry, I'm not really sure what you trying to do, or achieve...

#6

Hey @kat

I havent tried this object myself, put I noticed it a while a go:

rbrt/control/pulse delay

I THINK it does what you need. I never tried it, cause I kind of prosponed it, but I think you should try it out.

Jaffa

#7

Thanks a ton for the detailed reply, Mark. I am in that phase of ramping up with the Axoloti where I am trying to do a lot of things in stupid ways because my brain isn't thinking about things in an Axoloti-specific way yet! Your answer not only helps me solve this particular problem but also helps me get my vocab right and understand a few other things going on here... I very much appreciate your patience and clear explanations since it's this kind of messy stuff that helps a new person very quickly become a capable contributor (which I hope I can be soon!).

Yeah, I was using 'k-rate sample' sloppily... I guess I was thinking that if a k-rate parameter is in control of something involving timing, it can't change things in anything other than units of 1/3 millisecond, so I was thinking of that as its own kind of sample rate.

It does sound like the delayed pulse is probably not going to do what I want here and some kind of counter or a pulse in an audio buffer is the right idea.

Bottom line is that what I want is to synchronize some triggered stuff in a patch so that it happens at intervals that have a fixed relationship to a delay that is also running. There are a couple things I want to try out but the simplest application is just triggering a looper so that it automatically records audio for a time period that is a fixed number of repeats in the delay pattern. Since I am still new to thinking about tables and how the delays and loopers are actually functioning, I was hoping I could hack this into place with my minimal knowledge just by getting the timing parameters set up right for a delay and a delayed pulse.

But, it's a good thing if I have to be less stupid! Hear the click of the gears turning...learning quickly...

#8

Ah, I don't think I would have easily found @rbrt's pulse delay object but yes, it does exactly the right thing if what I want is a pulse delivered at k-rate... but now I think I am realizing that it needs to be s-rate, or else I just need to do this differently. But I am glad to discover the pulse delay ... I keep thinking of ideas that involve various sorts of triggering dependent on signal conditions and delays and whatnot, and that definitely will go into the toolkit. Thank you Jaffa!

#9

hey!
did you find a proper solution?
I'm having a similar problem and I'd like to hear more from your workaround.

#10

Hi @srodillof,

Funny that you've picked up this old thread right now, since I think I am circling around to the same issue again.

I am pretty sure what I was trying to do when I wrote this question initially was the same thing I have suddenly realized I need to do now (meaning, I never solved the problem). What I want is a looper that is in synch with a multi-tapped delay. I have a song that has two guitar parts that involve the same complex delay pattern, and for live performance purposes I need to rig up one of them to loop. But because the pattern is complex (and my timing sucks) it is not easy to just use a straightforward looper.

I don't know if this is actually similar to any of the things you are trying to do, but let me know, if so. I am going to bang my head against the question for a day or two and then may open a new thread if I get stuck.

Sorry... no great insights yet!

#11

I made a 4-track looper with a simple delay effect that syncs to the tempo of the main loop (the first loop sets the length for the other 3 loop units).

the loop units (rbrt's looper) use a phasor transport to stay in sync. I set up cue triggers every 4 beats along that phasor that work as a constant tap-tempo, and that tapping sets de time of the delay unit. the phasor goes from 0 to 64 and then immediately 0 to start again, so I set the cues at 0, 16, 32 and 48.

it works! I'm not sure if it helps your case, and I'm sure there's def. a better way to do it, but I had limited time to finish my project and that's all I could come up with.

if you need more details, let me know!

#12

Probably a very noobish question :stuck_out_tongue: but how would this work? The logic/counter object seems to need an input to actually count and I couldn't find an object that just created a pulse for every k-rate cycle. Tbh I expected the logic/counter object to be processed/counting for every k-rate cycle automatically but I'm probably missing some Axoloti specific knowledge here :slight_smile:

#13

@simonvanderveldt

Look in rbrt's folders, you will find some timer objects that report time in k ticks.

#14

I managed to get it work by combining the code from the midi/in/clock object and some small own code that does actually increment a counter every k-rate cycle :slight_smile:

Still not sure if the behaviour from the counter object is correct/if it's behaving as expected.