Hi all!
I’m trying to modify any factory delay objects, so I can set the delay length in millisecond from a list of custom numbers. There is the factory object, where the length can be set in sample buffer size and there is the one, when it can be choosen from a list of numbers. I’m familiar with modifying objects in a very basic way, like adding inlets and so on, but very much stuck with this task. What am I missing? Where should I start?
If I recall correctly the sizes in the delay objects drop down list double up in size with each entry.
And due to this double-up nature, the author of the objects used some “microcontroller-efficient” code, which is arguably cryptic (namely, bit shifting), to produce some helper variables.
The variables called LENGTH and LENGTHMASK (and LENGTHPOW which, i believe, isn’t used by the object internally)
LENGTH is the actual length of the buffer, derived from the drop down value.
LENGTHMASK is LENGTH - 1, another C language bit masking sort of thing. Makes it easier to get the delay line to wrap around exactly after the last sample.
Long story short, we’ll have to rewrite these helpers to get other delay sizes than power-of-2 ones.
You mean you want a drop down list with sizes of, say 500ms, 1000ms, and so on?
For that you’d edit the size attribute. In the list of string entries (what text is displayed in the drop down) you’d write something like “500ms”, “1000ms”
That is, each text entry in double quotes, and entries separated by a comma.
Ksoloti audio runs at 48 kHz samplerate. That means, one second of delay is 48000 samples long.
So in the values list, you’d write “24000”, “48000” in the same quotes-comma format like above.
So when you select 500ms, the number 24000 is passed to the code.
(attr_size is replaced by this value during compilation)
I may be forgetting something as I dont have my Ksoloti in front of me. I’ll have a look later. Almost sure that LENGTHPOW will be making trouble (it may be referenced by the respective delay/read object). In that case we’ll have to change the way LENGTHPOW is handled in both /write and /read.
1 Like
You were right, this whole system is really hard to mod. The concept itself is not too hard but the very low-level implementation makes it hard to exchange values for millisecond-based ones. The only way to understand it is to visualize which values do what during the DSP process. Working on it!
By the way, if you want delay times in milliseconds, you wouldn’t usually need the buffers (=delay/write) to be exactly that size, only the read position? (Usually having a buffer slightly bigger than the maximum delay time is safer)
1 Like
Ok I figured it out, it was unrelated to the delay mechanism itself but unexpected (to me) behaviour of the “%” operator with negative integers.
write_ms1 and read_ms1 contain the relevant code.
I went with a “spinner” number attribute to choose a delay time in ms. I am guessing that you will want to change the delay time ms live, in that case you’ll have to set the size_ms in the write object to the maximum available delay time, then do some math after the “delay time” knob to get your desired delay time (ratio).
delay_ms.axp (9.5 KB)
1 Like
Meanwhile I had one heureka moment based on your first answer, but then I faced some issues what you described and stuck. Thank you for solving this puzzle! Can’t wait to try it out.
An update: it’s working faboulusly, I’m having tons of fun with it. Thanks a lot again!
Added ksoloti/delay/* ms objects for easy millisecond-based delays. Includes help patch with a polyrhythmic example.
Thanks for the inspiration!
1 Like
My pleasure!