OK thanks!
I posted this earlier Python call to Fortran DLL crashes on array bounds fail - Stack Overflow
basically if I send in an array with more than 9 elements then it blows up, less than 9 then I get something sane back (haven't attempted to verify the values yet)
If I change the calling code to vary the value for n independent of the array size then I can get the call to complete though it returns garbage (i.e. a load of NaNs)
I then created a dummy FFT subroutine using the same interface to just dump out the values
Code:
subroutine FFT(data, len)
! Variables
REAL(8), intent(in):: data(len)
integer(4), intent(in):: len
! Body of Test
Print*, 'len: ', len
Print*, 'size:', size(data)
do i = 1, len
Print*, 'i:', i, ' d:', data(i)
enddo
return
end subroutine FFTcompiled using mingw/gfortran
Code:
gfortran -shared -static -fPIC Test.f90 -o Test.dlland ran it against the same python code, works fine
Code:
len: 20
size: 20
i: 1 d: 0.0000000000000000
i: 2 d: 1.0000000000000000
i: 3 d: 2.0000000000000000
i: 4 d: 3.0000000000000000
i: 5 d: 4.0000000000000000
i: 6 d: 5.0000000000000000
i: 7 d: 6.0000000000000000
i: 8 d: 7.0000000000000000
i: 9 d: 8.0000000000000000
i: 10 d: 9.0000000000000000
i: 11 d: 10.000000000000000
i: 12 d: 11.000000000000000
i: 13 d: 12.000000000000000
i: 14 d: 13.000000000000000
i: 15 d: 14.000000000000000
i: 16 d: 15.000000000000000
i: 17 d: 16.000000000000000
i: 18 d: 17.000000000000000
i: 19 d: 18.000000000000000
i: 20 d: 19.000000000000000I imagine I'm missing some particular incantation (to do with memory layout perhaps) but working out which one(s) are required is a bit of a wild goose chase (on unknown unknowns grounds)
I spent a bit of time attempting to write a fortran wrapper (to see if that made a difference) but that went into the weeds extremely quickly
I'll probably try creating a f2py wrapper using this interface spec next to see if that produces a different result (as I have now determined that it is possible to use f2py with compiled code and a hand crafted interface spec)
Last edited:
I suppose an alternative answer is that the subroutine expects data of certain sizes only. This would explain why I could get it to return when manipulating the value for n (and that did seem happy when n was 16 or 32). @gedlee any expectations like this in the code? What is the expected (real) input data here?
IME the first is likely as for speed only large prime factors seriously affect speed, 3, 5 , and 7 cover all the audio sampling rates and I have never experienced any issues.
Unfortunately the algorithms were presented within a few years of the Cooly-Tucky paper but did not get widely adapted. Now every major math package has arbitrary N FFT's. There is absolutely no noticeable speed hit for 44100 or 96000 FFT's vs 65536 and having exact 1Hz bins makes life so much easier.
ok so that is that mystery solved then, I will pad with zeroes (unless there is some other approach that is recommended).
now onto the next call, you described LinToLog as
Code:
DataIn, & ! FFT data in at all angles
DeltaF, & ! the frequency delta
NumFFTPts, & ! the number of FFT points
Dataout, & ! The interpolated log frequency output
NumLogPts, & ! the number of data points being output
Freqs ) ! the Array of output frequenciesDataout is the only one marked as intent(out), the rest are intent(in)
I can see that DataIn, NumFFTPts and DeltaF will come from the input data and that Dataout will need to be allocated by me, passed in and used for the return value
I don't understand where NumLogPts and Freqs comes from though. Your previous post said
which I took to mean the subroutine will calculate the correct log spacing for you, i.e. NumLogPts and Freqs would be intent(out)
Can you explain how to call this please?
Yes, Freqs would be Intent(out). I never did see the point of "intent" since it makes no difference what you set it at.
I suppose it would be useful, but I'd like to see some movement on the GUI as well. I am unsure about doing/showing too much until I see some progress on the GUI. Being able to call the DLL is a baby step.
right ok, are there any constraints on the value for NumLogPts? like a max of x per octave or anything like that
ok sure. This leads to the Q of what to start with in the gui. Are these two subs sufficient to produce an FR chart? For example, one could take http://www.gedlee.com/downloads/12901140.txt as in input and produce a chart with a series of curves on it?
If not, what direction do we want to go in?
I usually use 200 log points as anything higher just didn't seem to make any difference. So stick with 200 or less and there won;t be a problem. I am not sure what the upper limit is however.
You could use that data.
1) read in the impulses
2) plot them
3) set a window
4) find the linear FR with the FFT (use DLL)
5) transform the linear set to log (Use DLL)
6) plot this data as a set of 13 curves
All of the above steps are required to get a modal radiation model and so the code up to this point would be the same as the full program. Once we have step 6 in place then I will specify how to go from the data in 6 to a modal model for the full far field data.
We would still need to decide what technique to use for the LFs. There are several option. I did not worry too much about the FR below about 200 Hz since this is room dependent anyways and if multiple subs the LF response of the mains is not really much of a factor. So I just used a simple LF model based on the Q of the woofer and its resonance in a closed box. This model is already in the code but doesn't work for ported or dipole systems.
They will be open source for sure, I was thinking of giving pyqtgraph a go (PyQtGraph - Scientific Graphics and GUI Library for Python) and hence using Qt for the GUI
Last edited:
In my experience, no package offers EXACTLY what you will want. I used them for about 10 years and then just gave up and wrote all my own from primitives like DrawLine, ext. That gave me the graphics that I wanted. They may work for early development, but I do not see them working for the end product.
Looking at that exact package, looks far more capable than most. Still won't do what I envision as I stated before. (By that I mean that I previously gave a description of how I thought the GUI should look.)
Looking at that exact package, looks far more capable than most. Still won't do what I envision as I stated before. (By that I mean that I previously gave a description of how I thought the GUI should look.)
Last edited:
rolling your own gui toolkit with the software available today is something that only the most esoteric or demanding apps require. Nothing I've seen mentioned so far suggests that would be remotely necessary.
Which features (of the UI) do you think are going to a problem?
I am referring to post 170 btw for the description of a GUI - http://www.diyaudio.com/forums/soft...r-field-scanner-shoestring-4.html#post5440551
Which features (of the UI) do you think are going to a problem?
I am referring to post 170 btw for the description of a GUI - http://www.diyaudio.com/forums/soft...r-field-scanner-shoestring-4.html#post5440551
Last edited:
See post 193. If the package can do all this then we're good, but if not then I do not know what the GUI should look like. Static plots just aren't very useful when you have 3D data. You need an intuitive way to scroll through the data in real time.
Could that package do what Polarmap does now?