@willblackhurst said:

vu meter maybe works

Works for which part?

The screenshot you posted shows that the vu meter object doesn't do the volume measurement itself. It only displays the dB level that you've calculated on your own. So I don't think that object is relevant to OP's question (which is, how to calculate the volume level, and for which there have already been a couple of suggestions in the thread).

hjh

@fussicks said:

I was wondering if I could have pd detect audio levels of an audio...

See the [slop~] help patch for an amplitude (envelope) follower -- called "peak meter" in the help patch.

hjh

This is as close as I could get with rpole~.

The limitation here is that using a phasor~ for reset, the period is not 100% exact -- 10 seconds should range from 0 to 479999 samples, but I actually get 479991.

To reset rpole~, both the input and the coefficient need to drop to zero for exactly one sample. That's the point of taking the slope of the phasor, scaling it up by a ridiculous amount, and clipping. If there's another way to do this in pd vanilla that will cycle after exactly the right number of samples, it could be substituted here, but I don't know what that technique is.

(FWIW, the [count~] object from Cyclone is exactly correct.)

hjh

@y0g1 said:

Here "phasor~"'s phase is reset when receiving a non zero signal.
The use case is resetting a sample counter.

Phasor~in puredata doesn't act the same,
Does anyone have a clue how to make a vanilla adaptation ?

I forget who is the pd forum user who taught me this trick, but, here's a neat way to have a signal reset a phasor:

[phasor~]
|  \
|  [samphold~]
|  |
[-~]
|
[wrap~]

Then the reset trigger goes into the right inlet of samphold~ (but IIRC it should be inverted, because samphold samples its input signal when its trigger signal decreases, see its help file).

Always works (think about it a minute, and it becomes clear why).

Btw phasor * sample rate is not safe as a sample counter, due to floating point rounding error. (Maybe ok for one second.) In pd vanilla, [rpole~ 1] can serve as an accumulator but resetting it at signal rate is a bit trickier. I'm not at the computer now but I could track that down later. Or use cyclone's count~.

hjh

@atux said:

But now the problem is this: for example, the values ​​60.0, 60.1, 60.2 inside the number box always get the same note. Is there a way to make all the notes sound at their true frequencies? In this way you can obtain a true continuous glissando.

No. 1/ MIDI note numbers cannot represent microtones. 2/ else/sfont~ ignores fractional note numbers too (so even if you bypass notein/noteout and put fractional note numbers directly into the sound font player, you still won't get microtones).

Basically: MIDI is outdated and boring, and we're still stuck with its 80s limitations

Rant incoming... Actually, the VST framework has an extra data field for detuning, but I'm aware of only one plugin that actually implements it (the old VST2(!) version of Plogue's sforzando). I used to use that for microtuned sampler instruments, but then I had to migrate to yabridge instead of direct WINE support, and... yabridge ignores the detune field too so that's gone. So what's left? sfizz = nope (and sfizz also makes it impossible to use MPE because "hey we're just a plugin, we'll never have to respond to MIDI through hardware so we're going to ignore MIDI channel completely, so, no MPE ever! We're stuck in 2015!") There's a cute sampler plugin called Decent Sampler which does support MPE, but it doesn't handle pitch bend right, and they ignore bug reports, so... for now, don't even think about continuous pitch in sampler plugins, at least not in Linux.

hjh

It depends on how the Python script is written, but often [comport] gets ASCII codes for a string representation of the values, not a linear mapping of the values themselves.

I think that's the case here because: 1/ a "CR-LF" pair (carriage return - line feed) uses ASCII codes 13 and 10, where 10 conspicuously matches the lower bound you observed, and 2/ decimal digits are ASCII codes 48 to 57, which is kind of close to 60.

I think there are other threads on this forum showing how to reassemble the comport bytes into strings and convert them into real numbers. ... such as: https://forum.pdpatchrepo.info/topic/15143/help-parsing-continuous-serial-float-stream-from-arduino-into-pure-data/2 -- note that the cables coming out of [t b b] crisscross going into the [list store] (output first, then reset).

hjh

External loading is one of those things where there are a hundred ways to mess it up.

After struggling with it for a while myself, I came up with a few practices that remove some variables, thus remove some risk.

1. Only install externals in the "pd externals install directory" (found in the preferences panel). Do not ever install externals in any other location. Deken (IIRC) download externals here, so that's fine.
   • Actually, on my system, Gem is an exception since I'm using the Ubuntu package instead of installing from deken. But to avoid the types of complications that I ran into before, I symlinked the Gem into my pd externals install location: under Documents/Pd/externals/, there is a Gem directory, but it's a link pointing to /usr/local/lib/pd/extra/Gem. So I access it through the externals install directory.
2. Pd "path" should list only the externals install directory -- my path list is "/home/xxx/Documents/Pd/externals" and nothing else. So I always know where to start looking.
3. Use [declare -path xxx] to add library paths, and "-lib yyy" to init libraries like Gem.
   • Isn't that a pain to have to do that in every patch? Well, not really... and the benefit is that you can search the patch for any declare objects used in the main patch file or abstractions to quickly get an inventory of which externals need to be transferred.

If you follow some streamlined practices for external management, then it removes a lot of speculation and worry. Recompiling? No... Or, "Mac is doing things to make the folder not findable" -- it's a user folder under Documents; if Mac is hiding folders under Documents without the user's permission, that would be pretty bad -- so that's a concrete example showing how you benefit from putting externals in a consistent location that is expected to be under your control, not the system's control.

My "rules" might seem too strict but I arrived at this because being haphazard about external installation caused a ton of headaches for me early on. Those problems don't exist for me anymore.

hjh

Well, if you load a large audio file while sound is playing, you can get dropouts then too.

That's a 97.3 MB file -- "audio I/O error." Only vanilla objects in the patch. Sending that read message does glitch the audio.

So this isn't "a Gem issue."

Since Pd is single-threaded and the control message layer runs within the audio loop, heavy activities in the control message layer can cause audio processing to be late. Reading a hundred MB of audio? Opening a window and preparing it for graphics rendering?

AFAIK the available solutions are: A/ structure your environment so that all heavy initialization takes place before you start performing -- i.e., start Gem before your show, not during. Or B/ Put Gem in a different Pd process (which doesn't have to be [pd~] -- you could also run a second, completely independent Pd instance and use OSC to communicate between them). (Smart-alecky suggestion: Or C/ Move your audio production over to SuperCollider, whose audio engine shunts heavy loading off to lower-priority threads and whose control layer runs in a separate process, so it doesn't suffer this kind of dropout quite so easily.)

"Except that dropout when you create and destroy. Wish that could be changed" -- sure, but the issue is baked into Pd's fundamental design, and would require a radical redesign (of Pd) to fix properly.

hjh

@jamcultur said:

It looks like the feature request on github that @oid mentioned would fix the problem in a much cleaner way.

I would not be too optimistic about that feature request -- its current state seems to be: OP: "hey, this would be nice"; dev: "here are some reasons why this won't work"; OP: "oh come on, it would be nice"; dev: "here's another couple reasons why it won't work" ... which is kind of the same form as the thread here.

Well, the github issue ends with "let me try it in an external" but my prediction is that this effort will quickly run into trouble. It's not an easy problem.

hjh

... whereby, a reliable solution would be that an abstraction using another abstraction needs to initialize the sub-abstraction by sending messages to it. That is:

• Main patch loads abstraction xyz
  • xyz loads abstraction abc
    • abc initializes itself by [savestate] using the defaults saved in xyz.pd
  • xyz gets data from [savestate]
    • xyz, as part of its init, sends messages to the [abc] instance to override the earlier init

Then xyz.pd is responsible for sending the right data to the right instances, avoiding ambiguity.

hjh