There are some things I would have expected to have been implemented in vanilla pd by now, but I don't see them in any of the archives. Perhaps you could advise.

Among them:

• An audio file player which does not keep an entire sound file in memory, but rather streams in blocks from the file system as needed and discards them once played.
• A timeline editor for sample sequencing, ideally based on such an audio player.
• A method for keeping multiple parallel mono audio tracks in sync.

Most of the attempts at these things seem to depend for some reason on old extensions that are no longer supported. Advice appreciated, thank you.

longaudiojumps.pd thats how i solved to play an audio file from disk. in the example it jumps every 2 seconds to a random position, but you can adjust it. of course you need to rename the name of the .wav file or you can use openpanel.

@johnwbyrd [readsf~] is still implemented in 047.1 and has been since before 0.37....... but maybe only for windows?....

Your second two requests do not exist I think...... or at least not based on a disc streaming player.
Now with ssd affordable I suppose it could be used, but for sequencing many samples, and maybe manipulating them as well, ram is still probably more sensible.

I suppose you could write out the mono tracks (up to 64) using [writesf~] to be sure of the sync? but that's probably not useful.
David.

@whale-av I saw readsf~ and I also noticed that it can take parameters representing ranges of the input sound file... but I don't see any suggestions that readsf~ occurs asynchronously to the main thread -- it seems to hang the rest of pd while the file system wakes up and delivers some more audio data into pd. I think it might make more sense to tell readsf~ or some other equivalent to asynchronously fill an array range with some data from an audio file, and then send a bang or something once that particular read is complete. Do I misunderstand the nature of readsf~? I can dig around in the source code, but I bet I'm not the first person to consider this problem.

@johnwbyrd I have never looked at the source code, but I run a live performance with Pd....... 30 input channels, 8 out..... with live mixing and using [readsf~] for up to 15 minute backing tracks, and I have never had Pd hang even momentarily.
I use extended for that although I doubt the [readsf~] implementation is different.
However, I use windows7....... and is it possible that Pd and the OS treat disk access slightly differently on other systems? I doubt that.

[readsf~] requires an "open" and a "start"...... so it is not forward looking as it might be in an audio editor. However if you program the "open" in advance.... or even at load, then the start is instantaneous (in ram) and you can emulate an instant player.
If Pd is stumbling during playback..... look elsewhere for the problem....... not in [readsf~]......

A multi-GHz processor with rapid disc access should not have problems with audio or Pd...... they use a paltry fraction of the resources available.

Yes..... Pd prioritises audio..... like all programs that use audio.... over video, screen drawing...... everything. So if your patch is struggling in any way you could see the Pd gui stumble.
Check thoroughly your audio and latency settings.... any mismatch with the capabilities of the soundcard could cause what you are seeing.
More here about setting up your computer for audio......... https://forum.pdpatchrepo.info/topic/10125/audio-and-video-why-do-i-have-problems ..... with a link to a good read for problem solving!
You often just need to tell your OS to do as instructed......"and I mean it!"........... Otherwise it prefers to go and peruse it's Facebook page for likes!

Maybe, otherwise, use FL studio or something similar.
Programs written specifically for audio application will have been written in assembly language and be more appropriate for your purposes.
Communication with Pd is usually facilitated through at least midi or OSC messaging.
David.