*This* is a good point and worth noting, not necessarily as a "always delay before playing" sort of thing but more a short description of how it works, then a note like "if you experience occasional dropouts on first accessing a file, consider adding a small delay after opening but *before* playing."
> On Mar 4, 2024, at 1:01 PM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Mon, 4 Mar 2024 12:55:54 +0100
> From: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>>
> To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: Re: [PD] help making sense of [readsf~]
> Message-ID: <2176516f-edbe-4982-bcfa-b7002952abc1(a)christofressi.com <mailto:2176516f-edbe-4982-bcfa-b7002952abc1@christofressi.com>>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Actually, I forgot something important:
>
> Of course, the worker thread must also *open* the file! If the file is
> not yet cached by the OS, this can indeed take a few milliseconds.If you
> don't add some delay between "open" and "start", you might notice that
> you get a dropout the very first time, but not on subsequent times.
>
> In fact, if you don't wait between "open" and "start", the perform
> method almost certainly blocks. However, often we don't notice because
> it may be "absorbed" by Pd's own ringbuffer (= "Delay" in the audio
> settings).
>
> Anyway, I agree that the help needs some more clarification! (Just make
> sure you really understand how the object works before changing the help
> patch :)
>
> ?Christof
--------
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
To echo Christof, each object has a parallel worker thread as the file I/O could block Pd's audio thread. It takes time to read the beginning of the file (or from the start point) before it can be played back.
IMO the warning / concern in the help file is really from a time of *much* slower media where the file I/O would take a lot longer, especially if a spinning hard drive has to access multiple files in multiple physical locations. Nowadays, speed and (pre-)caching make access times so much faster we don't necessarily think about it except for very large files we need to be able to randomly access.
As Christof says, fine tuning the reader buffer size could be thought of as fine tuning the audio buffer length, ie. a 64 block size is faster but has less space/time if your patch does some really CPU intensive stuff. If you don't need super responsively, you can increase the block size. I have never personally needed to use anything but the default readsf~ buffer size.
> On Mar 4, 2024, at 12:00 PM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Mon, 4 Mar 2024 06:23:16 +0100
> From: Christof Ressi <info(a)christofressi.com <mailto:info@christofressi.com>>
> To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>
> Subject: Re: [PD] help making sense of [readsf~]
> Message-ID: <93bd5dc6-baa9-4097-ac07-ae7683b75479(a)christofressi.com <mailto:93bd5dc6-baa9-4097-ac07-ae7683b75479@christofressi.com>>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi,
>
>> making it seem it would load the file into an internal memory and not
>> just read directly from the disk
> The help file says "soundfile playback from disk"...
>
> Here's how the object works:
>
> A worker thread is reading data from the given file and fills a buffer.
> If the buffer is full, it waits until there is space. The thread starts
> to do its job right after the [open( message.
>
> Once we send the [start( message, the perform method simply tries to
> read a block of samples from the buffer and copy it to the outlets. If
> there is not enough data in the buffer, the method blocks - which is
> something we definitely want to avoid! This is exactly the reason why we
> need to wait a little bit between the [open( message and the [start(
> message; otherwise the perform routine might have to wait for the
> buffer, causing a dropout.
>
> The second argument for [readsf~] is the size of the buffer. The default
> value seems to be 262144 bytes (per channel). In single-precision Pd
> that corresponds to 65536 samples, which should be more than enough. I
> think this value comes from the times where everybody had slow HDDs with
> unpredictable seek times; for modern SSDs it can be much smaller, but we
> probably don't care about a few kilobytes.
>
> (BTW, I have no idea why the help patch uses a buffer size of 1 MB...)
--------
Dan Wilcox
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
(taken it back to the list)
> Do you have a suggestion for ambisonic plugins?
Here are some free and open source ambisonic plugins:
IEM plugins: https://plugins.iem.at/
SPARTA: https://leomccormack.github.io/sparta-site/
ICST plugins: https://ambisonics.ch/page/icst-ambisonics-plugins
Personally, I use the IEM plugins. One very nice thing about those is
that they can automatically deduce the ambisonics order from the channel
count. For example, let's take the following stereo encoder:
[vstplugin~ -e -m StereoEncoder 2 16]
Here I create it with 16 output channels, so the StereoEncoder will
automatically output a 3rd order ambisonic signals
If I send the [channels 24( message to [vstplugin~] it will switch to 24
output channels and the StereoEncoder will automatically switch to 4th
order.
If you want to change the ambisonics order of your whole patch, you just
need to send the same [channels <n>( message to all your [vstplugin~]
instances and the [send~]/[receive~]/[catch~] objects that make up your
"ambisonic busses". (You don't have to do this for [throw~].)
Christof
On 02.03.2024 09:51, Edwin van der Heide wrote:
> Dear Christof,
>
> Very nice!
>
> Do you have a suggestion for ambisonic plugins?
>
> Best!
>
> Edwin
>
> On 1 Mar 2024, at 23:24, Christof Ressi <info(a)christofressi.com> wrote:
>
>
>
> Hi,
>
> I have just released [vstplugin~] v0.6.0! Binaries are already
> available on Deken (search for "vstplugin~").
>
> The most important new feature is /support for multichannel signals/:
> a single input or output signal can now contain multiple channels.
> This is particularly handy for spatialization plugins with many
> channels, such as higher-order ambisonics. Not only does it save you
> from drawing lots of patch cords, it also allows you to change the
> channel count dynamically! For example, you can now freely change the
> ambisonics order without rewriting your patch.
>
> IMPORTANT: previous versions would hide certain (non-automatable)
> parameters in VST3 plugins. This has been fixed, but as a consequence,
> parameter might have changed. [vstplugin~] prints a warning for every
> plugin that is affected by this change!
>
> Here is the full changelog:
> https://git.iem.at/pd/vstplugin/-/releases/v0.6.0
>
> Please test and report any issues at Issues · Pure Data libraries /
> vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.
>
> Have fun!
>
> Christof
>
> _______________________________________________
> Pd-list(a)lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
Hi,
I have just released [vstplugin~] v0.6.0! Binaries are already available
on Deken (search for "vstplugin~").
The most important new feature is /support for multichannel signals/: a
single input or output signal can now contain multiple channels. This is
particularly handy for spatialization plugins with many channels, such
as higher-order ambisonics. Not only does it save you from drawing lots
of patch cords, it also allows you to change the channel count
dynamically! For example, you can now freely change the ambisonics order
without rewriting your patch.
IMPORTANT: previous versions would hide certain (non-automatable)
parameters in VST3 plugins. This has been fixed, but as a consequence,
parameter might have changed. [vstplugin~] prints a warning for every
plugin that is affected by this change!
Here is the full changelog:
https://git.iem.at/pd/vstplugin/-/releases/v0.6.0
Please test and report any issues at Issues · Pure Data libraries /
vstplugin · GitLab <https://git.iem.at/pd/vstplugin/-/issues>.
Have fun!
Christof