Rockbox

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Patches
  • Category Plugins
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by archivator - 2010-04-26
Last edited by Llorean - 2010-04-27

FS#11219 - FFT: add support for input visualization.

Initial support for showing input in the fft plugin. Now, on targets supporting recording, instead of quiting when no track is playing, fft starts monitoring the audio input (using the settings under Recording Settings).

The first patch is just the functional changes, the second patch fixes the indentation of the entire file.

I’m not sure if it works at all since I don’t have a device that can record.

Is there a prompt saying "Press select to start recording?" I think it would be a bad idea to start recording upon selection of this plugin without a confirmation of some sort - a user scrolling through the demos without music playing could very easily launch it and not realize it's created a file using up some of their disk space. Especially for players with an internal mic, where they might play with it for a while thinking it's just a demo without realizing it's also creating a file.

Who said anything about files? It works the same way pitch_detector does - record some data into memory, analyze it, rinse, repeat. Nothing is stored on disk.

I'm sorry then. "Recording" though means you'd be keeping a record of it. Listening to the mic without keeping a record would be called something else, so the description of this task does rather strongly suggest there would be a file since it says it "starts recording." Anyway, as long as it's just monitoring the mic and not recording, I don't see any problem.

I like of "recording" as the opposite of "playback". Recording - sound goes in, playback - sound goes out.

In any case, this is arguing semantics and that bit is easiest to change, really.

Yes, but for future reference "recording" means actually creating a record of something. When you're in the recording screen you're monitoring until you press a button and start recording (which includes writing to disk). While it's semantics, it's one of those things that will also need to be clear in the manual update for this, so getting the terminology right for English does matter.

I've edited the task description based on your statement that no recording occurs.

* Fix playback mode.
* Remove a blocking splash from the recording codepath! (fixes input mode slowness)
* Rename "Recording mode" to "Input mode"
* Add a brief overview of the plugin for future reference

Patch 1 is functional changes only, patch 2 fixes the indentation as well.

Rename "Recording mode" to "Input mode"
Maybe "Monitoring mode" is better?

I really have no opinion on the matter. Whatever you decide, it's a single splash that needs to be changed (line 1190 in the patched file).

I forgot to mention that this patch needs testing on devices *without recording support* (to check that my #ifdefs haven't broken basic functionality). Unfortunately, there are only 10 of these and it's too late for me to figure out which ones have what.

* Compiles on targets without recording or logf

I can't think of anything else to test, so I leave this patch in your capable hands :)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing