memin feedback for DSP Code

[chackl]

Hello!

It is realy nice to see things going on here

And i have something that seemed to be usefull on the first look - and now i noticed, that it is not working.

What i did is:
Handling the memin of a code component like the memin from the mono-write module (as found in the mono-to-poly)
I imagined that this will give me some additional features to handle multible poly-streams with different Multi-Voice options - But i see the mimin is only for input "at the moment".

So might there be any chance in future to handle the memin as "feedback" in future? (writing data to the mem conector like the R&D Wave-Write)
If it is alredy possible - will there be any way to get this handled now?

Added non-working schematic example.

Kind Regards
C.Hackl

[Exo]

Hey chackl,

MemIn is currently read only. This is because the mem is copied instead of being read from directly.

To be able to write you will need to use the "Mem to Address" component. Which means going into ASM. My free runnning oscillator has an example of this on Flowstone Guru HERE.

Also because the mem is copied very large mems are a bad idea,the mem is copied on every note on. This can cause a delay and CPU spike every time a note is pressed. So if you plan to work with large mems you should use the "mem to address" component also.

Malc has said he will try and update the Memin to use the address directly in the next update, this will solve the large mem delay and CPU spike problem but also will enable writing to the mem like you are trying to do.

[chackl]

Hello!

Nice to hear those news.

But i never could get the ASM think into my brain so i fear i will not understand that eaven if it is done in a shematic.

Would it be possible if you culd show here a litte example with asn where you have a module with those conectors:

Value (Input of Stream and value to set on index)
Index (Stream index of MEM)
Mem Adress (As got out of the next module)
Mem Length (As got out of the next module)


Geting Data by Readout will be simple i think

What i wanted to do is to get a new version of the Unison MIDI to Poly, that i did years ago.
The problem was, that the OSCs will save CPU if they are combined within one polystream. But everything after an OSC would bloat up the CPU because it also calculates each ADSR and each filter too often.

If you could show her a little example it would be to nice

Regards, C.Hackl

[Exo]

Combining into one poly stream is technically possible I think but not so simple to do. It would require having two midi to poly modules and keeping them separate so there streams never touch, one could have the unison the other not.
It would then be a case of summing the voices for the unison and passing them into another poly stream run from the other midi to poly. I had a quick go but couldn't get anything working.

Anyway what you want is a kind of fake unison, which can be achieved by stacking multiple oscillators. I think that is the way to go for this because summing the poly streams and passing them into another poly stream is very hacky and would probably end up using more CPU than just stacking lots of oscillator manually.

[chackl]

Well - ending up with a lot of CPU was one of the last developments within this direction.
But as i saw now the minin I thought about trying it again

So mem in is not possible at the moment - so it would be quite interesting by doing that with asm and see if it would be an option for future.

Kind Regards

[KG_is_back]

You need something like this?

It uses trogs shared mem - I made it before this update, but should work with mem to pointer too (I have no way of checking I do not have the new FS update ).

In the schematic there are two completely separate poly sections.
First one has an oscillator. Output of that oscillator is written into memory at index (which is in this case the pitch)
The second poly section has memory read module, which is basically a recreation of stock wave read prim. Only difference is that it uses address and size instead of mem connection.

Note: I do not know in which format will you provide the memory size / max index. Current version uses integer input. If you use float instead, you have to disable/delete one line in the ASM code. It is marked with a note "disable this line if input size is float...". If you do not provide size at all (because for example you are certain that input index will not exceed mem size) then delete the full section that evolves maxps and minps