From the original SynthMaker forum (2004–2014), with its members’ names and dates.
ChrisHooker ·
I'm working on a project where I have two FFTs running simultaneously. I need to compare the values of both FFTs at specified indexes, but the FFTs do not output their results in sync.
After noticing this, I read somewhere on this forum that green data won't actually support this type of multi-stream alignment, so I attempted to create a memory buffer within a code primitive, with which I could store the values of the FFT magnitudes at each index, then run calculations on the memory indexes after they'd been stored. I can get the memory to write, but unfortunately, the memory clears after (I'm presuming) every sample. I can't create a memory or buffer ("float mem[256]" or "float buffer[256]") within a "stage(0)"... so I'm at a loss for what to do.
Anybody have any ideas?
-Chris
MichaelBenjamin ·
the stage 0 is only 1 sample long - it can be used to initialize or pre-fill a mem array with a loop, only by inside values - so it would not work to get the green array data inside the mem at stage 0 - infact its quite cumbersome to get any green array of a bigger size into the code array, also the triggering of that stage is hardwired and you cant change it.
see also here: stage 0 does not retrigger on stolen voice
so for calculations on the mem use stage 1,2 or 3. they should keep the data as long as its not overwritten or the section deactivated. the problem would still be to get the green data inside the code mem. another possibility could be - if it does not need to be sample accurate and you only want to be sure that both arrays are from the right batch - that you trigger the calculation in green as soon as both arrays are updated.
ChrisHooker ·
Hi Michael,
Thanks for your reply. I'm actually not trying to get the green array data stored into the memory at stage 0, I wanted to try to get the variable creation ("float mem[256];") performed in stage0, then to write to it and read it within stage1, as the audio is streaming...
What's happening is that when outputting, for example: mem[1], the value reverts to "0" immediately after the green array index has swithed from 1 to 2. As if the memory is being reinitialized. This is what I don't want, hence my hoping that I could put the command "float mem[256];" into a stage 0.
Let me see if I can post an .osm for ya...
Ok - in this example, I've got 2 counters running (a and b), and as they cycle from 0-3, they should write a never-changing "4" (an example magnitude) to each memory or buffer slot 0-3 while the counter displays the corresponding #. If the counter moves on to the next #, the code should in my mind just update the next memory slot... but it also wipes the previous one clean.
I originally did try to do all the calculations in green, and I got incorrect results when sending a controlled signal evenly to both FFTs. This prompted me to put readouts directly after the "Float Array Get At" primitives that follow the FFTs, and what I saw was that one array would fill up, and then the second would follow only after the first finished. I could also reverse the order of which would readout first, simply by disconnecting the readouts and then reconnecting them to the same "Get At" primitives as before, but in opposite order. (And nothing else is connected to those "Get At" outputs.)
Sound weird to you?
MichaelBenjamin ·
ok this is because of the analyzer - everytime you trigger it the whole thing gets initialized since the analyzer "plays through" what would happen in the first n samples of the code from beginning - so you also loose the mem data everytime.
to circumvent it you could build the code section in blue, so its always running and then use a mono to graph primitive - or keep it in white and then combine to blue and readout in blue - but then you need to activate the white stream with a midi note since its not persistant.
btw theres no reason to use polyin/out and monoin/out - you can always use streamin / out and then the output type adapts automatically to the connected type.
heres a blue version that keeps the data
ChrisHooker ·
Thanks again for your help, Michael.
On your blue schematic, I'm only reading "0.000000" on the text primitive connected to the mono-to-graph output. I see that you've put a note to "activate" the direct sound out to get the blue running... does this mean that it must be connected to see that text readout update? I even tried a mono readout connected to the code output, and that didn't work either.
My trouble here (of course I'm having more) is that I can't use Direct Sound in/out - I always get a CDirectSound::error. It seems to think I have another program running which is using ASIO, which I don't. (I've got a laptop PC running Windows Vista, and only the built-in realtek speakers.)
[sigh]
-Chris
trogluddite ·
Hi Chris, welcome to the forum.
Sadly, those realtek motherboard sound chips are a complete pain to use with SM. Even using the ASIO4ALL overlay driver still seems to give far too much latency on my laptop's realtek chip. Having said that, I can usually get DirectSound to function - although I'm on Win XP so maybe that makes a difference.
It may be worth trying to disable windows built in sounds from the control panel, and even disabling the Realtek mixer in the taskbar tray - sometimes that will free up the chip for SM's exclusive use.
If you can spare the cash, it's well worth buying a cheap USB sound card with a dedicated ASIO driver to use with SM - as well as sorting out the 'Driver in use' errors, it will give you much more usable latency.
MichaelBenjamin ·
you dont need to directly connect them if theres already a readout on it, just activate it. if the ds out does not work, try asio. or the asio4all driver, you need atleast some output functioning.
ChrisHooker ·
As I didn't really want to install anything else on the laptop, I tried everything else imaginable to get the Direct Sound working, all to no avail... so I took the project to one of my other PCs and it worked without a hitch. Now the code/graph output updates perfectly. Thank you so much for your help, Michael. And thanks Trog, for your input as well. 😀 😀 😀
ChrisHooker ·
Alright, I got the code section we've been working on incorporated in my project, and it works as it should - the memory slots store and read out perfectly... but the original problem still exists: the twin FFTs (one for the left channel and one for the right channel) will not output in sync. They are so far out of sync that if I trigger the calculations at the same rate as the FFTs, or even half that rate, it still gives irrational results.
Has anyone gotten stereo or dual mono FFTs to work in sync?
-Chris
MichaelBenjamin ·
i assume you mean the green analysis fft primitives. what you could do is just use 1 global ticker to trigger it. you wont have time accuracy, since thats not possible with the tickers, but atleast the calculations should happen for all connected modules at once when it happens. also the order in which you connect the triggers is often important. but you still might run into trouble with other things since the green system is unfortunately still really bad for real time accuracy. might be worth a try with one global ticker if you dont need many calculations per second.
infuzion ·
MichaelBenjamin wrote: btw theres no reason to use polyin/out and monoin/out - you can always use streamin / out and then the output type adapts automatically to the connected type.
That is true 99% of the time, though on rare occasion I do specify poly/mono so I can communicate that the Code can only be used in that section.
MichaelBenjamin wrote: You wont have time accuracy, since that is not possible with the tickers, but atleast the calculations should happen together for connected modules, in the order in which you connect the triggers in.
corrected
MichaelBenjamin ·
so if you connect the same ticker to two fft primitives is the delay of calculation constant, or is it scattered and depending on cpu load like two ticks following each other?
ChrisHooker ·
@ Michael: Yes, I do mean green FFT primitives.
...use 1 global ticker to trigger it...
I actually am doing this already. The result does seem like scattered ticks. And not an even balance either. Like I said earlier (but so you don't have to go look for it now), if I place readouts after the FFTs, when connecting a sin wave panned dead center, you can see one graph/FFT fill it's array, and only then does SM begin to fill the second array.
Is there different/better method than "going green", such as an entirely code-based FFT, that could give me the magnitude and frequency (index) that I need? I've looked for code-based FFTs on the forum, but I can't make heads or tails of them.
Thanks again.
-Chris
MichaelBenjamin ·
there is no fft for sm in code that i know off. i would guess it could be done in theory with a rather small window to some extend but would use atleast 10 times more cpu than a "real" module. since fft always introduces delay i can somewhat understand it doesnt really fit into sm sample for sample calculation principle, so there is only the green module. seems you either have to adapt to the programs shortcomings and find some other way where you dont need the timing precision or look for another program that does what you want, or wait a bit for some magic update.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker