Read multiple values from ArrMem at the same time

[megique]

Hi Everyone,

I need some help concerning using ArrMem + Read primitives. Let's say I have an array with ~6000 values. I also have a code block which determines the sample that I need from that array. Awesome, that's simple. But what if I need to take more than one sample (let's assume 16) from that array at the moment? Do I need to duplicate Read primitive 16 times? That doesn't sound optimal... I ended up with the schematic similar to the one attached. Is there any easier way to take a few samples from an array at the same moment? Any hack or anything obvious that I've missed? Any other way to store the array? I'd be grateful for pointing me to anything helpful.

I was thinking about using Ruby to somehow implement this kind of functionality myself (taking an array and returning a few samples also as an array) - would that make any sense? I'm worried about synchronizing DSP code block with Ruby code block.

An additional info: you could ask why do I need 16 samples at the same time instead of taking them one by one in the following samples. Well, I will actually put them in a buffer and will use them later one by one but the thing is that during the next sample I might need another 16 to add them to the same buffer, so the Read primitives will be busy with something else anyway. I hope that makes sense. Just thought it might be helpful in case anyone sees some kind of workaround around this.

Btw in the real case scenario it's not even 16 but 64 so I'm really not comfortable with duplicating Read primitive 64 times...

Thanks!

[KG_is_back]

Using multiple wave read prims is unfortunately the most stable and efficient solution. You may use "memin" in DSPcode, which makes copy of the mem as an array, and you may use it in the DSP code just like normal arrays. Problem is, you are effectively working with copy of the mem. if the mem buffer is very big (like a several second long wave table ...myriads of samples) the overhead of creating the copy may be significant (very bad when used in poly, in mono it's OK). Also I do not know how the buffer is updated once it's created. It might be, that you write a value using "wave write prim" and it will not show up in the DSP code copy.
Another solution is to extract the pointer of the mem (using toAddress prim) and write your own custom waveRead prim in assembler (or ask someone to do it for you, for example me). Problem with that is that the solution has very high crash potential (discussed in several topics here on the forum). Once that problem is more-or-less sorted out I will also add the support for it to DSPcode2 project.

[megique]

Thanks for the reply KG!

'Memin' in DSP code sounds helpful, I've never heard about it. I do use poly but the array would be 6400 samples and I don't plan to modify it at all. In that case I assume it would work rather smoothly, right?

If I'd use 'memin', would it be copied to DSP code primitive once during stage(0)? This shouldn't cause too much overhead. Or would FlowStone try to update it from time to time?

[KG_is_back]

Memin' in DSP code sounds helpful, I've never heard about it. I do use poly but the array would be 6400 samples and I don't plan to modify it at all. In that case I assume it would work rather smoothly, right?

Yes, in this case it should be reasonable.

If I'd use 'memin', would it be copied to DSP code primitive once during stage(0)? This shouldn't cause too much overhead

Yes, you are right.

Or would FlowStone try to update it from time to time?

I don't know. I assume it will update it every time the mem changes, but I never really played with it to confirm that.

[martinvicanek]

You may get some inspiration from here. Alternatively, if you have the latest Flowstone 3.0.8 there is an improved mem-to-address&size prim which may provide a simpler route. Let us know your result.

[megique]

Thanks to both of you!

I decided to simply go for the memin functionality in DSP code block. I don't really care about writing to this specific array at the moment but it's good to know that it's possible. The problem I faced though was high spike in CPU usage (no wonder if I'm reading/writing 32 values from/to arrays in every sample). So currently I'm trying to optimize the code using Assembler and I cannot express how grateful am I for the posts you wrote on your blog KG_is_back! I already managed to reduce the CPU by half and still see some possibilities ahead!