Sample accurate Array shifting.

[lalalandsynth]

I need to shift an array and have it sample accurate , how can i achieve this ?

Will Ruby spit out a shifted array at sample accuracy , I read in the manual that it should work at sample rate but I am not sure. I would be shifting the array at a maximum of 64 notes with a quantized LFO , possibly even with an unquantized lfo , although I might cap it at 128th notes when moving in a linear fashion.

Using the Shift array is not accurate , max 100 ticks , and will definitely not be accurate at faster then realtime rendering.

Any thoughts ?

[Spogg]

I would be inclined to check out the memin option in DSP. You need to provide a mem component to feed it, and that data could be created from a float array. Shifting or rotating the array in DSP should be possible but I think Martin or someone would have to help with that. Plus you need to get at the data once shifted, but that should be possible by making a DSP multiplexor or having multiple streamouts for the appropriate mem indices.

One limitation is that the mem size is pre-defined when the DSP code is first active (new note in poly or forever in blue). So you can’t change the mem size on the fly and there’s no way to set a variable that defines it externally. You’d need multiple versions of the DSP code box, one for each mem size I think. Or maybe have a large mem size that takes the worst case into account, and rely on the code to address the appropriate range within the mem array.

I’m not really the one to offer Ruby advice, but I do know that if you need sample accuracy then you have to use Frames and that carries a high CPU overhead. Otherwise it lives in the green world so you don’t gain accuracy once it’s outside the RubyEdit code and back in the green world.

Cheers

Spogg

[tulamide]

I dare to say a few things, although I'm not on my safe place here.

The DSP code box offers arrays. They are generated with the square bracket.

Code: Select all

float myArr[128];

They are accessed similar.

Code: Select all

myArr[3] = 0.5;
myArr[4] = myArr[3] + 0.12;

Maybe it's better to start the array in the DSP code box and keep it there, so that green is not involved? Shifting would be a matter of (depending on direction) looping through and setting last but one value to last value etc.

Code: Select all

float counter = 126;
float buffer;
float myArr[128];
buffer = myArr[0]; //temporarily store first item of array
loop(127)
(
  myArr[counter] = myArr[counter + 1];
  counter = counter - 1
)
myArr[127] = buffer

However, I don't know if the DSP code box offers everything that is needed for above example to work (like addressing array elements through the use of variables for example). That's where the DSP pros have the word.

Regarding memin I have even less knowledge, but this is what I found in the manual:

You need to specify a maximum size for the mem data this is so that enough space is reserved for mem data in the compiled code. Whilst Mems do know their size we don't want to be recompiling everytime a mem changes so by declaring a maximum from the outset the Mem size can change dynamically without affecting anything

I don't even pretend I'd understand this paragraph, but it says something about dynamic mem changes.

Ruby uses frames to handle data in streams without leaving the streams. Those frames are the size of your audio buffer (DirectSound, ASIO, ASIO4ALL, etc.) and works beforehand, which adds another buffer on top (say ASIO introduces 3ms latency, then with active Ruby frames you'd be at 6 ms). Also, since Ruby is an interpreted language it is way slower than C or Assembler and adds quite a lot of cpu load. But technically it could be done with Ruby, yes.

[lalalandsynth]

Thanks guys !

To further explain the issue.
The array is initially created in Ruby and is 1024 values, I could possibly output that as frames and into DSP?
But now it goes into a FloatMem and into a Mem read interpolation to Blue.
Using a shift array on the output from the intitial Ruby and into the Floatmem I can shift it in both directions, 1024 in each direction. But , then I am in Greenland and have lost accuracy.

I dont need to vary the memsize , it can be fixed.
Shifting it in dsp is probably the answer !

I have double inaccuracy actually as i am also quantizing the LFO via greens , BUT ,that I can fix....possibly.

Working on this, its essential to two of my plugins so, needs to be fixed

[lalalandsynth]

Here is the current version of the plugin, mostly finished except for the Shifting issue .

martin.jpg (213.45 KiB) Viewed 13505 times

GIF.
https://imgur.com/xYAgCnP

[trogluddite]

A couple of quick questions...

Do you want the Array to shift in order to open up space at one end for new data (losing the values that "fall off the end"), or do you want to do a rotation where values that "fall off the end" are inserted back into the empty space?

Will you always be shifting in the same direction, or do you need to be able to go both ways?

In any of these cases, DSP/Assembly is likely to be best, as using Ruby on a Frame of such a large size would be very slow, and using 'Frame to Mono' is out of the question as it assumes a Frame size that matches the audio buffer size. However, IIRC, there is a sneaky way to get the memory address of the raw sample data from a Frame, which might ease the translation from Ruby to Blue (though it has to be used somewhat, erm, carefully!)

[lalalandsynth]

The Array would indeed wrap around , so "rotation where values that "fall off the end" are inserted back into the empty space" I need to be able to shift in both directions so 1024 or -1024. Or preferably just like the Array shift works where I can go above the 1024 and it will just keep on shifting accordingly


Also , I might need to convert blue to float at sample rate as well , M2f is not accurate either.
Or be able to shift the array with both floats and blue.

[trogluddite]

The Array would indeed wrap around , so "rotation where values that "fall off the end" are inserted back into the empty space" I need to be able to shift in both directions so 1024 or -1024.

I was hoping you'd say that!

What I would do in that case is to treat the array as a circular buffer. Rather than shifting the data, leave it where it is and shift the read index in the opposite direction instead, wrapping it around the start/end as required. This might require some additional Ruby code, depending whether the GUI needs to interact with 'shifted' or 'unshifted' data, but it means that your blue sync problem then only needs accurate timing of a single blue offset value and a handful of DSP 'wrapping' calculations. This should be much easier to arrange and will be far more efficient than rotating the data.

[lalalandsynth]

Gui can display shifted data derived by green means , that is fine.
So you mean shift the index at the mem read/interpolator ?

If I could shift with blue I would be golden ,That would solve data coming from the Modulator (blue) which I can quantise into discrete array offsets .

I could then of course also shift with float with the offset knob.

To be clear, currently there are two way to shift the array , either with the offset knobs which is "static" unless automated and the Modulator/lfo . All of this is currently done in greenland which is unacceptable but If I could shift the array with blue , It seems everything would work.

[lalalandsynth]

This is where the shifted array comes in via the Shift array prim.

Shifted array.jpg (101.74 KiB) Viewed 13473 times

And goes into the Mem read interpolator module.

mem read.jpg (129.55 KiB) Viewed 13473 times

Now I if could find a way to shift it here with blue?
Thoughts ?

Btw, I would be more then willing to pay for someones time to make it so that I can shift the array with blue.
I have 2 plugins dead in the water if I cannot solve this and I think its more then worth it to me