yes, but inverting with [!= 1] or [== 0]

** also wondering if [tabplay~] simply accumulates?
And how does [loop~] do? And [tabosc4~] ?

phasor~ way isn't sufficient for many use cases; perhaps a new object would be useful, or, the accumulator technique would be useful as a more prominent part of pd culture.

@ddw_music Just chiming in, to say thank you.
I am always interested in how to make Pd sound better: Not only looking for more Pd-double developement, but also for such basic insights.

Vanilla's oscillators use the "Höldrich method", of which I get an idea, but – like most of us? - do not understand fully in depth.
So don’t want to muddy the waters.

Just sharing some related links on the topic:

[phasor~]'s source:
https://github.com/pure-data/pure-data/blob/master/src/d_osc.c

Miller on the method:
http://lalists.stanford.edu/lad/2000/Sep/0188.html

@seb-harmonik.ar explaining:
https://forum.pdpatchrepo.info/topic/8691/generating-sines-in-plain-c-on-arm-understanding-osc-guts/3

Does Pd have a "sound"? (vs. SC)
https://lists.puredata.info/pipermail/pd-list/2016-02/113248.html
(...discussion containing partly false information, too I think...)

A stub, not explaining the method:
https://github.com/TonicAudio/Tonic/wiki/Fast-Phasor-ala-R.-Hoelderich

(The quoted paper appears to be the wrong one or missing:
1995 ICMC“An Accurate Signal Representation for Sound Resynthesis Utilizing a Time-Frequency Mapping of the DFT-Magnitude”
it is not. )

@cfry said:

when saving the text file the system can get unstable and PD crash at times. Usually the text file is intact though. The text file gets quite large also, I suspect that there could be more suitable file formats. When saving Pd gets locked up too so it is not a realtime solution as it is.

Bottleneck appears to be the harddrive? There are huge differences in write speed of SSDs today.
Dropouts/freezing is happening if the task is not accomplished until the next block in realtime audio stream would play.

@oid yay!!! great!!!!!!

More patching, but different, maybe inspiring way to separate urgent realtime tasks from non-realtime, such as disk access for example, is described in the last paragraph of this post:
https://forum.pdpatchrepo.info/topic/14500/using-writesf-to-create-files-but-could-i-use-tabwrite-to-record-sounds-then-save-to-file/2
The NRT pd instance could do some more pre-/post processing/analysing/training, if not urgent.

I'm using writesf~ to record the files, as i need to read them randomly.

Are you running into any problems with this?

How long may the recordings become?
Which hardware is being used?
How much effort do you want to put into this?
...

There are differences of harddrive (solid state or mechanical?) and RAM.
RAM is good for quick read/write access, size is limited (how big? how long the recordings?) and is non-persistent at power-cycles.

Maybe you don't need [writesf~] at all.
But using only [writesf~] may work for you too.

tabwrite~ to capture then save a file afters?
Is that possible?

Yes with [soundfiler]
or this: https://forum.pdpatchrepo.info/topic/14290/array-save-to-textfile-load-from-textfile
(may be possible with .wav files too, but not sure)

Pd runs into precision issues on large arrays:
https://forum.pdpatchrepo.info/topic/7705/looper-write-to-hard-drive-or-array/3
but you can use indexing or split into multiple arrays

And loading large .wav files from hd may introduce audio-dropouts (because [readsf~] is running syncronous, in deterministic order, - I think [soundfiler] does, too).

If really required (!) and (!) you are up for making things complicated (!):
If you need the hd and have big files or dropouts: save once in a while to harddisk in a second pd instance.
Both instances are running asyncronously: one for everything realtime (threshold/recording/playback),
the other instance only for saving and loading to/from hard-drive.
Sharing data between instances with the shmem library. And communicating with [netsend] / [netreceive] or also with shared arrays.

@kaimo An envelope follower you want to patch?

Depending on how accurate it should be, such simple tasks can quickly become quite complicated.

Scaling of [sigmund~] or [env~] also depends on your input:
https://en.wikipedia.org/wiki/Root_mean_square#In_common_waveforms

Edit:
crest factor https://en.wikipedia.org/wiki/Crest_factor#Examples

Now I don't have Pd, so can not try.
But I fairly remember a bug (in Windows?) where .aiff files won't output a bang on the right outlet of [readsf~] when done, while .wav files do? Not sure.

I think the patch should loop, I can not see anything wrong.

Try to debug with [print pleaseplaythatfile] attached to [open $1, start(
and [print done] to the right outlet of [readsf~].

If this is the case, you could start a timer to restart the sample when done.

or even more elegant:

If the soundfiles are not very long, you could load them into arrays with [soundfiler] (i.e. loading from HD to RAM)
and loop the array with [tabread~] or [tabread4~] or [tabosc~] or [tabplay~]

Each time you [open( a file with [readsf~] it loads from harddrive.

... Pd is fairly low-level and has some quirks.

(For beginners I recommend sticking to Vanilla:
learn all its' objects little by little, read the helpfiles
and dive a bit into the first few doc patches of Vanilla installation, but don't get confused by their names.)

Others prefer to start right away with libraries. I am sure there are looping samplers somewhere.
PlugData comes with Cyclone, doesn't it? I think Cyclone probably has something easy?

A cleanup (only visually and not related to the issue):
Delete the cable from
[text get $0-dirfiles] to [open $1, start(
because on hot inlet [symbol] saves and outputs immediately.

Vanilla random-sound-file-from-dir.pd
https://forum.pdpatchrepo.info/topic/14417/installation-patch-and-help-with-pathnames/3

ctrl+t for messages, too:
https://forum.pdpatchrepo.info/topic/14071/msg-a-message-object-bug-fix

I prefer keyboard over mouse.
Using the shortcuts ctrl+1 or +2 or +3 ect. keeps the flow already being connected.
[bng] [tgl] ect same for GUI objects.

In Windows system settings I have activated this shortcut:
zero on number-pad for click-hold. Although I'd prefer a different key, it is very useful in Pd to avoid arm strains.

And this looks promising:
Keyboard navigation/patching
https://github.com/pure-data/pure-data/pull/869

This one too:
canvas zoom and scroll with mousewheel
https://github.com/pure-data/pure-data/pull/1659

(Wish to connect a whole chain easily by simply dragging a cable across several objects/msgs, without the need to release the mouse-button.)

Also: in editmode ctrl+click on GUI, instead of ctrl+e

essential: hold shift + drag on number box

connections in bezier curves

not in Vanilla, as far as I know, only in other flavours as PurrData, L2Ork or PlugData.
One trick for clean patching is to use the patcher more text-like, with many horizontal lines, as you can see from more advanced users here in the forum (lately here f.e. : https://forum.pdpatchrepo.info/topic/14461/can-an-array-be-used-to-arrange-amplitude-changes/2 )

visualize what's going in the chords (which I remember I had in pd-ext)

I never tried, @svanya has made this:
https://forum.pdpatchrepo.info/topic/13046/a-movable-autoconnnecting-vu-meter-esp-for-debugging-code

and something like insert function (insert the block between two objects when dragging), adaptive chords drawing

Not all, but some are available by "intelligent patching"
https://forum.pdpatchrepo.info/topic/13471/shortcut-replacing-wires

edit/production modes

ctrl+e
learn all the shortcuts

@oid recommended this, I haven't tried yet:
https://github.com/RVirmoors/maxhotkey-pd

hard on PD