Remove stale docs

docs/README.md

@@ -1,10 +0,0 @@
-# Pipecat Docs
-
-## [Architecture Overview](architecture.md)
-
-Learn about the thinking behind the framework's design.
-
-## [A Frame's Progress](frame-progress.md)
-
-See how a Frame is processed through a Transport, a Pipeline, and a series of Frame Processors.
-

docs/architecture.md

@@ -1,17 +0,0 @@
-# Pipecat architecture guide
-
-## Frames
-
-Frames can represent discrete chunks of data, for instance a chunk of text, a chunk of audio, or an image. They can also be used to as control flow, for instance a frame that indicates that there is no more data available, or that a user started or stopped talking. They can also represent more complex data structures, such as a message array used for an LLM completion.
-
-## FrameProcessors
-
-Frame processors operate on frames. Every frame processor implements a `process_frame` method that consumes one frame and produces zero or more frames. Frame processors can do simple transforms, such as concatenating text fragments into sentences, or they can treat frames as input for an AI Service, and emit chat completions based on message arrays or transform text into audio or images.
-
-## Pipelines
-
-Pipelines are lists of frame processors linked together. Frame processors can push frames upstream or downstream to their peers. A very simple pipeline might chain an LLM frame processor to a text-to-speech frame processor, with a transport as an output.
-
-## Transports
-
-Transports provide input and output frame processors to receive or send frames respectively. For example, the `DailyTransport` does this with a WebRTC session joined to a Daily.co room.

docs/frame-progress.md

@@ -1,46 +0,0 @@
-# A Frame's Progress
-
-1. A user says “Hello, LLM” and the cloud transcription service delivers a transcription to the Transport.
-![A transcript frame arrives](images/frame-progress-01.png)
-
-2. The Transport places a Transcription frame in the Pipeline’s source queue.
-![Frame in source queue](images/frame-progress-02.png)
-
-3. The Pipeline passes the Transcription frame to the first Frame Processor in its list, the LLM User Message Aggregator.
-![To UMA](images/frame-progress-03.png)
-
-4. The LLM User Message Aggregator updates the LLM Context with a `{“user”: “Hello LLM”}` message.
-![Update context](images/frame-progress-04.png)
-
-5. The LLM User Message Aggregator yields an LLM Message Frame, containing the updated LLM Context. The Pipeline passes this frame to the LLM Frame Processor.
-![Update context](images/frame-progress-05.png)
-
-6. The LLM Frame Processor creates a streaming chat completion based on the LLM context and yields the first chunk of a response, Text Frame with the value “Hi, “. The Pipeline passes this frame to the TTS Frame Processor. The TTS Frame Processor aggregates this response but doesn’t yield anything, yet, because it’s waiting for a full sentence.
-![LLM yields Text](images/frame-progress-06.png)
-
-7. The LLM Frame Processor yields another Text Frame with the value “there.”. The Pipeline passes this frame to the TTS Frame Processor.
-![LLM yields more Text](images/frame-progress-07.png)
-
-8. The TTS Frame Processor now has a full sentence, so it starts streaming audio based on “Hi, there.” It yields the first chunk of streaming audio as an Audio frame, which the Pipeline passes to the LLM Assistant Message Aggregator.
-![TTS yields Audio](images/frame-progress-08.png)
-
-9. The LLM Assistant Message Aggregator doesn’t do anything with Audio frames, so it immediately yields the frame, unchanged. This is the convention for all Frame Processors: frames that the processor doesn’t process should be immediately yielded.
-![pass-through](images/frame-progress-09.png)
-
-10. The Pipeline places the first Audio frame in its sink queue, which is being watched by the Transport. Since the frame is now in a queue, the Pipeline can continue processing other frames. Note that the source and sink queues form a sort of “boundary of concurrent processing” between a Pipeline and the outside world. In a Pipeline, Frames are processed sequentially; once a Frame is on a queue it can be processed in parallel with the frames being processed by the Pipeline. TODO: link to a more in-depth section about this.
-![sink queue](images/frame-progress-10.png)
-
-11. The TTS Frame Processor yields another Audio frame as the Transport transmits the first Audio frame.
-![parallel audio](images/frame-progress-11.png)
-
-12. As before, the LLM Assistant Message Aggregator immediately yields the Audio frame and the Pipeline places the Audio frame in the sink queue.
-![sink queue 2](images/frame-progress-12.png)
-
-13. The TTS Frame Processor has no more frames to yield. The LLM Frame Processor emits an LLM Response End Frame, which the Pipeline passes to the TTS Frame Processor.
-![response end](images/frame-progress-13.png)
-
-14. The TTS Frame Processor immediately yields the LLM Response End Frame, so the Pipeline passes it along to the LLM Assistant Message Aggregator. The LLM Assistant Message Aggregator updates the LLM Context with the full response from the LLM. TODO TODO: I realized I forgot that the TSS Frame Processor also yields the Text frames that the LLM emitted so that the LLM Assistant Message Aggregator could accumulate them, arrggh.
-![response end](images/frame-progress-14.png)
-
-15. The system is quiet, and waiting for the next message from the Transport.
-![response end](images/frame-progress-15.png)

docs/frame.md

@@ -1,110 +0,0 @@
-# Understanding Different Frame Types in the Pipecat System
-
-In the Pipecat system, frames are used to represent different types of data and control signals that flow through the pipeline. Understanding these frame types is crucial for working with the system effectively. This tutorial will cover the main categories of frames and their specific uses.
-
-## 1. Base Frame Classes
-
-### Frame
-The `Frame` class is the base class for all frames. It includes:
-- `id`: A unique identifier
-- `name`: A descriptive name
-- `pts`: Presentation timestamp (optional)
-
-### DataFrame
-`DataFrame` is a subclass of `Frame` and serves as a base for most data-carrying frames.
-
-## 2. Audio Frames
-
-### AudioRawFrame
-Represents a chunk of audio with properties:
-- `audio`: Raw audio data
-- `sample_rate`: Audio sample rate
-- `num_channels`: Number of audio channels
-
-Subclasses include:
-- `InputAudioRawFrame`: For audio from input sources
-- `OutputAudioRawFrame`: For audio to be played by output devices
-- `TTSAudioRawFrame`: For audio generated by Text-to-Speech services
-
-## 3. Image Frames
-
-### ImageRawFrame
-Represents an image with properties:
-- `image`: Raw image data
-- `size`: Image dimensions
-- `format`: Image format (e.g., JPEG, PNG)
-
-Subclasses include:
-- `InputImageRawFrame`: For images from input sources
-- `OutputImageRawFrame`: For images to be displayed
-- `UserImageRawFrame`: For images associated with a specific user
-- `VisionImageRawFrame`: For images with associated text for description
-- `URLImageRawFrame`: For images with an associated URL
-
-### SpriteFrame
-Represents an animated sprite, containing a list of `ImageRawFrame` objects.
-
-## 4. Text and Transcription Frames
-
-### TextFrame
-Represents a chunk of text, used for various purposes in the pipeline.
-
-### TranscriptionFrame
-A specialized `TextFrame` for speech transcriptions, including:
-- `user_id`: ID of the speaking user
-- `timestamp`: When the transcription was generated
-- `language`: Detected language of the speech
-
-### InterimTranscriptionFrame
-Similar to `TranscriptionFrame`, but for interim (not final) transcriptions.
-
-## 5. LLM (Language Model) Frames
-
-### LLMMessagesFrame
-Contains a list of messages for an LLM service to process.
-
-### LLMMessagesAppendFrame and LLMMessagesUpdateFrame
-Used to modify the current context of LLM messages.
-
-### LLMSetToolsFrame
-Specifies tools (functions) available for the LLM to use.
-
-### LLMEnablePromptCachingFrame
-Controls prompt caching in certain LLMs.
-
-## 6. System and Control Frames
-
-### SystemFrame
-Base class for system-level frames.
-
-Important system frames include:
-- `StartFrame`: Initiates a pipeline
-- `CancelFrame`: Stops a pipeline immediately
-- `ErrorFrame`: Notifies of errors (with `FatalErrorFrame` for unrecoverable errors)
-- `EndTaskFrame` and `CancelTaskFrame`: Control pipeline tasks
-- `StartInterruptionFrame` and `StopInterruptionFrame`: Indicate user speech for interruptions
-
-### ControlFrame
-Base class for control-flow frames.
-
-Notable control frames:
-- `EndFrame`: Signals the end of a pipeline
-- `LLMFullResponseStartFrame` and `LLMFullResponseEndFrame`: Bracket LLM responses
-- `UserStartedSpeakingFrame` and `UserStoppedSpeakingFrame`: Indicate user speech activity
-- `BotStartedSpeakingFrame` and `BotStoppedSpeakingFrame`: Indicate bot speech activity
-- `TTSStartedFrame` and `TTSStoppedFrame`: Bracket Text-to-Speech responses
-
-## 7. Special Purpose Frames
-
-### MetricsFrame
-Contains performance metrics data.
-
-### FunctionCallInProgressFrame and FunctionCallResultFrame
-Used for handling LLM function (tool) calls.
-
-### ServiceUpdateSettingsFrame
-Base class for updating service settings, with specific subclasses for LLM, TTS, and STT services.
-
-## Conclusion
-
-Understanding these frame types is essential for working with the Pipecat system. Each frame type serves a specific purpose in the pipeline, whether it's carrying data (like audio or images), controlling the flow of the pipeline, or managing system-level operations. By using the appropriate frame types, you can effectively process and transmit various kinds of information through your pipeline.