FrancescoCeruti
New Feature Request: Recording Cue
This is a feature request to create a new cue type that records the audio output of both audio cues and input from audio sources (e.g., microphones). This feature would have the same "footprint" as other cues and would include the following characteristics:
- indicator light (as other cues) indicating if recording is active (red), paused (yellow), or off (dark) -VU meter (as other cues) indicating relative level of current recording -toggling icons that would also indicate record, pause and stop. -there would be no functional difference between pause and stop. When a file is paused, the indicator would be yellow and the icon would be record. If the user clicks the cue, recording continues and the icon changes to pause. If the user right-clicks the cue and selects "tag" or "publish", recording stops.
The context menu for this cue (i.e., right click) would contain the following options:
-ability to specify the file name and output path -ability to specify the audio format type (more on this below) -ability to bring up a dialog to set basic ID3 metatags on MP3 formatted files -ability to publish via FTP a completed audio file to a location specified in the cue
Supported audio formats: Two formats need to be supported - an uncompressed format (like wave or aiff, and MP3 with the the following characteristics: 44.1KHz, 128Kbps. This is because some producers will want to edit the file after the fact (hence uncompressed) and others will want to publish the file "as is" (hence MP3).
ID3 Tagging Tagging before publishing is essential as podcast syndication relies on these pieces of metadata. At a minimum, the tags that need to be supported are Title, Album Artist, Year, Number, Genre. There are a number of ID3 libraries for doing this tagging.
Publishing By far the most popular audio podcast publishing platform is libsyn (https://four.libsyn.com/). Publishing to this platform is as simple as FTPing the file to a specified location. This is the basic functionality to build - FTP to location with username and password.
While this is a good idea, and I'd like to see something like this, it's, in my opinion, a bit off the goals of LiSP, right now there're other features which have priority
That said, with the current backend, the recording can be accomplished in (at least?) 3 ways:
- Adding support for live-inputs and file-recording to LiSP while keeping mixing external:
- Adding support for live-inputs but record with and external application (or the opposite)
- Input and output are done externally (this should already be possible)
This is what we may be able to have in the future, but requires some important work on the backend, that will also give other benefits, in this case we need the ability to control the outputs with ease (start/stop/pause, volume, etc ...) via some custom UI component
Tagging/uploading can (and must) be done in a plugin @
I was thinking more in terms of this where ALSA is the mixer, LiSP provides audio cues to ALSA and remotely controls the recording software, either arecord (an ALSA kernel-level utility - VERY efficient) or Audacity via the mod-script-pipe, which is actively being developed right now in the Audacity project to enable remote control. I've gotten both of these to work with shell script cues from LiSP. A little bit of a cleaner interface would be nice and not very hard to engineer. My method doesn't appear to require any reworking of the internal pipes and leaves the heavy lifting of recording audio to be handled by other programs.