I'm afraid I know next to nothing about dynamic patching... sorry but there's not much I can do here.

hjh

It isn't enough to convert Hz to linear. You also need to decide which frequency corresponds to -5 V, and which to +5.

Then divide your frequency by the Hz value for -5. Then you need the log to base (high Hz / low Hz). This can be done by:

// this is both steps: division and log
ln(freq / low) / ln(high / low)

Now you'll have a value from 0 to 1, which can easily be scaled onto the desired voltage range by doing that_value * 10 - 5.

On the phone so I can't build it out right now, but this formula will work.

hjh

If the intent is to get a 48 dB/octave rolloff, you could chain 4 2-pole filters in series. (Often, a 4-pole aka 24 dB/oct filter is implemented by chaining 2 of them, because a true recursive 4th-order filter requires too much numeric precision or else it blows up. I'd imagine an 8th-order filter would be subject to the same concern.)

If the intent is for very specific filter characteristics, that's outside of my expertise.

hjh

@seb-harmonik.ar said:

internally phasor~ uses something like 32-bit fixed-point. So the comparative error is really introduced when multiplying by the buffer size I guess.

Must be.

Also looking at what I think is the Phasor code, it looks to me like it outputs 64-bit doubles.

SC UGens are free to use doubles internally, but the interconnection buffers are single precision, so we do run into trouble at that 24 bit mantissa limit.

I think the difference is that the output of Phasor is already scaled and output as a 64-bit value before being converted to 32-bit...

I think it's a bit more than that. When the phase increment is 1 buffer frame per output sample, then there is no inaccuracy at all, because integer values are never repeating fractions, and up to 2^24, are not subject to truncation (2^24 - 1 is ok but 2^24 + 1 is not). It avoids the problem of scaling inaccuracy by not scaling at all -- which may be what you meant, just being clear about it. rpole's similar results are because my example is integrating a stream of 1's, so everything is integer valued.

It struck me interesting how the correct observation "buffer playback by scaling phasor~ runs into trouble quickly" slips into a generalized caution. Agreed that the 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.

hjh

An old post, but just spotted:

https://forum.pdpatchrepo.info/topic/8940/manipulate-video-with-sound/10 :

There are limitations to the length of the audio file that can be loaded into ram and played (90sec) in 32-bit Pd, that can be overcome with some difficulty...

SuperCollider also uses 32-bit floats for audio processing, and our documentation notes that BufRd (analogous to [tabread4~]) can go up to about 6 minutes at 44.1 kHz.

Possibly this is because SC provides a Phasor that is designed for buffer reading, where the default increment is 1.0. Pd's [phasor~] calculates the increment as frequency / sampleRate (the nearest analog in SC is LFSaw, not Phasor).

When accumulating 1's, the output value will be exact up to the 24-bit mantissa precision (23 mantissa bits are stored, plus one implicit "1" to the left of the binary point). Binary floating-point values are exact when the denominator of the fraction is a power of two. The denominator of an integer value is 1 == 2 ^ 0, so, no problem up to (2 ** 24) - 1.

Dividing by sample rate to get the increment will introduce inaccuracy, but it is not the only way to produce buffer indices.

I tested at 48 kHz with a 5'30" sine tone, written into a file. If I get the sample positions from [rpole~] accumulating 1.0, it sounds clean, even starting at around the 5 minute mark.

hjh

@nenleh said:

In an tutorial I have seen that someone marked the checkbox "compute audio" in the main window of PD (first picture) to solve this poblem.
But I do not have this checkbox (second picture).

Ancient tutorial, then. The current "DSP" checkbox is the same as the old "compute audio" box.

What can be the problem?

The console messages that you get after clicking DSP say that it's an audio driver problem: Pd is trying to connect to an Advanced Linux Sound Architecture instance and this is failing.

Linux audio is famously messy. The current best attempt to clean up the mess is Pipewire, so I guess your best option may be to install Pipewire and run pd under its power. If it's me, I'd use the Media menu to choose the JACK backend and then run pd as "pw-jack /path/to/pd-gui" (I think; not at the computer right now, and the path may vary depending on Linux distro).

I have not yet used Pipewire, though, so I couldn't troubleshoot beyond that. Linux audio forums could help more. (Note that Linux audio being chaotic and disorganized isn't Pd's fault -- but once you get the audio subsystem configured, then it works for every app. It's painful only the first time.)

Also, "priority 6 scheduling failed" means that you should add your user to the "audio" group.

hjh

@4poksy said:

The architecture of patching is utmost important.

Also: You won't get the architecture right the first time. So, try something, in full knowledge that eventually you'll have to rip the guts out.

(However, some architectural elements could be done well right away: minimizing the paths through which data can flow from one part of the system to another, for instance. Modularizing, and keeping modules as local as possible, concretely reduces the chances of bugs, and also reduces the area over which guts will have to be ripped out later.)

hjh

IIRC (I don't have the book in front of me just now) Dodge/Jerse Computer Music discusses the Voss algorithm to generate 1/f noise, as an average of sample-hold random number generators.

23-1112-voss.pd

The discrete derivative (difference between successive points) should follow the 1/f law.

hjh

PS Edit, replaced attachments a minute later b/c of a mistake.

I'm curious, are you comparing "sequence time point == transport time point" or ">="?

If >=, wouldn't it be easier to keep them numbers, instead of converting to text? (Prefer the simplest solution that gets the job done: if a and b are numbers, there's "a > b" or there's "convert a and b to strings, with zero padding, and compare ASCII" and it's pretty clear which approach is simpler and less breakable -- oh, and faster.)

hjh

@whale-av said:

But there is still a limit...... 198 is it...... in 32-bit extended

How? ...

Vanilla 0.53 will not show a result for either with input > 34...... a big for extended.and for vanilla.

The largest possible exponent in 32-bit float is 38. With an input of 34, you're already reaching this limit. Anything above that will be an incorrect result, so I'd say to extended for providing a false answer and no indication that the result is false. (Unless you meant 64-bit extended... but the exponent limit in 64-bit floats is 308, and 198! = 1.9815524305E370, also outside the limit... so even in 64 bits, 198! is a garbage result.)

hjh