On Nov 22, 2024, at 12:18 PM, pd-list-request@lists.iem.at wrote:

Message: 1
Date: Fri, 22 Nov 2024 12:06:50 +0100
From: reduzent@gmail.com
Subject: [PD] Re: mp3 playback from URL
To: pd-list@lists.iem.at
Message-ID: <ccf3392c82eb7e0e20cff8cb0249f1ab9ad0b745.camel@gmail.com>
Content-Type: text/plain; charset="UTF-8"

Hi Oliver

On Fri, 2024-11-22 at 11:49 +0100, oliver wrote:

I recently had good success with remote controlling VLC player from 
within PD. 

Thanks for the suggestion. That's actually where I came from. I used to
control MPlayer from Pd and I was really glad that I could do it all
purely within a Pd patch when [readanysf~] came along. Things were much
more cumbersome back then. Nowadays, with [command] this would work a
tad bit neater. 

It's definitely a fall-back option. However, I'd like to avoid it due
to the increased complexity and the different software involved. I
still want to process audio in Pd, so I have to make sure to route
vlc/mpv audio output to Pd through JACK, which requires to give each
JACK client (mpv/vlc and Pd) a unique name so that persistent routing
works (consider having many such setups in parallel). Also, I'd like to
avoid JACK all together so that a Pd hiccup does not cause an audible
drop-out. My radios run Pd with '-nosound -nomidi -nogui' and thus the
only buffering is happening in [mp3cast~]. Which again means there are
practically no drop-outs at all. The patch can even do tasks like
rendering text-to-speech voice with [flite~] without any side-effects.

Cheers,
Roman