Audio recording FrameProcessor #451

adriancowham · 2024-09-10T18:46:08Z

Adds a FrameProcessor that will record a conversation between a bot and a human. The new AudioBufferProcessor is meant to be used a base class, it simply stores the conversation in a buffer. The intention is that developers can extend this class and do something interesting.

This PR also includes another FrameProcessor, CanonicalMetrics. This FrameProcessor is a concrete implementation of the AudioBufferProcessor and when the end of the call is reached, CanonicalMetrics will upload the audio to the Canonical AI platform for evaluation and metric collection.

This PR adds 2 examples in the examples directory demonstrating how to use both of the new FrameProcessors, they are in the examples/chatbot-audio-recording and canonical-metrics directories.

… buffer and another frame processor to upload audio to Canonical for evaluation and metrics collection. Examples included

kwindla · 2024-09-10T23:30:23Z

@aconchillo, I talked to @adriancowham about this via email.

There have been a number of questions in Discord about how to build a pipeline element that can record a conversation. I think it's really useful to have a standard recording capability in Pipecat that doesn't depend on a transport implementation.
Canonical's new evals/observability platform for voice AI is really cool! Adrian's colleague Tom did a demo at the event last night in SF.

aconchillo · 2024-09-10T23:52:31Z

@aconchillo, I talked to @adriancowham about this via email.

There have been a number of questions in Discord about how to build a pipeline element that can record a conversation. I think it's really useful to have a standard recording capability in Pipecat that doesn't depend on a transport implementation.

Canonical's new evals/observability platform for voice AI is really cool! Adrian's colleague Tom did a demo at the event last night in SF.

This is fantastic. I'll review as soon as I can!

aconchillo · 2024-09-10T23:56:15Z

src/pipecat/processors/audio_buffer_processor.py

+        self.num_channels = None
+        self.sample_rate = None
+        self.assistant_audio = False
+        self.user_audio = False


Please, use private fields (single underscore) so it's clear we don't expose this. 🙏

If we expose them, we could use properties instead.

aconchillo · 2024-09-10T23:57:50Z

src/pipecat/processors/user_marker_processor.py

+    This class extends FrameProcessor, used to mark the user's audio in the pipeline.
+    This FrameProcessor must be inserted after transport.input() so that the only
+    AudioRaw it receives are from the user.
+    """


In theory this is not needed. All the audio coming from transport.input() is from the user. I believe what you have done in AudioBufferProcessor by checking UserStartedSpeaking and UserStoppedSpeaking should be enough.

@aconchillo I can get this to work by only using UserStartedSpeaking and UserStoppedSpeaking but there is an longer than delay between when the assistant finishes and the human starts. This delay does not reflect what happened reality. I'm pretty sure it's because audio from the user's mic is coming in and since there's no way to differentiate it, it gets added to the buffer while the assistant is talking. That is, the amount of extra delay added is the amount of time the assistant is speaking because all that silence from the user's mic is coming in and getting added to the buffer. There's a small mention of this in the discord, here: https://discord.com/channels/1239284677165056021/1278753324274814977/1279769874482204814

I'm happy to try an alternative implementation, but this is the best one I could come up with. The inflated delay is pretty bad, I don't think it would lead to usable feature.

Let me know your thoughts.

So weird.... I'll take a look again.

Oh, duh! Yes, of course! I'm working on a PR that will make this easier. We will no need for a UserMarkerProcessor, the incoming audio frames will have different types. Please, bear with me!

Just for others who find this.... The reason this happens is because of this DailyParams:

vad_audio_passthrough=True, vad_analyzer=SileroVADAnalyzer(), transcription_enabled=True,

The STT will happen on the Daily server so really no audio would be required in the pipeline. However, since we want to save the audio we have vad_audio_passthrough which continuously pushes audio frames.

aconchillo · 2024-09-10T23:58:36Z

src/pipecat/processors/canonical_metrics_processor.py

+                    raise e
+                self.audio_buffer = bytearray()
+
+    def get_output_filename(self):


Nit: add underscore to all private functions. 🙏

aconchillo · 2024-09-11T00:00:07Z

src/pipecat/processors/canonical_metrics_processor.py

+        super().__init__()
+        if not os.environ.get("CANONICAL_API_KEY"):
+            raise ValueError(
+                "CANONICAL_API_KEY is not set, a Canonical API key is required to use this class")


Could we pass api_key: str to the constructor instead? This is the approach we take in many other services. Form outside you can do os.environ.get("CANONICAL_API_KEY") or get it from somewhere else.

aconchillo · 2024-09-11T00:00:41Z

src/pipecat/processors/canonical_metrics_processor.py

+    def request_headers(self):
+        return {
+            "Content-Type": "application/json",
+            "X-Canonical-Api-Key": os.environ.get("CANONICAL_API_KEY")


If we follow my other comment here we would do self._api_key.

aconchillo · 2024-09-11T00:01:23Z

src/pipecat/processors/canonical_metrics_processor.py

+        return f"{self.output_dir}/{timestamp}-{uuid.uuid4().hex}.wav"
+
+    def canonical_api_url(self):
+        return os.environ.get("CANONICAL_API_URL", "https://voiceapp.canonical.chat/api/v1")


Same to api_key, we could probably add this to the constructor defaulting to "https://voiceapp.canonical.chat/api/v1"

aconchillo · 2024-09-11T00:02:30Z

src/pipecat/processors/canonical_metrics_processor.py

+            'assistantSpeaksFirst': self.assistant_speaks_first
+        }
+        print(f"Requesting presigned URLs for {numparts} parts")
+        async with aiohttp.ClientSession() as session:


In many other services we pass aiohttp_session as an argument so we can provide an external session and we don't have to create it every time.

aconchillo · 2024-09-11T00:03:24Z

src/pipecat/processors/canonical_metrics_processor.py

+                json=params
+            ) as response:
+                if not response.ok:
+                    raise Exception(f"Failed to get presigned URLs: {await response.text()}")


Here we could use logger.error and return so the bot doesn't stop working.

Mmm... I actually think we capture the exception upstream, so maybe this is OK. I'll double-check

aconchillo · 2024-09-11T00:07:39Z

src/pipecat/processors/canonical_metrics_processor.py

+    async def process_frame(self, frame: Frame, direction: FrameDirection):
+        await super().process_frame(frame, direction)
+        if self.end_of_call:
+            return


We should not get anything after an EndFrame or CancelFrame so we probably don't need end_of_call.

Done. I thought I saw a case where I was getting both of them.

aconchillo · 2024-09-11T00:12:55Z

src/pipecat/processors/audio_buffer_processor.py

+        # mic is always coming in. if we include all the user's audio there will be a long latency before
+        # the user starts speaking because all of the user's silence during the assistant's speech will have been
+        # added to the buffer.
+        if isinstance(frame, UserAudioFrame) and self.user_audio:


It seems this should be enough:

if isinstance(frame, AudioRawFrame) and self.user_audio:

@aconchillo Gonna leave this one for now until we figure the latency issue described above.

aconchillo · 2024-09-11T00:14:20Z

src/pipecat/processors/audio_buffer_processor.py

+        if (
+            isinstance(frame, AudioRawFrame)
+            and not isinstance(frame, UserAudioFrame)
+        ):


Maybe:

if isinstance(frame, AudioRawFrame) and self.assistant_audio:

@aconchillo Gonna leave this one for now until we figure the latency issue described above.

aconchillo · 2024-09-11T00:20:01Z

src/pipecat/processors/audio_buffer_processor.py

@@ -0,0 +1,75 @@
+from pipecat.frames.frames import (AudioRawFrame, BotStartedSpeakingFrame,


It'd be great if we could move this to src/pipecat/processors/audio.

aconchillo · 2024-09-11T00:37:03Z

src/pipecat/processors/canonical_metrics_processor.py

+"""
+
+
+class CanonicalMetrics(AudioBufferProcessor):


I feel maybe this could be probably an AIService instead and we should then pass the AudioBufferProcessor as an argument.

So:

class CanonicalMetricsService(AIService): def __init__(self, audio_bufer_processor: AudioBufferProcessor, ...): ...

So CanonicalMetricsServices would live in src/pipecat/services with this approach. Another benefit is that you could then use any other AudioBufferProcessor implementation.

The only thing is that you then need to put both processors in the pipeline. But it's probably fine. So,

Pipeline([transport.input(), audio_buffer_processor, canonical, ....])

Actually, that would also allow other processors in the pipeline to use the audio_buffer_processor.

WDYT?

I like it. I'll make the change.

Awesome! Thank you. Looking great!

adriancowham · 2024-09-12T22:40:34Z

@aconchillo Thanks for the thoughtful feedback. I'll start working on this.

adriancowham · 2024-09-16T04:03:41Z

@aconchillo I pushed the changes from your feedback. I left you a comment, let me know what you think.

aconchillo · 2024-09-16T18:30:32Z

src/pipecat/processors/audio/audio_buffer_processor.py

+        self._sample_rate = None
+        self._assistant_audio = False
+        self._user_audio = False
+        print(f"ctor::AudioBufferProcessor object memory address: {id(self)}")


Use loguru logger if you need to log anything. 🙏

My fault, I left a debug print statement in there. Fixed.

aconchillo · 2024-09-16T18:33:48Z

@aconchillo I pushed the changes from your feedback. I left you a comment, let me know what you think.

This looks great! I'll take a final look later today/tomorrow max.

adriancowham · 2024-09-17T00:44:51Z

No rush.

aconchillo · 2024-09-20T06:00:54Z

This is the PR that I'll probably merge: #480

You will not need the additional UserMarkerProcessor and you will need to check for InputAudioRawFrame instead.

adriancowham · 2024-09-20T17:19:38Z

Ok, sounds good. That's a massive PR, nice work on that! I'll keep my eye out for the merge and then update my PR.

aconchillo · 2024-09-20T21:46:27Z

Ok, sounds good. That's a massive PR, nice work on that! I'll keep my eye out for the merge and then update my PR.

This is now merged. I'll take a final look once you update. So excited to get this one in as well. Thank you for your patience!

aconchillo · 2024-09-23T18:41:24Z

Another massive PR went in to use Ruff as our formatter. Please, rebase and make sure the pipeline is green. I'll merge after that. Thank you! 🙏

cyrilS-dev · 2024-09-29T15:34:13Z

hey @aconchillo @adriancowham i did some test on my side, using InputAudioRawFrame & OutputAudioRawFrame
About the input :

async def process_frame(self, frame: Frame, direction: FrameDirection):
        await super().process_frame(frame, direction)
        
        if isinstance(frame, UserStartedSpeakingFrame):
            self._human_speaking = True
        elif isinstance(frame, UserStoppedSpeakingFrame):
            self._human_speaking= False
        elif isinstance(frame, InputAudioRawFrame) and self._human_speaking :
            self.audio_buffer.extend((frame.audio))
        
        await self.push_frame(frame, direction)

is a wrong approach, because the VAD latency causes the beginning of the input audio to be missing for a few milliseconds.

It means the input audio has to be recorded continuously, while the output audio is only recorded when the bot is speaking.

This creates a problem when combining the input and output audio, making the process more complicated.

@aconchillo Do you have any insights? thanks

aconchillo · 2024-09-30T05:11:02Z

hey @aconchillo @adriancowham i did some test on my side, using InputAudioRawFrame & OutputAudioRawFrame About the input :
async def process_frame(self, frame: Frame, direction: FrameDirection):
        await super().process_frame(frame, direction)
        
        if isinstance(frame, UserStartedSpeakingFrame):
            self._human_speaking = True
        elif isinstance(frame, UserStoppedSpeakingFrame):
            self._human_speaking= False
        elif isinstance(frame, InputAudioRawFrame) and self._human_speaking :
            self.audio_buffer.extend((frame.audio))
        
        await self.push_frame(frame, direction)
is a wrong approach, because the VAD latency causes the beginning of the input audio to be missing for a few milliseconds.

It means the input audio has to be recorded continuously, while the output audio is only recorded when the bot is speaking.

This creates a problem when combining the input and output audio, making the process more complicated.

@aconchillo Do you have any insights? thanks

You are right, it would be a few milliseconds off. One solution is to keep, for example, a 1 second buffer. When you get the VAD event you just grab VADParams.start_secs from that buffer (maybe a bit more) and then start appending as we do now.

cyrilS-dev · 2024-09-30T21:07:19Z

hey @aconchillo @adriancowham i did some test on my side, using InputAudioRawFrame & OutputAudioRawFrame About the input :
async def process_frame(self, frame: Frame, direction: FrameDirection):
        await super().process_frame(frame, direction)
        
        if isinstance(frame, UserStartedSpeakingFrame):
            self._human_speaking = True
        elif isinstance(frame, UserStoppedSpeakingFrame):
            self._human_speaking= False
        elif isinstance(frame, InputAudioRawFrame) and self._human_speaking :
            self.audio_buffer.extend((frame.audio))
        
        await self.push_frame(frame, direction)
is a wrong approach, because the VAD latency causes the beginning of the input audio to be missing for a few milliseconds.
It means the input audio has to be recorded continuously, while the output audio is only recorded when the bot is speaking.
This creates a problem when combining the input and output audio, making the process more complicated.
@aconchillo Do you have any insights? thanks
You are right, it would be a few milliseconds off. One solution is to keep, for example, a 1 second buffer. When you get the VAD event you just grab VADParams.start_secs from that buffer (maybe a bit more) and then start appending as we do now.

Thanks for the pointer, @aconchillo ! I'm not sure I'll use the pipeline to record the audio since InputAudioRawFrames flow continuously through the pipeline, while OutputAudioRawFrames are only present when the TTS is speaking. This means that silences would need to be inserted into the output audio to maintain sync with the input.
Even with the idea of recording the input audio based on VAD events, i would still need to reconstruct the silences by using timestamps on the frames to maintain proper alignment and sync.
Using LiveKit Egress seems like a more precise and simpler approach.

aconchillo · 2024-10-01T04:23:04Z

hey @aconchillo @adriancowham i did some test on my side, using InputAudioRawFrame & OutputAudioRawFrame About the input :
async def process_frame(self, frame: Frame, direction: FrameDirection):
        await super().process_frame(frame, direction)
        
        if isinstance(frame, UserStartedSpeakingFrame):
            self._human_speaking = True
        elif isinstance(frame, UserStoppedSpeakingFrame):
            self._human_speaking= False
        elif isinstance(frame, InputAudioRawFrame) and self._human_speaking :
            self.audio_buffer.extend((frame.audio))
        
        await self.push_frame(frame, direction)
is a wrong approach, because the VAD latency causes the beginning of the input audio to be missing for a few milliseconds.
It means the input audio has to be recorded continuously, while the output audio is only recorded when the bot is speaking.
This creates a problem when combining the input and output audio, making the process more complicated.
@aconchillo Do you have any insights? thanks
You are right, it would be a few milliseconds off. One solution is to keep, for example, a 1 second buffer. When you get the VAD event you just grab VADParams.start_secs from that buffer (maybe a bit more) and then start appending as we do now.
Thanks for the pointer, @aconchillo ! I'm not sure I'll use the pipeline to record the audio since InputAudioRawFrames flow continuously through the pipeline, while OutputAudioRawFrames are only present when the TTS is speaking. This means that silences would need to be inserted into the output audio to maintain sync with the input. Even with the idea of recording the input audio based on VAD events, i would still need to reconstruct the silences by using timestamps on the frames to maintain proper alignment and sync. Using LiveKit Egress seems like a more precise and simpler approach.

That's sounds reasonable. We have recording support at Daily as well and if you use a service transport it makes sense to use the provided recording.

adriancowham · 2024-10-03T00:33:38Z

@aconchillo @cyrilS-dev I just got back from out of town and I'm all caught up. I plan to jump on this tomorrow. I'll play around with VAD stuff while I'm in there. Thanks for the insights!

… also moving to stereo instead of mono with the human and bot on their own channel.

adriancowham · 2024-10-03T21:13:34Z

@aconchillo I nuked UserMarkerProcessor and the code now uses InputAudioRawFrame. I also changed the audio post-processing code to save to stereo. Things work well, however, when the bot is interrupted the recording has the bot's full response but the live playback doesn't. That is, when talking to the bot and I interrupt it, its speech is cutoff (which is good), but the recording has the bot's full response. I'm not sure how to address this, any guidance would be appreciated.

Thanks!

adriancowham · 2024-10-09T16:56:10Z

@aconchillo Wanted to get this back on your radar, no rush, but curious to hear your thoughts on how best to handle interruptions. Thanks!

aconchillo · 2024-10-10T07:09:52Z

@aconchillo Wanted to get this back on your radar, no rush, but curious to hear your thoughts on how best to handle interruptions. Thanks!

Sorry for the delay. I've been heads down on something else.

I believe all you have to do is put the audio processor after transport.output().

So, this:

            transport.output(),
            audiobuffer,  # used to buffer the audio in the pipeline

instead of

            audiobuffer,  # used to buffer the audio in the pipeline
            transport.output(),

adriancowham · 2024-10-10T17:11:48Z

@aconchillo Ah, makes perfect sense, I'll give it a go. Thanks!

…port output

adriancowham · 2024-10-11T17:37:11Z

@aconchillo It's a lot better now, thanks for the tip. Hopefully this PR is ready, let me know if there's anything else I can do?

Thank you!

aconchillo · 2024-10-11T17:57:56Z

src/pipecat/processors/audio/audio_buffer_processor.py

+
+class AudioBufferProcessor(FrameProcessor):
+
+    def __init__(self):


pass **kwargs

aconchillo · 2024-10-11T17:58:05Z

src/pipecat/processors/audio/audio_buffer_processor.py

+        The num_channels and sample_rate are set to None initially and will be
+        populated when the first audio frame is processed.
+        """
+        super().__init__()


pass **kwargs

aconchillo · 2024-10-11T17:58:42Z

src/pipecat/processors/audio/audio_buffer_processor.py

+        - user_audio: A boolean flag to indicate if user audio is being processed.
+
+        The num_channels and sample_rate are set to None initially and will be
+        populated when the first audio frame is processed.


is the documentation accurate with latest changes?

Ha, no. Good catch.

aconchillo · 2024-10-11T18:00:42Z

src/pipecat/processors/audio/audio_buffer_processor.py

+        with BytesIO() as buffer:
+            with wave.open(buffer, 'wb') as wf:
+                wf.setnchannels(2)
+                wf.setsampwidth(self._sample_rate // 8000)


this should always be 2 because every sample is a signed 16-bit integer. If we change sample rate to 44100 this would break.

aconchillo · 2024-10-11T18:01:10Z

src/pipecat/processors/audio/audio_buffer_processor.py

+
+    async def process_frame(self, frame: Frame, direction: FrameDirection):
+        await super().process_frame(frame, direction)
+        if (isinstance(frame, AudioRawFrame) and self._sample_rate is None):


nit: remove outter parenthesis

aconchillo · 2024-10-11T18:01:23Z

src/pipecat/processors/audio/audio_buffer_processor.py

+                self._assistant_audio_buffer.extend(silence)
+
+        # if the assistant is speaking, include all audio from the assistant,
+        if (isinstance(frame, OutputAudioRawFrame)):


nit: remove outter parenthesis

aconchillo · 2024-10-11T18:43:53Z

src/pipecat/services/canonical.py

+
+    def __init__(
+            self,
+            aiohttp_session: aiohttp.ClientSession,


force keyword-only arguments with

self, *, ...

aconchillo · 2024-10-11T18:44:12Z

src/pipecat/services/canonical.py

+            api_key: str,
+            api_url: str = "https://voiceapp.canonical.chat/api/v1",
+            assistant_speaks_first: bool = True,
+            output_dir: str = "recordings"):


pass **kwargs

aconchillo · 2024-10-11T18:44:21Z

src/pipecat/services/canonical.py

+            api_url: str = "https://voiceapp.canonical.chat/api/v1",
+            assistant_speaks_first: bool = True,
+            output_dir: str = "recordings"):
+        super().__init__()


pass **kwargs

aconchillo · 2024-10-11T18:48:24Z

@aconchillo It's a lot better now, thanks for the tip. Hopefully this PR is ready, let me know if there's anything else I can do?

Thank you!

Added some last minor comments. All looks great. I'll merge after those.

adriancowham · 2024-10-11T19:02:47Z

No problem at all, I appreciate all the feedback and the time you've put into this PR.

aconchillo · 2024-10-11T20:47:53Z

LGTM! Thank you so much for all the work!!!

adriancowham added 2 commits September 10, 2024 10:15

adding a frame processor with the ability to save a conversation to a…

f411bf3

… buffer and another frame processor to upload audio to Canonical for evaluation and metrics collection. Examples included

Merge branch 'main' into recording

b4eff20

aconchillo reviewed Sep 10, 2024

View reviewed changes

aconchillo reviewed Sep 11, 2024

View reviewed changes

PR feedback

2e02ab7

aconchillo reviewed Sep 16, 2024

View reviewed changes

missed a debug print statement

387a36d

adriancowham added 3 commits October 3, 2024 09:42

merge from main

2d82702

nuked the code that marks user audio in favor for InputAudioRawFrame.…

4d81a2e

… also moving to stereo instead of mono with the human and bot on their own channel.

comment back in some code

678e87f

adriancowham added 2 commits October 11, 2024 10:33

better interruption handling by moving the processors after the trans…

522d931

…port output

Merge branch 'main' into recording

917e482

aconchillo reviewed Oct 11, 2024

View reviewed changes

adriancowham added 2 commits October 11, 2024 11:29

PR feedback

083d221

ruff formatting

79c8aa2

aconchillo reviewed Oct 11, 2024

View reviewed changes

passing kwargs and forcing keyword-only arguments

4330374

aconchillo approved these changes Oct 11, 2024

View reviewed changes

aconchillo merged commit dc73b20 into pipecat-ai:main Oct 11, 2024
3 checks passed

		@@ -0,0 +1,75 @@
		from pipecat.frames.frames import (AudioRawFrame, BotStartedSpeakingFrame,


		class AudioBufferProcessor(FrameProcessor):

		def __init__(self):

Audio recording FrameProcessor #451

Audio recording FrameProcessor #451

Conversation

adriancowham commented Sep 10, 2024

kwindla commented Sep 10, 2024

aconchillo commented Sep 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aconchillo Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aconchillo Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aconchillo Sep 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adriancowham commented Sep 12, 2024

adriancowham commented Sep 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aconchillo commented Sep 16, 2024

adriancowham commented Sep 17, 2024

aconchillo commented Sep 20, 2024 • edited Loading

adriancowham commented Sep 20, 2024

aconchillo commented Sep 20, 2024 • edited Loading

aconchillo commented Sep 23, 2024

cyrilS-dev commented Sep 29, 2024

aconchillo commented Sep 30, 2024

cyrilS-dev commented Sep 30, 2024 • edited Loading

aconchillo commented Oct 1, 2024

adriancowham commented Oct 3, 2024

adriancowham commented Oct 3, 2024 • edited Loading

adriancowham commented Oct 9, 2024

aconchillo commented Oct 10, 2024

adriancowham commented Oct 10, 2024

adriancowham commented Oct 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aconchillo commented Oct 11, 2024

adriancowham commented Oct 11, 2024

aconchillo commented Oct 11, 2024

aconchillo Sep 11, 2024 •

edited

Loading

aconchillo Sep 11, 2024 •

edited

Loading

aconchillo Sep 11, 2024 •

edited

Loading

aconchillo commented Sep 20, 2024 •

edited

Loading

aconchillo commented Sep 20, 2024 •

edited

Loading

cyrilS-dev commented Sep 30, 2024 •

edited

Loading

adriancowham commented Oct 3, 2024 •

edited

Loading