@porres something about [format] doesn't seem to be working correctly. See the [datetime] helpfile to see what I mean

@porres recompiled using rc12 code and everything seems to be working well.

I assume there still might be problems with sfinfo etc but [highpass~] is working. [format] is also working as expected (no error thrown about variables).

@porres yes, I did! I should used the Rc12 one actually. I'm sort of new to compiling etc. I'll try and recompile later and see if that solves the [highpass~] issue.

It's not a major problem for me to not have [sfload] etc. But I'm glad I've been able to at least replicate the problem's you've all been having. I did some quick googling, which suggests it might be still linked to openssl in some way. I'm not sure if that tallies with what @timothyschoen thinks.

Another issue I'm stumped on: I keep getting errors with [format] saying that no variables are given. I don't get these errors on macOS at all.

Further update. Else compiled but I am running into errors. I opened a patch I've been working on with a macOS system. I get the following errors on load:

... couldn't create
/home/csteenson/Pd/externals/else/sfload.l_arm64:/home/csteenson/Pd/externals/else/sfload.l_arm64: undefined symbol: TLS_client_method
else/sfload buffer_$0
... couldn't create
/home/csteenson/Pd/externals/else/sfinfo.l_arm64:/home/csteenson/Pd/externals/else/sfinfo.l_arm64: undefined symbol: TLS_client_method
else/sfinfo
... couldn't create
load_object: Symbol "highpass_tilde_setup" not found in "/home/csteenson/Pd/externals/else/highpass~.l_arm64"
else/highpass~
... couldn't create
[format]: no variables given

I'm assuming the [sfinfo] errors are to do with ffmpeg in some way during compilation. No idea about the [highpass~] error. [lowpass~] for example works fine.

I've been trying to do a build of else for 64-bit Bookworm OS on Pi 4B.

I've been able to edit the CMakeLists file to remove pdlink~.c and pdlink.c

-- Configuring Opus
-- Configuring sfizz
-- Configuring ffmpeg
-- 316 coded objects (205 signal objects / 111 control objects)
-- 225 abstractions (87 signal objects / 138 control objects)
-- Merda modules: 22
-- Configuring done
-- Generating done
-- Build files have been written to: /home/csteenson/pd-src/pd-else/Build

But I'm having problems with ffmpeg now...

[ 28%] Built target pimp_tilde
[ 28%] Built target pink_tilde
[ 28%] Building FFmpeg libraries...
ERROR: openssl not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.libera.chat.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.
Makefile:194: /tests/Makefile: No such file or directory
make[3]: *** No rule to make target '/tests/Makefile'.  Stop.
make[2]: *** [Source/Shared/ffmpeg/CMakeFiles/ffmpeg_deps.dir/build.make:76: Source/Shared/ffmpeg/ffmpeg-7.0.1/libavformat/libavformat.a] Error 2
make[1]: *** [CMakeFiles/Makefile2:9328: Source/Shared/ffmpeg/CMakeFiles/ffmpeg_deps.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

EDIT: I got past this by installing libssl-dev and ffmpeg compiled correctly... This part took quite a while.

BUT! else fully compiled after that! Yay!

@porres @timothyschoen whoops, I realised I compiled from the wrong source. Here's a failed compile with the 0.55-2 source.

Is it to do with float32 in some way?

else-compile-log2.txt

I can attest that this is a great little abstraction for DBAP thank you @solipp

@porres no worries. I hope you can fix it. It would be brilliant to have running on the Pi. Especially with the multichannel support.

I tried compiling on a 32-bit operating system and this is the log. I didn't get very far, unfortunately. But maybe this is useful for you and @timothyschoen

else-compile-log.txt

Just a note that if you are trying to install pd 0.51-4 using Raspbian Bookworm,

sudo apt install libfftw3-3

in Step 3 of @emviveros's instructions will not work.

However, you can get around this by installing each of libfftw3-3's dependencies, which can be found here: https://packages.debian.org/buster/libfftw3-3

After this, you can proceed as normal and pd will install.

It's also worth noting at when pd is installed it goes to usr/local/bin (at least when I've done it). From here you can create a link to the pd-gui bash file to create a logo shortcut. If I have time I'll make instructions, for those who wants something a bit more user friendly...

I've just run into the same issue, regarding else on a 64-bit Rpi OS.

Has anyone had success compiling RC12? I haven't tried the pd-lib-builder method. I did try using the compilation instructions on the Github page, but to no avail. It ran but did not seem to work...

I'm reverting back to a 32-bit OS to see if that will work.

Thank you both!

I suppose I was trying to exactly replicate the inverse square law equation at the link in my first post so that I could that I check that I was doing everything correctly. When I checked my abstraction against the examples on the site, I seemed to be getting the correct outputs. What stumped me was why this wasn't translating when applying the abstraction's output to the [*~] in the patch with a sound source. I definitely made an assumption here that I wasn't expecting @jameslo.

@manuels I understand that it might not strictly be necessary and thank you for pointing out that you can just multiply the signal by d1/d2 divided. I will definitely do that for actual calculations!

@jameslo I wonder if you're being pedantic about my phrasing, which is fine. I do understand that division by 0 would be 0. That is totally fine in this situation, where I was do that as part of a formula to calculate the reduction in dB at distance 2, and then subtracting that from the dB of the sound at a hypothetical distance 1 (even if it's a bit unnecessary). As I said, I was following the equation at the link to check my work.

@jameslo thanks. Yes, that's not the problem. It's that when the d1 and d2 (which controls the volume of the sound) is zero, there's a discrepancy at the output stage.

You can see in the screenshot that the noise signal at input is indeed around -5dB as you say. But at the output stage, it's lower by a few dB. This is despite the rms value after the inverse_sq_law abstraction being the same as that going into the abstraction. That's what's stumping me.

Hey all.

I've just been working on making an abstraction for the inverse square law to control the volume of an audio source based on distance. The maths seems okay.

https://www.engineeringtoolbox.com/inverse-square-law-d_890.html

The mystery I can't figure out is that when the distance between distance 1 and distance 2 is 0, there's a discrepancy in volume, which should not be there (see screenshot).

Edit: I said 'should be there' when I meant 'should not'!

I'm also attaching the patches. I'm a bit perplexed, but it could be something very simple that I'm not accounting for!

test-inverse_sq_law.pd
inverse_sq_law.pd