DSP Robotics Support

with the filter you'll still have to use two FFTs in parallel (with offset and windowing) to eliminate frequency wrapping. Just duplicate the given FFT streams in my schematic twice (including the mem creators). I suppose you know how FFT based FIR filters work. Convert the filter response into form that real numbers are even and imag are odd.
use floatarray to mem primitive and my mem to pointer to extract the pointer.

Now all you have to do is inbetween the FFT and iFFT add complex multiplication that will multiply the spectrum in second array with given response array.

I'm afraid I'm not that good. I know how to use such blocks or how to integrate them into more or less sophisticated stuff or what questions to ask if output produces something wrong, but on that particular level (building blocks) - I'm like a blind. Trog was always surprised about this paradox.

Basically, what I'd like to get may be a little bit more complicated for me than I thought.

The concept should work as a standalone (not VST), and it's a kind of batch processor.
In steps it looks like this:

1) Load wave
2) Pass through FFT/iFFT spetral filter (border frequencies are given externally)
[I guess here, wave could be sent somehow via mem connectors instead of stream/blue ones?]
3a) (somewhere here would be the decay estimator module, to get gain points of interest per filtered output)
3b) Save filtered signal to audio file
4) Return to pt (2) (at next pair of border frequencies).

As a result, there would be several audio files (1 per filtered band), background audio file (signal - all badns) and decay tables.

I'm trying to debug the thing and it keeps crashing... it makes me really pissed off

I can imagine.

BTW, I noticed, that this fft/ifft filter, when used in DAW - produces a delay on processed file. This complicates one thing for me (resulting background = signal minus all bands). I guess there is no way to compensate that issue, because some sort of serialized operations are done, but - maybe some sort of delay could be used, to set the starting point exactly at some time, so that the source signal file can be shifted manually then? Because I guess, that processing delay is fixed (FFT size dependent), just it's size is not so syncable so to speak (syncing would be required to do the mix). Thos way or is there a better one?

tester wrote:I can imagine.

BTW, I noticed, that this fft/ifft filter, when used in DAW - produces a delay on processed file. This complicates one thing for me (resulting background = signal minus all bands). I guess there is no way to compensate that issue, because some sort of serialized operations are done, but - maybe some sort of delay could be used, to set the starting point exactly at some time, so that the source signal file can be shifted manually then? Because I guess, that processing delay is fixed (FFT size dependent), just it's size is not so syncable so to speak (syncing would be required to do the mix). Thos way or is there a better one?

Well, you can always use latency compensation to inform your daw how long it takes to process the data. Your daw will automatically delay all other tracks in your project to be in sync. If you need to do that inside your schematics, simply use delays too. You'll have to first find out the exact latency... I think it was FFTsize-1

The size is somewhat... weird. If I understand correctly. at 32kpts delay would be 2x 32kpts (part A and part B) = 64kpts in samples ~1.4sec. Easy to combine with delay to get to 2sec. But the delay seems to be somewhere around 1.6sec. Well - I will need to export background separately as well. I did wanted to do this through mixing due to possible FFT artifacts.

Only the input buffering does make latency - FFT and iFFT are instant and output buffer is read instantly too...

Hi all,
As I'm just catching up, just a quick post with a few observations and little things I've discovered lately...

As has been said earlier - some real 'holy grail' stuff going on here, and hopefully, these tips will bring it closer still...

Integer -> Float -> Integer
First thing, I found a much better way in Ruby to generate the address for a Frame, which incidentally will let us pass ANY integers directly into a stream input.

...or, more generally...

If you output this value (through a float output), you can pass it into an ASM primitive. But the cool thing is that the float isn't really a float - it is the float value that has exactly the same combination of bits as the original integer.
Within the ASM, there's no need to use 'cvtps2dq' on the value, you can just treat it as an integer value, and it will be the full 32bits wide - no need to split into high and low words.
That code will work on any integer value that you want to pass into ASM.

You can do the reverse using this code...

This allows you to send an integer directly out of a stream out - read it as normal with an 'M2F', then pass it through that code, and you will recover the original 32bit wide integer.

Pack and unpack, are what is used within Ruby to pack values into a String - in this case the String is not text, merely a list of byte values (as used for passing values to Win32API etc.). Note that they operate on Strings and Arrays, hence the [brackets], and final [0] index.

Integer -> Integer
Passing integers between code blocks is simple - just pass as normal via streamouts and streamins. Mono/mono4 don't care if a value is a float or an integer, they just pass whatever pattern of bits represents the value. As long as the sent value is integer and the receiver expects an integer, the value will pass perfectly well.

You will, of course, need some kind of test that the address is valid. Easiest way is to set the streamin to zero during stage0; - then bypass the main code if the value is zero. When an actual address does get passed, it will overwrite the zero, and the address becomes valid (same applies to the Ruby generated values above).
NB - writing to a streamin is not usually a good idea!!! - this is a very special case, and doing it in other circumstances may lead to some very buggy code. Also, be aware that if you are passing multiple Ruby/green values into code/asm primitives, you can never rely on them all changing at the same time!!

Shared memory
CAN be done. It's one of things I've been working on recently. It's done using .dlls to call the Windows API to set up something called a Mapped File. Mapped files allow either a real HDD file, or a pretend 'virtual file' to have sections mapped to the local memory of multiple processes simultaneously. All processes actually see 'aliases' of exactly the same physical memory - so updates are instantaneous - and all reads/writes are to memory, so its really fast too!

There's only one fly in the ointment - I have a Ruby prototype working beautifully, successfully sending data between multiple FS instances, and to my test rig within Notepad++. However, there seems to be a problem with the Ruby Win32API module - it does not want to load properly when the project is exported.
I've done some detective work, and the files are being found, but the compiled 'C' extension that makes Win32API work (called 'DL') freezes Ruby every time. Bug report is on its way to Malc.
However, this feature would be much better implemented using the DLL embedding of the dll primitive - but I'm finding the C++ learning curve a little bit steep at the moment. I'll post a schematic soon, and maybe one of our more C++ savvy users could translate the Ruby into something usable.

Guess great minds think alike - now that I've poked about inside the schematics a bit, seems my last post is just duplicating a load of stuff that you already worked out!
Bizarre, I hadn't seen any of these posts while I was away, yet was working n just the same thing - convergent evolution I guess!