Hi folks, I'm on a vibe of uploading missing libraries and objects for Pd Vanilla on deken. On the list I have FFTease, Lyonpotpourri, CICM-Tools and more stuff that I'm looking into, just so you know...
Now, I see there's an old soundtouch~ external here: http://www.katjaas.nl/pitchshift/soundtouch~.html - it's "version 0.9" by Katja Vetter. It was developed with SoundTouch version 1.6 and Pure Data version 0.42. I tested on Pd 0.51-4 32 bits on mac and it works fine. There are binaries for download on the link above, but not for 64 bits. I wonder if anyone wants to help me build these with pd-lib-builder and all.
Now, the ceammc librarym (and Pd-ceammc distribution) has a soundtouch~ external too. It's the same name, but not the same external, this one is marked as "version 0.1". So we do already have "a" soundtouch~ for vanilla, but I wanted to also get katja's external up there.
So I just uploaded the download from that page here https://github.com/porres/pd-soundtouch - It's just the download as it is and we need to change to hopefully use pd-lib-builder, which would make things easier. I did try that and it didn't work.
So, anyone onboard with this?
cheers
On 1/27/21, Alexandre Torres Porres porres@gmail.com wrote:
Em ter., 26 de jan. de 2021 às 22:47, Alexandre Torres Porres < porres@gmail.com> escreveu:
It was developed with SoundTouch version 1.6
The latest stable release is 2.1.1, by the way... I guess we should update to the new version, right?
The port based on 1.6 is very old, maybe 10 years or so.
On 1/27/21, Alexandre Torres Porres porres@gmail.com wrote:
Hi folks, I'm on a vibe of uploading missing libraries and objects for Pd Vanilla on deken. On the list I have FFTease, Lyonpotpourri, CICM-Tools and more stuff that I'm looking into, just so you know...
Now, I see there's an old soundtouch~ external here: http://www.katjaas.nl/pitchshift/soundtouch~.html - it's "version 0.9" by Katja Vetter. It was developed with SoundTouch version 1.6 and Pure Data version 0.42. I tested on Pd 0.51-4 32 bits on mac and it works fine. There are binaries for download on the link above, but not for 64 bits. I wonder if anyone wants to help me build these with pd-lib-builder and all.
Now, the ceammc librarym (and Pd-ceammc distribution) has a soundtouch~ external too. It's the same name, but not the same external, this one is marked as "version 0.1". So we do already have "a" soundtouch~ for vanilla, but I wanted to also get katja's external up there.
So I just uploaded the download from that page here https://github.com/porres/pd-soundtouch - It's just the download as it is and we need to change to hopefully use pd-lib-builder, which would make things easier. I did try that and it didn't work.
Doesn't build, load, or what? If you create a branch with your pd-lib-builder attempt, someone might help figure out why it "doesn't work" (I'm not promising it'll be me).
So, anyone onboard with this?
cheers
hi, now I have a tag for version 0.9, see https://github.com/porres/pd-soundtouch/releases/tag/0.9
All I did was remove a couple of dependencies from the help file (for++ and pddplink) and replace them with vanilla alternatives.
I uploaded to deken the bundle package and also separately (linux, windows, mac).
I tried the make file as it is to build it for mac 64, it works! So I also uploaded it. Please check them and test the on deken.
It's only missing binaries for windows64 bits, linux64 bits and raspberry pi versions. Hopefully other people can build and upload them.
Em qua., 27 de jan. de 2021 às 07:12, katja katjavetter@gmail.com escreveu:
Doesn't build, load, or what? If you create a branch with your pd-lib-builder attempt, someone might help figure out why it "doesn't work" (I'm not promising it'll be me).
I haven't really even tried properly. I just tried in the most lazy attempt to include pd-lib-builder and it didn't work (no surprise). Then I tried the makefle as it is and it was a success, so I guess other can build with it just fine. Perhaps other people with better knowledge on how makefiles work can help and make an actual (and probably successful) attempt. I'll merge and we can make a "1.0" release with that.
The port based on 1.6 is very old, maybe 10 years or so.
Yeah, it's from 2011! So version "1.0" may also include the latest soundtouch release and pd-lib-builder.
cheers
On Wed, 2021-01-27 at 22:59 -0300, Alexandre Torres Porres wrote:
It's only missing binaries for windows64 bits, linux64 bits and raspberry pi versions. Hopefully other people can build and upload them.
I'd be glad to help out here. I don't know how to build it, though.
Simply running make gives me errors¹. I tested on Linux amd64 and
i386.
To my (not so well-trained) eyes, things look still a bit rough on the edges. It's not using pd-lib-builder, it comes with an included m_pd.h, it seems to want to create a pd_darwin file (don't know how to override this). Before doing any release, it should be IMHO in a more mature state, much preferably with a pd-lib-builder Makefile.
And - please ! - do not commit building artifacts to a source code repository. It's generally considered bad practice.
For me to be able to help providing binaries, it needs to be as simple as running make. I won't be able to spend much time on it otherwise.
That said, I welcome your efforts bringing interesting externals to the masses. But we should acknowledge the amount of work it requires and not rush things through.
Roman
¹:
pd-soundtouch/src[(HEAD detached at 0.9)]$ make
g++ -DPD -O3 -Wall -W -Wshadow -Wno-unused -Wno-parentheses -Wno-switch -fcheck-new -fvisibility=hidden -I ./include -c *.cpp
soundtouch~.cpp: In function ‘void soundtouch_tilde_setup()’:
soundtouch~.cpp:312:67: warning: cast between incompatible function types from ‘void* (*)(t_floatarg, t_floatarg)’ {aka ‘void* (*)(float, float)’} to ‘t_newmethod’ {aka ‘void* (*)()’} [-Wcast-function-type]
312 | soundtouch_class = class_new(gensym("soundtouch~"), (t_newmethod)soundtouch_new,
| ^~~~~~~~~~~~~~
g++ -bundle -undefined suppress -flat_namespace -o soundtouch~.pd_darwin *.o
g++: error: suppress: No such file or directory
g++: error: unrecognized command line option ‘-bundle’
g++: error: unrecognized command line option ‘-flat_namespace’
make: *** [Makefile:47: soundtouch~.pd_darwin] Error 1
Em qui., 28 de jan. de 2021 às 06:17, Roman Haefeli reduzent@gmail.com escreveu:
it seems to want to create a pd_darwin file (don't know how to override this).
just change the target here in the makefile before running make https://github.com/porres/pd-soundtouch/blob/main/src/Makefile#L8
Am 28. Jänner 2021 17:00:54 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Em qui., 28 de jan. de 2021 às 06:17, Roman Haefeli reduzent@gmail.com escreveu:
it seems to want to create a pd_darwin file (don't know how to
override
this).
just change the target here in the makefile before running make https://github.com/porres/pd-soundtouch/blob/main/src/Makefile#L8.
actually, don't.
better just run specify the target when running make.
like so:
make pd_linux
this is less to type, less error prone and more flexible.
mfg.hft.fsl IOhannes
In the past I have been using the shell object, part of the ggee library, on the raspberry pi using the 32 bit version of the OS.
Now I’ve moved to the 64 bit version of the Raspberry PI OS (aarch64) but there is no version of the ggee library available for this architecture.
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
Best!
Edwin
On Mon, 2023-10-30 at 18:21 +0100, Edwin van der Heide wrote:
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken.
Roman
On 31/10/23 2:52 am, Roman Haefeli wrote:
There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken.
If I type "command" into the Deken search I get deken-externals as the
only result. If I install this package I can't instantiate [command]
after it's installed. Is this the right package?
Chris.
On Tue, 2023-10-31 at 15:06 +0800, Chris McCormick wrote:
On 31/10/23 2:52 am, Roman Haefeli wrote:
There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken.
If I type "command" into the Deken search I get
deken-externalsas the only result. If I install this package I can't instantiate[command]after it's installed. Is this the right package?
No. The package name is 'command'. This is how it looks like on a Raspberry Pi with Rapsberry Pi OS (Bullseye) arm64:
Roman
Hi,
On 31/10/23 3:58 pm, Roman Haefeli wrote:
On Tue, 2023-10-31 at 15:06 +0800, Chris McCormick wrote:
On 31/10/23 2:52 am, Roman Haefeli wrote:
There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken.
If I type "command" into the Deken search I get
deken-externalsas the only result. If I install this package I can't instantiate[command]after it's installed. Is this the right package?No. The package name is 'command'. This is how it looks like on a Raspberry Pi with Rapsberry Pi OS (Bullseye) arm64:
It appears I accidentally upgraded deken itself by installing
deken-externals and now when I search for command it shows up. Cool
object, thanks for sharing. I will use this instead of ggee/shell from
now on.
Cheers,
Chris.
On 10/31/23 09:07, Chris McCormick wrote:
It appears I accidentally upgraded deken itself by installing
deken-externals
assuming you meant to say "deken-plugin", then yes: if the server detects that you are running a version of the deken-plugin that cannot handle "new-style" .dek packages then it will *always* inject a suggestion for an update of the deken-plugin.
afaik, the first Pd-version that included a deken plugin that can handle new-style .dek packages was Pd-0.48-2, which was released some 5 years ago...
even Raspbian/buster shipped with Pd-0.49-0 :-)
and now when I search for
commandit shows up. Cool
and "command" uses a new-style .dek package, so that's why it shows up after you've updated the deken-plugin.
gmfdsar IOhannes
Dear Roman,
Thanks a lot for this tip!
I’m now studying how to easily parse its output.
Best,
Edwin
On 30 Oct 2023, at 19:52, Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2023-10-30 at 18:21 +0100, Edwin van der Heide wrote:
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
There is the [command] external, which is a fork of [ggee/shell] and is meant as its successor. It's available for Raspberry Pi (32 and 64 bit) through Deken.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 30. Oktober 2023 18:21:50 MEZ schrieb Edwin van der Heide pd@evdh.net:
In the past I have been using the shell object, part of the ggee library, on the raspberry pi using the 32 bit version of the OS.
Now I’ve moved to the 64 bit version of the Raspberry PI OS (aarch64) but there is no version of the ggee library available for this architecture.
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
Sorry if I state the obvious, but have you tried apt-get install pd-ggee ?
mfg.sfg.jfd IOhannes
Dear IOhannes,
This works like a charm and installs it in the extra’s folder.
I didn’t know it was possible to install external libraries via apt-get. Is there a way to know which external libraries are available via apt-get?
Best!
Edwin
On 30 Oct 2023, at 20:55, IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 30. Oktober 2023 18:21:50 MEZ schrieb Edwin van der Heide pd@evdh.net:
In the past I have been using the shell object, part of the ggee library, on the raspberry pi using the 32 bit version of the OS.
Now I’ve moved to the 64 bit version of the Raspberry PI OS (aarch64) but there is no version of the ggee library available for this architecture.
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
Sorry if I state the obvious, but have you tried
apt-get install pd-ggee?mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Try: apt-cache search ^pd-
On 10/31/23 18:41, Edwin van der Heide wrote:
Dear IOhannes,
This works like a charm and installs it in the extra’s folder.
I didn’t know it was possible to install external libraries via apt-get. Is there a way to know which external libraries are available via apt-get?
Best!
Edwin
On 30 Oct 2023, at 20:55, IOhannes m zmölnig zmoelnig@iem.at wrote:
Am 30. Oktober 2023 18:21:50 MEZ schrieb Edwin van der Heide pd@evdh.net:
In the past I have been using the shell object, part of the ggee library, on the raspberry pi using the 32 bit version of the OS.
Now I’ve moved to the 64 bit version of the Raspberry PI OS (aarch64) but there is no version of the ggee library available for this architecture.
Is there an alternative 64 bit version of a shell object available for the PI or is there another way to go?
Sorry if I state the obvious, but have you tried
apt-get install pd-ggee?mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Am 31. Oktober 2023 17:46:33 MEZ schrieb Alexandros Drymonitis adrcki@gmail.com:
Try: apt-cache search ^pd-
Exactly. Virtually all pd-externals packages start with "pd-" (the exception is "gem", which for historic reasons is called like it is)
You can also install the "multimedia-puredata" metapackage, which will install all the Debian packaged externals.
mfg.sfg.jfd IOhannes
Em qua., 27 de jan. de 2021 às 07:12, katja katjavetter@gmail.com escreveu:
Doesn't build, load, or what? If you create a branch with your pd-lib-builder attempt, someone might help figure out why it "doesn't work" (I'm not promising it'll be me).
I haven't really even tried properly. I just tried in the most lazy attempt to include pd-lib-builder and it didn't work (no surprise). Then I tried the makefle as it is and it was a success, so I guess other can build with it just fine. Perhaps other people with better knowledge on how makefiles work can help and make an actual (and probably successful) attempt. I'll merge and we can make a "1.0" release with that.
SoundTouch (from Olli Parviainen https://gitlab.com/soundtouch/soundtouch) uses an autotools build system with configure script. For a makefile approach these configurations have to be figured out (per platform).
However, I'm not sure whether brushing up this old port is worth the effort, also considering the nameclash potential. The CEAMMC port seems to expose more options from the library (anti-aliasing):
https://github.com/uliss/pure-data/blob/ceammc/ceammc/extra/SoundTouch/pd/so...
Unfortunately there's no Linux build of CEAMMC in deken so I couldn't quickly compare implementations. Porres can you explain the reason for updating an old port while there is a maintained implementation available?
Em sex., 29 de jan. de 2021 às 07:37, katja katjavetter@gmail.com escreveu:
However, I'm not sure whether brushing up this old port is worth the effort, also considering the nameclash potential. The CEAMMC port seems to expose more options from the library (anti-aliasing):
https://github.com/uliss/pure-data/blob/ceammc/ceammc/extra/SoundTouch/pd/so...
Unfortunately there's no Linux build of CEAMMC in deken so I couldn't quickly compare implementations. Porres can you explain the reason for updating an old port while there is a maintained implementation available?
I'm just getting things available on the internet somewhere and putting it in deken as well as it feels like the main place to get all externals for Pd. You have these binaries provided in your page, and maybe people are using it. Maybe people need to use a version for 64 bits, especially now that macOS is 64 bits only. The nameclash is still true and happens if people get it from your website. It sucks I know, but it happens every now and then here and there. It did also happen inside Pd Extended. What we need is a way to deal and manage this and we already have it.
Anyway, unless you really feel this shouldn't be available anywhere anymore, and in that case I mean it should also be removed from your website? Of course I don't think that should be the case, especially because you have an amazing article over there.
I haven't really compared the implementations of ceammc, but what usually happens is that externals from ceammc have some particularities that are special to that fork of Pd, like special messages using "@", and they're usually integrated into that system. Having a single, light, updated and independent version of soundtouch~ for all systems seems like a good idea. The more the merrier.
On 2/2/21, Alexandre Torres Porres porres@gmail.com wrote:
[...]
I haven't really compared the implementations of ceammc, but what usually happens is that externals from ceammc have some particularities that are special to that fork of Pd, like special messages using "@", and they're usually integrated into that system. Having a single, light, updated and independent version of soundtouch~ for all systems seems like a good idea.
[...]
In the meantime I did some attempts to build pd-ceammc but failed so still can't compare, but I get your point. The method(s) to avoid nameclash could be documented in the readme text.
-
Alexandre Torres Porres -
Alexandros Drymonitis -
Chris McCormick -
Edwin van der Heide -
IOhannes m zmölnig -
katja -
Roman Haefeli