Hello,

I keep half posting questions today, only to find my answer while reflecting on how best to frame my explorations. Earlier it was in relation to extracting BPM from a soundfiler based audio loop, but I was able to muddle through by manipulating the sample size (sample size divided by sample rate * 1000 to get total length in ms, then multiplying 60,000 by beats in the loop / total sample length in ms to get BPM).

Two very fundamental questions remain, however:

1. there used to be a random object that spit floats (randomF). That doesn't appear to be included in vanilla anymore, and I do not see anything by that name in the external search. Anybody familiar with something that will do this?

2. Earlier I was working on an array, and really wanted to send a bang every time it looped around to index 0. This feels like it should be really easy, but I couldn't think of anything that would send the active index step as out (the contents of the index step, sure, but not the step number itself).

Is there something in the toolbox that will allow for this?

Thanks!

@_ish The vanilla version is [random] which spits integers.
You could use a few of them and [* 0.1] ... [* 0.01] for each..... adding the outputs.... if you want more decimal places.

Bangs at loop wraparound... https://forum.pdpatchrepo.info/topic/3168/bang-on-zero
So it depends on how you are driving the array and how much time accuracy you need but [edge~] might be good enough.
As in that link if using [phasor~] catching it's output as it passes 0 is unreliable because the value of [phasor~] will likely not be 0 as it is captured at a block boundary.
There are audio rate objects that can set future events within the 64 sample blocks of the Pd audio thread, so achieving more time accuracy.
Their names usually start with a "v"
So [vline~] is a more time accurate version of [line~] for example.

But for most uses whether a bang is at one block boundary or the next is unimportant.
Audibly it is as if the origin of the sound has moved just one metre further away from you.

If you are looking for an external object (not part of your vanilla download) then go to Help.... Find externals..... in the Pd top menu and search for it.
[randomf] is in the markex library.
David.

@whale-av since @_ish wants to get a bang, that will happen at block boundaries anyway, so why using [phasor~] is not accurate? You can use it combined with [threshold~] which takes in a signal and outputs a bang. If one wants to do stuff in the signal domain only, then bangs are not the way to go, and Pd's native objects don't really support such operations. I have compiled some externals that send trigger signals when a threshold is crossed. These signals are just a 1 surrounded by 0s, sent as a signal instead of a control message, but I'm not aware of a vanilla where way this is possible.

@_ish said:

1. there used to be a random object that spit floats (randomF).

The ELSE library has [rand.f].

(I wish, when I started with Pd, that someone had pointed me to ELSE... a lot of the things that are missing from vanilla, or "build it yourself," are just there.)

2. Earlier I was working on an array, and really wanted to send a bang every time it looped around to index 0. This feels like it should be really easy, but I couldn't think of anything that would send the active index step as out (the contents of the index step, sure, but not the step number itself).

Are you reading the array in the control or signal domain?

whale-av:

As in that link if using [phasor~] catching it's output as it passes 0 is unreliable because the value of [phasor~] will likely not be 0 as it is captured at a block boundary.

The value of phasor~ isn't reliable for this, but the two-point difference ([rzero~ 1]) is guaranteed to be positive most of the time, and negative only when the phasor jumps down. So this will always work (for a positive phasor~ frequency).

hjh

Am I missing something, or the patch below isn't correct?

[phasor~ 1]
|
[threshold 0.5 10 0.5 10]
|
[o]

This does output a bang whenever [phasor~] resets.

@alexandros said:

Am I missing something, or the patch below isn't correct?

[phasor~ 1]
|
[threshold 0.5 10 0.5 10]
|
[o]

This does output a bang whenever [phasor~] resets.

Nice, provided this operates as suggested (haven't tested), this does precisely what I'm looking for.

I literally started with PD last week, so I just haven't encountered the threshold module to consider (I used Max/MSP back in the Nato.0+55+3d days, supercollider in the early 2000s, and patch modulars extensively since the Nord Modular days, but ignored PD for the most part under an impression it lacked refinement).

My aim is quite simple, embarrassingly so: I'm learning how to play back samples loaded into arrays, and wanted to test my bpm calculations after changing the phasor's speed. As a test I wanted to run a metro at the quarter note time of the new BPM, triggering a kick sample, and confirm the hits are falling where I expect them to,... but then I ran into the issue of getting my metro to start precisely in time with the looping sample (which is just freely looping endlessly via a phasor). Since the phasor~ lacked a phase output, I was stumped, and figured getting the array index = 0 = bang would be a simpler approach.

Per the randomF, the multiplicative scaling by 0.1 works, but then limits my range to 0-1. The use of a second random added to these values would fix this easily, but didn't seem as efficient as finding something that might already exist. Good to hear else has a "rand.f" (or whatever is typed above). I have this external already installed, but haven't exhaustively worked through what is included.

Thanks again, one and all.

p.s. Per the playback of arrays, I have learned a method of chopping samples with a dedicated start button using direct indexing of the slice's start in sample size values (fed as arguments into a vline module set to read from tabread4), but haven't learned how to do so when indexing via a phasor~, I suspect I'll get there in the next day or so.

The vline approach feels superior, but I'm not so sure it lends itself to rate control as easily as phasor~. Indexing via phase seems simpler too since it'll always be 0-1.

@alexandros said:

Am I missing something, or the patch below isn't correct?

It's correct if you use the right outlet instead of the left outlet of threshold~.

@_ish

supercollider in the early 2000s

SC person here!

ignored PD for the most part under an impression it lacked refinement

Just the other day, I already did the rant about how Pd's 1990s-style GUI gives people the wrong impression about its capabilities, and how PlugData is a good way forward that deserves more support... so I'll stop there.

Pd is solid. What's lacking in the built-in feature set is convenience. For example, if you load a soundfile... how long is it? What is its sample rate? In SC, you have BufFrames, BufDur, BufSampleRate, BufRateScale. Pd does spit this information out of soundfiler at the moment of loading, but if you didn't retain those values at that time, then they're gone. So with SC, I feel like it's more straightforward to get into it incrementally -- you're hacking away, and then you find that you need the buffer's sample rate, no problem! It's right there. In Pd, at minimum, you'll have to issue a dummy read command to soundfiler, and unpack the list.

I got annoyed enough about this that I created some abstractions to help deal with soundfiles: https://github.com/jamshark70/hjh-abs :

[monofile] and [stereofile] for basic reading. Mono files play by sf-play~ or sf-varispeed~; stereo by sf-play2~ and sf-varispeed2~. Rate = 1.0 is always the file's normal speed. Also it creates [value] vars for buffer stats, and I have a read-only [getvalue] abstraction to access them without risk of overwriting.

... Strictly speaking, you don't "need" these -- they're only using information that is available in vanilla anyway -- but I just don't think users should have to deal with these fiddly details routinely. So it's not a matter of lacking refinement, but rather that it takes more work to rearchitect features that you might take for granted in other platforms.

I suppose it depends on the task, but in most cases, I can get there faster in SC; the threshold of complexity that I'm willing to attempt in SC is higher than that in Pd. (I usually find patching to be more cumbersome than code.)

hjh

@_ish said:

extracting BPM from a soundfiler

you can use [else/beat~] for beat detection of live input by the way