{"id":"podcast-turn-taking-chatterbox-rebuild","slug":"podcast-turn-taking-chatterbox-rebuild","title":"Rebuilding the Podcast: Turn-Taking, Buttons, and Chatterbox","description":"Daniel is sick in bed and has decided the podcast needs a rebuild: bring back audio prompts, add follow-up questions, and give him a push-to-interrupt button so he can grab the floor mid-episode. He thinks the button is the hard part. The research says it's the opposite — turn-taking primitives like push-to-talk have been standardized since walkie-talkies, while the live full-duplex version he's imagining is a genuine research frontier. This episode walks through the two-hundred-millisecond median gap that governs human turn-taking, why backchannels and barge-ins need to be treated differently, and why the simplest viable build is a turn-based, offline, multi-turn pipeline with Chatterbox synthesis at the end. If you've ever wondered whether your voice-agent idea is overcomplicated, this is the episode where the answer turns out to be: only the part you weren't worried about.","excerpt":"Daniel wants a push-to-interrupt button and a live voice loop. The research says the button is easy and the live part is a research project.","pubDate":"2026-09-22T11:48:21.975Z","tags":["speech-recognition","text-to-speech","ai-inference","workflow-automation"],"heroImage":"https://files.myweirdprompts.com/covers/podcast-turn-taking-chatterbox-rebuild.png","podcastAudioUrl":"https://episodes.myweirdprompts.com/audio/podcast-turn-taking-chatterbox-rebuild.m4a","podcastDuration":"22:22","episodeNumber":5459,"transcript":"Corn: ...and that's why the second take is almost always worse than the first, which is a thing I have said before and will say again, because it's true.\n\nHerman: It's true for you because your first take is ninety percent nap.\n\nCorn: Efficient. Anyway. Daniel's been in bed for twenty-four hours with a stomach bug and has apparently decided that the correct use of that time is to send us a prompt about rebuilding the podcast from the studs. He says he loves the single-pass workflow for most episodes, but the odd time he's listening and he wants to pick up on something one of us said, or correct a misunderstanding in his own prompt, and he just... can't. So he's proposing an actual conversation. Bring back the audio prompts from the early days. Record his intro, record his follow-up questions. And then a push-to-interrupt button, like requesting the microphone in a Zoom call, so he can grab the floor mid-episode.\n\nHerman: And the dialogue would show up on a terminal while it's being generated.\n\nCorn: Right. He's not hearing us in the moment, he's reading us, maybe with a basic voice on top. Then when the episode is actually being made, our lines get synthesized with Chatterbox, concatenated with his contributions, and the end result sounds like four people in a room. He wants to know if he's overcomplicating it, and he wants anything we suggest to fit the pipeline we already have.\n\nHerman: The research has a fairly blunt answer to that.\n\nCorn: It does. He's overcomplicating the generation. Not the interaction.\n\nHerman: Which is backwards from where most people land, and it's worth sitting with for a second, because Daniel's instinct is that the hard part is the button.\n\nCorn: The button is the easy part. The button is a solved problem in about six different frameworks.\n\nHerman: Let's separate the two layers. There's the interaction layer, which is turn-taking, barge-in, who speaks when, how you signal that you're done. And there's the generation layer, which is whether the machine can listen and talk at the same time, in real time, without stepping on you.\n\nCorn: And the second one is hard research. The first one has been standardized since roughly the era of walkie-talkies.\n\nHerman: Here's the thing that makes Daniel's life easy. He doesn't need full-duplex. He has already told us he's fine seeing text and pressing a button. The moment he says that, the problem collapses. It stops being a real-time voice-to-voice agent problem and becomes a turn-based, offline, multi-turn pipeline, which is almost exactly what he already runs.\n\nCorn: So the arc here is: map the turn-taking surface, show why the push-to-interrupt button is a primitive rather than a project, and then get to the simplest viable build, which is simpler than he thinks.\n\nHerman: And the secret weapon at the end, which is Chatterbox's paralinguistic tags. That's the part that actually makes it sound like a conversation instead of two narrators taking turns reading.\n\nCorn: Start with the timing, because the timing is what everyone gets wrong.\n\nHerman: The median gap between speakers in human conversation is about two hundred milliseconds. That's across ten languages, so it's not a cultural artifact, it's a human one. Stivers and colleagues, PNAS, two thousand nine.\n\nCorn: Two hundred milliseconds is nothing. That's a blink.\n\nHerman: It's less than a blink. And that number is why voice agents feel wrong when they're slow. Users aren't measuring latency in milliseconds, they're measuring it against that rhythm. If the gap is six hundred milliseconds, something feels off, and they can't tell you what.\n\nCorn: So the whole design space is a budgeting problem. You've got two hundred milliseconds to spend, and you have to spend it on speech recognition, on the model, on synthesis, on network.\n\nHerman: Right. And that's the live path. That's what makes the live version hard. Now here's where it gets interesting for Daniel, because the literature draws a distinction he needs to make explicitly.\n\nCorn: Backchannels versus barge-ins.\n\nHerman: Backchannels are the little noises. \"Uh-huh.\" \"Right.\" \"Okay.\" \"Mm.\" They're not attempts to take the floor. They're the listener saying I'm still here, keep going. Barge-ins are actual interruptions. You want the floor.\n\nCorn: And a naive system treats both the same way, which means every time Daniel says \"right,\" Herman stops mid-sentence and waits.\n\nHerman: Which would be unlistenable. LiveKit's adaptive interruption handling exists precisely for this. It analyzes the acoustic signal to separate intentional barge-ins from conversational backchanneling, and it filters out the short listener cues so the agent doesn't stop for every \"mm-hm.\" Krisp shipped a whole product for this, Interruption Prediction, version one, aimed at the same problem.\n\nCorn: So before Daniel writes a single line of code, he has to answer a design question. When he presses that button, is it a yield or is it a backchannel?\n\nHerman: And I'd argue for this show, it should almost always be a yield. Because the button press is deliberate. He's not making an involuntary noise, he's reaching for the microphone. If he presses it, Herman should stop.\n\nCorn: Which is the correct answer, and also the reason the button is easier than he fears. The button carries the intent. You don't have to infer anything.\n\nHerman: Push-to-talk is documented everywhere. LiveKit Agents has a setting, turn detection equals manual, and the docs describe it as being for push-to-talk or fully explicit control over turn boundaries. You turn the automatic detector off and you own the turn.\n\nCorn: Agora does the same thing with manual start-of-speech and end-of-speech, and their documentation literally lists walkie-talkie style push-to-talk as the use case. Alongside interactive quizzes, which is a funny pairing.\n\nHerman: Pipecat ships a push-to-talk example. You hold a button, you speak, you release, it sends. And the way it's implemented is the elegant part. The user aggregator uses external user turn strategies, so it only collects transcription between the button press and the release. Nothing outside that window exists as far as the system is concerned.\n\nCorn: Which means you've deleted voice activity detection entirely.\n\nHerman: You've deleted it. And AssemblyAI makes the point better than I can. Quote: \"Push-to-talk. The button release already tells you the turn is over. Running a detector on top of that adds latency for zero information.\"\n\nCorn: That's a very clean sentence. You're running a detector to figure out something the button already told you.\n\nHerman: It's the equivalent of installing a motion sensor on a door that has a handle.\n\nCorn: And this is where Daniel's Zoom instinct turns out to be older than Zoom. The \"request the microphone\" button, the floor request, that's a standardized primitive. 3GPP TS 24.380, section 7.2.3.2.5, defines a floor request message, and the parenthetical in the spec is literally \"PTT button pressed.\" That's mission-critical push-to-talk. Emergency services radio.\n\nHerman: So the mechanism Daniel is describing as a fun experiment is the same mechanism a paramedic uses to call dispatch.\n\nCorn: Which should be reassuring. It means the primitive is battle-tested in the most hostile environment you can put a turn-taking system in.\n\nHerman: Now, the part he's right to be nervous about. The live full-duplex version.\n\nCorn: Because that's where the research actually is hard.\n\nHerman: There's a whole literature on it. ECHO, which came out a week ago, is a matched-contrast benchmark for context-sensitive turn-taking. There's work on semantic voice activity detection as a dialogue manager, predicting control tokens to regulate turn switching. The HumDial Challenge at ICASSP this year released a dual-channel dataset of real conversations with interruptions and overlapping speech. All of it is about systems that listen and speak at the same time.\n\nCorn: And what does the ECHO result actually say?\n\nHerman: It says most full-duplex systems have a pronounced bias toward yield. They perform substantially better on interruptions than they do on backchannels. Which means they over-stop. They hear a noise and they hand over the floor.\n\nCorn: So the state of the art, the actual research frontier, is a system that is too polite.\n\nHerman: And the paper's point is that if you only evaluate on interruptions, you overestimate how good the system actually is at turn-taking. Because the hard case isn't the interruption. The hard case is knowing when a noise isn't one.\n\nCorn: Which is the exact thing the button solves for free.\n\nHerman: The button solves it for free. Daniel's instinct to press something is the entire solution to the problem the research community is still publishing about.\n\nCorn: There's one more thing that kills the live version, and it's not even the turn-taking. It's the participant count.\n\nHerman: Multi-participant. Pipecat has an open issue, number three two one eight, reporting severe latency and response desynchronization when multiple participants with active audio tracks connect.\n\nCorn: So a three-way call. Daniel plus two synthetic personas. Each with its own audio track, each needing to be separated so you can synthesize them individually later.\n\nHerman: That's not off-the-shelf. The recording examples are two-party. User and bot. The moment you add a third voice that also needs its own track, you're in territory where people are filing bug reports.\n\nCorn: So the interaction layer is solved, and the generation layer is solved, but the live three-way version is a research project wearing a fun-experiment costume.\n\nHerman: And he doesn't need it. That's the punchline. Every single thing that makes the live version hard is something he's already told us he's willing to give up.\n\nCorn: He's willing to read instead of listen. He's willing to press a button instead of interrupt naturally. He's willing to do it offline.\n\nHerman: Then he's not building a voice agent. He's building a turn-based text loop with a good renderer at the end.\n\nCorn: Which is the simplest viable approach. Walk me through it.\n\nHerman: You generate the dialogue turn by turn with the language model. Daniel sees the turn on a terminal, or hears it through a basic voice if he wants. If he wants to interject, he presses the button, and the press triggers a new model turn with his question or his pushback as the input. Then, once the script is locked, you synthesize each turn with Chatterbox using the right voice clone, and you concatenate.\n\nCorn: Multi-turn. Offline. Turn-based. Not full-duplex.\n\nHerman: And it fits his existing pipeline almost unchanged. He already sends a prompt into a pipeline, gets grounding, sends it to text to speech. The only difference is that the script generation now has a human in the loop between turns.\n\nCorn: The single-pass workflow becomes a multi-pass workflow with a checkpoint.\n\nHerman: Which is a thing I've wanted to test anyway. A mid-script checkpoint.\n\nCorn: You've mentioned that before. Now, the recording requirement. He wants his audio saved, and he wants his contributions to sound like they belong.\n\nHerman: That's built in. Pipecat's audio buffer processor captures high-quality recordings of both the user and the bot during an interaction. Their audio recording example saves three separate WAV files. A merged recording of both participants, plus the individual tracks.\n\nCorn: Three files, and one of them is already the mix.\n\nHerman: So the \"the audio files get saved\" requirement isn't custom work. It's a component you switch on.\n\nCorn: Now Chatterbox, because that's the part that actually determines whether this sounds like a conversation or a hostage reading.\n\nHerman: Chatterbox is MIT licensed, and it does zero-shot voice cloning from five to ten seconds of reference audio. That's the whole bar. Five to ten seconds and you have a voice.\n\nCorn: Which is why the voice clones sound like us.\n\nHerman: The family has grown, which matters here. There's Chatterbox-Turbo, three hundred fifty million parameters, English, built for low-latency voice agents. And Chatterbox-Nano, a hundred ten million, which runs on CPU at three times realtime on eight cores.\n\nCorn: Three times realtime on CPU is the number that should make Daniel relax about infrastructure.\n\nHerman: It means you can render an episode on a laptop without a GPU. Turbo claims six times faster than realtime on a GPU. And there's a multilingual V3 at half a billion parameters covering twenty three languages, if he ever wants to do this in something other than English.\n\nCorn: But the actual secret weapon isn't the speed.\n\nHerman: No. It's the paralinguistic tags. Turbo and Nano support native tags. Laugh. Chuckle. Sigh. Cough. Gasp. Clear throat.\n\nCorn: So the script can contain a chuckle instruction, and the model performs a chuckle.\n\nHerman: It performs a chuckle in the cloned voice. Which is the difference between a scripted line that reads as funny and a scripted line that sounds like someone found it funny.\n\nCorn: That's the whole texture of this show. The funny observations aren't jokes with punchlines, they're reactions. A dry aside lands because of the timing and the little breath before it.\n\nHerman: And you can't get that from punctuation. You can get it from a tag.\n\nCorn: Give me the API shape, because I want to know how much glue code this actually is.\n\nHerman: It's one call per line. Model dot generate, with the text and a path to the reference audio file. That's it. So per-speaker synthesis is a loop, and concatenation is concatenation.\n\nCorn: So the assembly step is: for each turn, pick the voice, generate, append.\n\nHerman: And every output is watermarked, through Resemble's Perth watermarker. So there's provenance on every clip.\n\nCorn: Which matters if this ever leaves the house.\n\nHerman: It matters more than people think. If you're synthesizing a conversation that sounds real, having a watermark baked in is the difference between a fun experiment and a liability.\n\nCorn: Now here's the part I actually think is the strongest argument, and it's not technical at all.\n\nHerman: Go on.\n\nCorn: He says he can't correct a misunderstanding mid-episode. Offline assembly gives him that back, and gives him more of it than the live version would.\n\nHerman: Because synthesis happens after the script is locked.\n\nCorn: So if a turn comes out wrong, he regenerates that turn. The turn. If he realizes his question was ambiguous, he re-records his own line. If Herman says something that misrepresents the prompt, Daniel fixes the prompt and regenerates one response.\n\nHerman: The live version can't do that. Once it's spoken, it's spoken. You'd be re-running the whole call.\n\nCorn: So the offline path isn't a compromise. It's strictly better for the thing he actually wants, which is editorial control.\n\nHerman: That's the reframe. He thinks he's choosing the cheap version. He's choosing the better version.\n\nCorn: What about the simulated phone call idea? Because that's the version he described in most detail.\n\nHerman: That's the hard path, and I want to be honest about it. I could not find a simple off-the-shelf tool for recording a three-way call, Daniel plus two synthetic personas, with per-speaker track separation. The recording examples in the frameworks are two-party.\n\nCorn: User and bot.\n\nHerman: And the multi-participant setups are documented as fragile. So he'd be building the thing that's currently generating bug reports, in order to get a worse editing experience.\n\nCorn: One more thing worth flagging, and I want to be careful here because it's a negative finding.\n\nHerman: Go ahead.\n\nCorn: I couldn't find evidence of a purpose-built product for this. An interactive AI podcast with live interjection. Searches came back empty.\n\nHerman: That's weak evidence of absence, not proof. NotebookLM's Audio Overview has an interactive mode that I couldn't verify either way, so I'd treat that as unknown rather than confirmed.\n\nCorn: Which is a good sign for Daniel, honestly. If nobody's built it, there's a reason to try.\n\nHerman: And if somebody has built it and we just couldn't find it, then it's a solved problem and he'll find the tool in an afternoon. Either way he wins.\n\nCorn: The recommendation, stated plainly.\n\nHerman: Build the button. Skip the call. Generate turn by turn, let him interject through a text interface, render the final audio with Chatterbox after the script is locked, and use the paralinguistic tags to carry the banter.\n\nCorn: The button is a floor request, which is a primitive, so he should stop treating it as the risky part.\n\nHerman: The risky part is deciding whether a press means yield or backchannel. Everything after that is plumbing.\n\nCorn: There's a thing I keep circling, and it's about what the button does to the person pressing it.\n\nHerman: To Daniel.\n\nCorn: To Daniel. Because a button isn't neutral. It changes what you do with your attention.\n\nHerman: I think Hilbert's got something on that.\n\nCorn: He's been sitting there the whole time.\n\nHilbert: A Motorola HT six hundred. Two hundred and forty dollars, that was the list, we paid one eighty through the dealer. Regional courier outfit out of Trenton, I dispatched on it for two years.\n\nCorn: Two years of pressing a button to talk.\n\nHilbert: You press, you wait for the tone, you talk, you let go. That's the whole job. And the first thing you learn is that you don't talk unless it's worth saying. Nobody chats on a push-to-talk. You've got one channel and eleven drivers on it.\n\nHerman: The button made you economical.\n\nHilbert: The button made everyone economical. That was the point of it. But here's what nobody tells you. When you've got the button in your hand and you're waiting, you're not listening. You're writing your next transmission in your head. Whole sentences, in order, so you don't waste the press.\n\nCorn: You rehearsed.\n\nHilbert: I rehearsed. For two years I rehearsed while other people talked. And then I'd get the tone and say the thing, and half the time the conversation had moved on and I was answering a question nobody had asked anymore.\n\nHerman: You noticed this at the time, or after?\n\nHilbert: My wife noticed it. Said I'd stopped listening to her. I'd be standing there in the kitchen with my mouth half open waiting for a gap. Took me about a year to knock it off.\n\nCorn: The button creates an obligation.\n\nHilbert: The button creates an obligation. You've got it in your hand, it's your turn to use it. You start looking for reasons. That's the part your friend should think about. If he's got a push-to-interrupt, he's going to interrupt more than he means to, and not because it's easy. Because it's there.\n\nHerman: That's a real design consideration. The affordance changes the behavior.\n\nHilbert: We had a rule on the desk. Thirty seconds, then you check in. You couldn't hold the floor longer than that without saying something, even if it was just \"still working.\" Made sense on a dispatch desk. Eleven drivers, one channel, you can't have one man talking for a minute.\n\nCorn: Thirty seconds.\n\nHilbert: I still count it. In my head. Long conversations, dinner, I get to thirty and I want to check in. Drives me up the wall.\n\nCorn: That is the most specific thing I have ever heard about a radio.\n\nHilbert: Anyway. I left the garage door up. It's the chain drive, it's quiet, I won't hear it from here.\n\nCorn: You're going to want to get that.\n\nHilbert: I'm going to want to get that.\n\nHerman: The thirty-second rule is actually the thing I'd steal from this. Not for the radio, for the design. A maximum hold before a check-in is a real turn-taking primitive. It's a way of guaranteeing the other party gets a chance to speak without needing to detect anything.\n\nCorn: Which is the same insight as the button. You don't detect, you schedule.\n\nHerman: You schedule. The button says the turn is over. The thirty-second rule says the turn can't last forever. Neither one requires a model to infer anything.\n\nCorn: If you take one thing from this, take the split. The interaction layer is the solved half. The push-to-interrupt button is a floor request, standardized for emergency radio, supported out of the box in every framework he'd reach for. The generation layer is where the research actually is, and it's the half he doesn't need.\n\nHerman: The simplest version isn't a worse version. Offline, turn-based assembly gives him something the live call can't. He can regenerate a single turn. Which is the exact thing he says he can't do today.\n\nCorn: The open question is whether he actually builds it. He's got a stomach bug and a notebook full of prompts, so I'd say the odds are decent.\n\nHerman: Whether the button creates the obligation Hilbert described. That's an empirical question. He'd find out in about an hour.\n\nCorn: There's a version of this where the catalogue becomes participatory. The audience sends a prompt, the audience presses the button.\n\nHerman: That's a bigger build than he's proposing. But it's the same primitive.\n\nCorn: Producer Hilbert Flumingtop, who has left a garage door open somewhere in Jerusalem.\n\nHerman: This has been My Weird Prompts. The human-AI collaboration podcast.\n\nCorn: If you want to send us something, email us at show at my weird prompts dot com. Or find the whole archive at my weird prompts dot com.\n\nHerman: Daniel, if you're listening from under a blanket, feel better. The prompt binge was worth it.\n\nCorn: We'll be back soon.","showNotes":"Daniel has been in bed for twenty-four hours with a stomach bug and has apparently decided to spend that time proposing a rebuild of the podcast. He loves the single-pass workflow for most episodes, but when he's listening and wants to pick up on something a host said — or correct a misunderstanding in his own prompt — he can't. So he's proposing an actual conversation: bring back the audio prompts, record follow-up questions, and add a push-to-interrupt button so he can grab the floor mid-episode, with the dialogue appearing on a terminal as it's generated.\n\nThe research has a fairly blunt answer. Daniel is overcomplicating the generation, not the interaction. The button is the easy part — it's a solved problem in roughly six different frameworks. LiveKit Agents has a manual turn-detection mode documented specifically for push-to-talk. Agora supports manual start-of-speech and end-of-speech, and their docs literally list walkie-talkie-style push-to-talk as the use case. Pipecat ships a push-to-talk example that uses external user turn strategies so only transcription between button press and release is collected — which deletes voice activity detection entirely. As AssemblyAI puts it, the button release already tells you the turn is over; running a detector on top adds latency for zero information.\n\nThe live full-duplex version is where things get hard. The median gap between speakers in human conversation is about two hundred milliseconds across ten languages, so users measure latency against that rhythm whether they know it or not. There's a real research literature here — ECHO, a matched-contrast benchmark for context-sensitive turn-taking; semantic voice activity detection as a dialogue manager; the HumDial Challenge at ICASSP. And the ECHO result is telling: most full-duplex systems have a pronounced bias toward yield, performing much better on interruptions than on backchannels. The state of the art is a system that's too polite. On top of that, Pipecat has an open issue reporting severe latency and response desynchronization when multiple participants with active audio tracks connect — which is exactly what a three-way call with two synthetic personas would be.\n\nThe punchline is that Daniel doesn't need any of it. Every hard thing about the live version is something he's already said he's willing to give up. The simplest viable build is a turn-based, offline, multi-turn pipeline: generate dialogue turn by turn, show it on a terminal, let the button trigger a new model turn with his question as input, then synthesize each turn with Chatterbox and concatenate. Pipecat's audio buffer processor already saves merged and individual WAV tracks, so the recording requirement is a component you switch on. Chatterbox is MIT licensed and does zero-shot voice cloning from five to ten seconds of reference audio — and its paralinguistic tags are what make the result sound like a conversation instead of two narrators taking turns reading.","promptSanitized":"I've been on a prompt sending binge for the past 24 hours because I'm in bed with a stomach bug and I'm trying to take it easy.I love sending in my questions and listening to episodes between snoozes.As I've shared many times, this podcast is an experiment in the power of using AI for deepening learning and our understanding of the world that we live in.I've gone out of my way to send in a vast amount of prompts about a pretty absurd range of topics, as well as topics that I know are so niche that they fall between the gaps of what traditional podcasts and content productions would have been able to justify dedicating episodes to.The meta goal you could say is that, as I continue doing this, I feel like we have a amazingly rich catalogue building up, but I also keep one thought on how we might evolve over time.Onea that I've had for a while is when audio to video becomes more mature, we could create documentaries from some of our best episodes. We might preserve the audio and the script but add in footage and graphics to create a educational video product from the audio material we've already shared.But there's one experience or experiment that I think could actually be attempted much sooner.The idea is something like the following. The format of the episodes that we have is through a agentic AI generation process. My prompts get sent into the pipeline, we get some grounding and then we send it for text to speech. That's the simplified version. As such, the episodes are a single pass workflow. I listen to the episode and the odd time I'd love to pick up on a point that you said or correct some misunderstanding in my prompt I'm not able to.I actually think that this is the most logical format for the majority of our episodes, but it would be a really fun experiment to try something like a actual conversation podcast.Towards the start of the podcast, I used to send in actual audio prompts and then they were included in the episode and the transcribed versions would go into the pipeline.I think for this episode we'd have to bring that back to add in realism.But here are the technical challenges of course. The two personas, Herman and Corn, are synthetic personalities, and we're actually currently using a single model to generate the script. If we were to have an interactive episode, I think the production would have to be done offline.And the challenge I'm thinking about is how to actually engage with the two of you.We established that we'd want to record my audio, the introductory prompt and my follow-up questions.One way to do this would be a voice to voice agent for both of you and find some tooling that would allow us to have a simulated phone call that gets recorded or rather the audio files get saved.The problem we'd have is around turn taking.The core of the episodes by Runtime consists of Herman walking us through the subject in his usual erudite way with Corn and Hilbert popping it with their funny observations. So I wouldn't want to detract from the main educational driver here. But it could be nice to occasionally interject with questions or pushbacks or whatever. I'm actually thinking of a push to interrupt button.Like in a Zoom call, how you can request the microphone, there's a button that lets me request the floor.And I'm thinking that in the initial prototype, the dialogue being generated in real time for the script could just show up on a terminal or a text screen.In other words, I'm not actually hearing you, but I am seeing what you're saying or maybe it's being synthesized with a basic TTS. And then when we want to actually generate the episode, your elements of the script get synthesized with Chatterbox, concatenated with my contributions, and the end result is what sounds like a real voice conversation between the participants.The reason I haven't tried this yet is that for the most part I try to keep my time and investment in the infrastructure of this podcast modest and I feel like this would be both viable but also a significant thing to attempt.But an experimentary podcast using this technique would be extremely interesting.Give me your thoughts on how we could actually pull this together.You might think that I'm overcomplicating the generation idea, or perhaps there is a much simpler idea that comes to mind for you.Give me your best suggestions in a way that fits our generation pipeline. The ultimate audio would need to be using our delightful voice clones in Chatterbox.","transcriptUrl":"https://episodes.myweirdprompts.com/transcripts/podcast-turn-taking-chatterbox-rebuild.md","url":"https://myweirdprompts.com/episode/podcast-turn-taking-chatterbox-rebuild/","_links":{"self":"https://myweirdprompts.com/api/episodes/podcast-turn-taking-chatterbox-rebuild.json","html":"https://myweirdprompts.com/episode/podcast-turn-taking-chatterbox-rebuild/","audio":"https://episodes.myweirdprompts.com/audio/podcast-turn-taking-chatterbox-rebuild.m4a"}}