Is FFT broken? [FIXED]

(Read-only) To re-open a bug, start a new thread in the Bugs forum.

Moderator: MSandro

Locked
mguzdial
Posts: 70
Joined: Sep 15th, '15, 11:21

Is FFT broken? [FIXED]

Post by mguzdial » Jul 6th, '16, 19:37

I've not worked with FFT much, so I can't look at the FFT code to see if it's broken. I suspect that the FFT block is still expecting +/- 1.0, instead of +/- 32K. I've recorded a bunch of samples which I can play fine, but when I try to get the FFT of those samples, I get an error.
FFT-bug.png

mguzdial
Posts: 70
Joined: Sep 15th, '15, 11:21

Re: Is FFT broken?

Post by mguzdial » Jul 6th, '16, 20:19

Okay, I think I've verified the bug in FFT. Now that GP is delivered as an application, I've lost the ability to edit the .gp files in the runtime library to find bugs and test fixes. I edited the FFT code in the runtime lib, but the fft block was unchanged when I restarted GP. Is there some way to read the .gp files? Or are they copied somewhere in the GP application that I might still be able to edit and test them?

I was able to multiply all the samples by 32767.0 in order to test the fix, and then FFT did return something that looked right. The problem is that it's still pretty hard to do this all in blocks because arrays exist in the GP text world but not in the GP blocks world. FFT demands an array. There is no way to create an (array) in blocks. All I really needed was toArray, but it took me awhile to find that and create it. I had to make multiple roundtrips into the text definition then blockify in order to be able to debug my fix.
FFT-fix.png
FFT-fix.png (17.74 KiB) Viewed 7023 times

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Is FFT broken?

Post by JohnM » Jul 7th, '16, 13:17

Sorry about the bug with FFT. It should definitely allow you to pass a list to it!

As you noticed, the Macintosh GP app has the "lib" folder embedded in it. This makes it easier for Mac users to move, copy, or delete the GP app; the app contains everything needed to run GP (although it doesn't include optional parts such as the instrument library and the sample projects).

However, you can still explore and modify the .gp files in the lib folder. Just control-click on GP.app and select "show package contents". This will open the .app file (which is actually a folder). If you open a few levels of nested folders (Contents/MacOS/runtime), you'll find the lib/ folder with all the .gp files inside it. You can edit those and restart GP to see your changes.

Obviously syntax or logic errors can break GP, and it's a bit harder to debug such problems because the errors go into a log file, not into a terminal window (since there is no terminal window). If you plan to do a lot of hacking of the internal GP code, you could copy the entire runtime folder to your Desktop and rename it something like "Experimental GP". You could then open a Terminal, 'cd' to that folder, and run GP from the terminal like this:

Code: Select all

  ./GP lib/* -
You'll get the command prompt:

gp>

You can type "o" to the prompt to start the GP project editor. If you encounter errors, you may see some useful information in the terminal.

Note: This is the process we've used to bootstrap GP. It won't be documented or supported and eventually it will be replaced by a debugger, browser, and other mechanisms that let you modify GP from within itself (as you can do in Squeak). GP just hasn't become entirely self-supporting yet. That's one of our primary goals for this next year.

mguzdial
Posts: 70
Joined: Sep 15th, '15, 11:21

Re: Is FFT broken?

Post by mguzdial » Jul 19th, '16, 22:38

Thanks -- that worked!

It was a one-line change to AuthoringCommands.gp that let me use FFT with a list:

Code: Select all

to fftOfSamples samples {
  samples = (toArray samples)
  n = (count samples)
  if (n < 2) { return (array) }
  if (not (isPowerOfTwo n)) {
	fftSize = 2
	while (and (fftSize < 8192) ((n >= (2 * fftSize)))) {
		fftSize = (2 * fftSize)
	}
	samples = (copyFromTo samples 1 fftSize)
  }
  return (fft samples)
}

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Is FFT broken? [FIXED]

Post by JohnM » Aug 1st, '16, 14:23

This fix is in v054, along with some tweaks to the underly fft primitive. It now works with the sample range of the input data (e.g. 16-bit signed samples from the 'sound input' block) range rather than converting to -1.0 to 1.0.

Locked