Re: [PD] Mailing list archive search: Remove attachment.htm results?

[IOhannes m zmoelnig]

On 4/23/24 08:56, Peter P. wrote:

Hi,

The search function on https://lists.puredata.info/pipermail/pd-list//
is great, but a large number of search results are of the form
"/pipermail/pd-list/attachments/20160527/3e480100/attachment.html"
and are more or less unreadable.

I would like to suggest to exclude them from the indexing or from the
results if possible.



what you are seeing is emails that come with both HTML and plaintext.

typically, a mail-client that composes HTML mail, will include the same 
information in a plaintext part of the email. but there's not really 
anything enforcing this (if you are usually reading plaintext emails, 
you will know this "you need an HTML-capable mail client to read this" 
message)


as such, i do not think there's anything wrong with including the HTML 
parts (even if they are rendered verbatim) in the search results, as 
they might contain information otherwise unavailable.


however, what is definitely wrong is that the "sort by relevance" does 
not really do what it promises.
at least i get HTML-attachments with a relevance of 73% sorted before 
the plaintext posts with 100% relevance.


in any case, i'm afraid this is rather low priority.
in the meantime you could try filtering out the HTML attachments by 
excluding some html tag (e.g. adding ` -div ` to the search terms helps 
for me; however, this will also exclude mails that discuss the use of 
[div]...)



msfdgasdr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] deken server seems to be down

[IOhannes m zmoelnig]

On 4/22/24 10:44, Edwin van der Heide wrote:

It seems the deken server is not working at the moment.


yes sorry.
yesterday we did some maintenance upgrade of the server running the 
deken backend, and it obviously didn't survive that.
unfortunately i had been busy the whole day, so i missed your mail. and 
eventually forgot about it.


anyhow: all things should be back to normal again.

amdrs
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [gem] trigger in gemchain

[IOhannes m zmoelnig]

On 4/16/24 14:56, Patko nytkophilus wrote:




Le 16 avr. 2024 à 10:51, cyrille henry  a écrit :


[trigger] are usually transparent in a gemchain. This is the only 
counterexample I am aware.
It also mean that you can't adapt my L-System example 
(02.Advanced/21.basic_LSystem), or Claude recursion tutorial 
(example/13.recursion) to use texture.


I did once recursion with textures, but I had to use pix_data to retrieve 
textured pixels.


the proper way is of course to use [pix_texture] to share a texture 
between different subtrees.


mdfs
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Jack transport on Linux

[IOhannes m zmoelnig]

On 4/15/24 10:15, Alexander wrote:


The external you mention can be found here:
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/tb/jack_transport/




ah yes, i didn't remember which library it was in, so didn't find it 
immediately:


in any case: if you prefer a git-checkout over svn (nobody these days 
has SVN installed anymore), you can also get it from 



(it's readonly, but for all practical purposes the SVN is readonly as well).


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Jack transport on Linux

[IOhannes m zmoelnig]

On 4/15/24 09:33, Lorenzo Sutton wrote:

Hi all,

I used to be able to do Jack transport on Linux with the external once 
hosted at http://artdent.homelinux.net/svn/jack_transport~/ which now 
seems to be dead.


Any other known externals or ideas? I need to simply synchronize Pd to 
Rosegarden [1] and jack transport would be the most straightforward way 
of doing it. I could also look into MIDI synchronization but I don't 
really need anything fancy like tempo changes etc. so would ideally 
avoid that route, also because I'm setting this up for a live performance.


Any ideas or pointers welcome.


maybe this?


gfadmsr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd.iem.at down?

[IOhannes m zmoelnig]

On 4/3/24 04:38, Peter P. wrote:

Hi,

i am getting a "Service unavailable" response from my browser trying to
access http://pd.iem.at/ while other sites such as http://puredata.info/
are accessible.



our IT department changed some firewall rules during the easter hols and 
we are still recovering from the fallout.


at least mails to the mailinglists get through again :-)

gfamdsr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] hid objects on linux/mac/win? hidraw on linux? hidraw parsing?

[IOhannes m zmoelnig]

On 3/14/24 10:57, Patko nytkophilus wrote:


This version have been uploaded this week after seing this thread, that 
explains why it didn't appear yet, meanwhile I don't get why the date is 2022.



i do not really know.

however, inspecting the deken package with my trusted `zipinfo`, i see 
that the files within are also timestamped 2022-11-09:

```
$ zipinfo hid\[v0.1.0\]\(Darwin-arm64-32\).dek
Archive:  hid[v0.1.0](Darwin-arm64-32).dek
Zip file size: 12879 bytes, number of entries: 2
-rw-r--r--  2.0 unx 2690 b- defN 22-Nov-09 00:09 hid/hid-example.pd
-rw-r--r--  2.0 unx71386 b- defN 22-Nov-09 00:20 hid/hid.pd_darwin
2 files, 74076 bytes uncompressed, 12635 bytes compressed:  82.9%
```

the the .dek files are served as-uploaded, so i suspect that the 
wrongish timestamp comes from the computer that created the package.


gfamdsr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] GEM. pix_record producing 1 frame videos

[IOhannes m zmoelnig]

On 2/21/24 09:00, altern wrote:


sorry, it is PD 0.54.1 for windows 64 bits, the portable version


thanks.


GEM: video record plugins: PNM


ah well.
the only recording capability that is available for your installation is 
PNM, which creates a portable anymap image, and not really a "film" in 
the traditional sense.


the use-case is typically to write the data to a named pipe and then use 
ffmpeg or whatever to turn that into a real film:


from the commit message:

1. `mkfifo fifo.ppm`
2. record frames into `fifo.ppm` with this plugin
3. encode video with `ffmpeg -f image2pipe -i fifo.ppm ...`


i probably have to add this to the actual documentation.

i'm afraid there is no real video recording backend available on Windows 
at the momemt (there used to be a QuickTime based backend, but apple 
never made this available for 64bit systems - including Windows; also 
iirc the quicktime backends required Gem to be compiled with MSVC which 
i no longer do).


gdmasr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Can't load iemmatrix lib

[IOhannes m zmoelnig]

On 1/17/24 15:47, Alexandros Drymonitis wrote:
I've installed iemmatrix from deken, but when I put a [declare -lib 
iemmatrix] in Pd, I get the following error:


that should be fixed with iemmatrix-0.4.0

gfdmasr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] iemmatrix 040 released

[IOhannes m zmoelnig]

iemmatrix 0.4.0 "double square" aka (040²)ⁿ has been released last night.



**developed for science**

most notable features:
- 23 years of relentless development
- 130 battle tested objects
- 13473 lines of spellchecked C-code (without docs!)
- 5575 lines of analyzed Pd-code (without docs!)

**used in science**

NEWS
- multichannel support
  - optional: works out of the box with Pd>0.54
  - also works with older Pds
- improved resiliency against system incompatibilities
  - the core will work on very old systems and very new systems
  - some specialized objects that require 3rd party libraries
might only run on newer systems (but you can still use most
objects if your system does not meet these requirements)
- lots of bugfixes

**used in /real/ science**

supported platforms via Deken packages
- Linux/amd64 ("64bit intel",...) single precision†
- Linux/amd64 ("64bit intel",...) double precision†
- Linux/i386 ("32bit intel",...) single precision†
- Linux/i386 ("32bit intel",...) double precision†
- Linux/arm64 ("64bit RPi >=4",...) single precision†
- Linux/arm64 ("64bit RPi >=4",...) double precision†
- Linux/armv7 ("32bit RPi >=2",...) single precision†
- Linux/armv7 ("32bit RPi >=2",...) double precision†
- macOS/amd64 ("64bit intel",...) single precision‡
- macOS/amd64 ("64bit intel",...) double precision‡
- macOS/arm64 ("Apple Silicon",...) single precision
- macOS/arm64 ("Apple Silicon",...) double precision
- Windows/amd64 ("64bit intel",...) single precision
- Windows/amd64 ("64bit intel",...) double precision
- Windows/i386 ("32bit intel",...) single precision
- Windows/i386 ("32bit intel",...) double precision

supported platforms via Debian packages (coming soon in the 
Debian/unstable repositories):

- Linux/amd64 - single precision
- Linux/amd64 - double precision
- Linux/arm64 - single precision
- Linux/arm64 - double precision
- Linux/armel - single precision
- Linux/armel - double precision
- Linux/armhf - single precision
- Linux/armhf - double precision
- Linux/i386 - single precision
- Linux/i386 - double precision
- Linux/mips64el - single precision
- Linux/mips64el - double precision
- Linux/ppc64el - single precision
- Linux/ppc64el - double precision
- Linux/riscv64 - single precision
- Linux/riscv64 - double precision
- Linux/s390x - single precision
- Linux/s390x - double precision
- Linux/alpha - single precision
- Linux/alpha - double precision
- Linux/hppa - single precision
- Linux/hppa - double precision
- Linux/ia64 - single precision
- Linux/ia64 - double precision
- Linux/loong64 - single precision
- Linux/loong64 - double precision
- Linux/m68k - single precision
- Linux/m68k - double precision
- Linux/powerpc - single precision
- Linux/powerpc - double precision
- Linux/ppc64 - single precision
- Linux/ppc64 - double precision
- Linux/sh4 - single precision
- Linux/sh4 - double precision
- Linux/sparc64 - single precision
- Linux/sparc64 - double precision
- Linux/x32 - single precision
- Linux/x32 - double precision
- Hurd/i386 - single precision
- Hurd/i386 - double precision

if your system is not listed above, you can compile iemmatrix yourself 
(you are probably used to that already)



**used by serious scientists**


get it while it's hot.




~~~

notes on compatibility with older OSs

† the Deken binaries for Linux require GLIBC-2.29, such as found on 
Linux distributions released after 2020, such as Ubuntu/20.04 "focal" or 
Debian/11 "bullseye"; but notably *not* on Debian/10 "buster".


‡ the Deken binaries for macOS have been tested to work back to OSX 
10.11 "El Capitan".
some specialist objects require a newer version of macOS however. e.g. 
heavy math like decomposing matrices with [mtx_eig], [mtx_qr] and 
[mtx_svd] requires macOS 10.14 "Mojave", as does [mtx_bessel]. 
[mtx_sndfileread] requires macOS 11 "Big Sur". if you do not need these 
specialized objects, then "El Capitan" will do nicely.


independent of iemmatrix, we strongly suggest that you use an up-to-date 
operating system for the safety of yourself and others.


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Can't load iemmatrix lib

[IOhannes m zmoelnig]

On 1/18/24 12:25, Linux ROUEN Normandie wrote:
Same issue here with 'iemmatrix' library (0.3.3 as of 2023/07/19 thru 
Deken) under Linux Mint 21.3 (Ubuntu 22.04-4 base) / Pd 0.54-1:

"/home/joe/Pure-Data/externals/iemmatrix/iemmatrix.pd_linux:libgsl.so.25:
cannot open shared object file: No such file or directory".

But 'libgsl25' is not available under my system (neither apt nor 
Synaptic), only 'libgsl27' (2.7.1+dfsg-3) is.



since the problem is exactly the same as described by Alexandros, the 
answer is exactly the same as well.


(ah well: replace "Debian" with "Ubuntu", or your distribution of 
choice; and replace the version number "12" with any version of your 
distribution that ships libgsl!=25 and "11" with any version of your 
distribution that ships libgsl==25).



and peter's advice goes for Ubuntu as well:
just install the pd-iemmatrix package via apt (or your preferred package 
manager of your distribution).


and finally: if you prefer to install all packages via deken, you might 
want to try to install the (somewhat experimental) "pd-deken-apt" 
package, which allows you to install your Debian packaged externals 
through deken (it's really just a replacement of synaptics for Pd packages)


hfdmsrt
KIOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Can't load iemmatrix lib

[IOhannes m zmoelnig]

On 1/18/24 07:57, Alexandros Drymonitis wrote:


On 1/18/24 08:56, Alexandros Drymonitis wrote:


On 1/18/24 08:53, IOhannes m zmoelnig wrote:

On 1/18/24 07:46, Alexandros Drymonitis wrote:
The funny thing is that I did install libgsl27 manually with 
apt-get, after I read the error I got in Pd, but it still didn't 
work with the Deken version.


[...]


/home/alex/Documents/Pd/externals/iemmatrix/iemmatrix.pd_linux:libgsl.so.25:
cannot open shared object file: No such file or directory


well, it seems that the iemmatrix from deken was linked against 
libgsl25, so installing libgsl27 doesn't really help to resolve this 
dependency.
Yeah, makes sense. Does this mean that the deken version of iemmatrix 
needs to be updated?


depends.
if the target platform is Debian 12, then yes.
if the target platform is Debian 11, then no.


i've opened https://git.iem.at/pd/iemmatrix/-/issues/7

I'm writing this because my system could only detect libgsl27, and not 
libgsl25.
sure, the world evolves. Debian does not ship all versions of GSL ever 
released (and that's a good thing)


g,mads
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Can't load iemmatrix lib

[IOhannes m zmoelnig]

On 1/18/24 07:46, Alexandros Drymonitis wrote:
The funny thing is that I did install libgsl27 manually with apt-get, 
after I read the error I got in Pd, but it still didn't work with the 
Deken version.


[...]


/home/alex/Documents/Pd/externals/iemmatrix/iemmatrix.pd_linux:libgsl.so.25:
cannot open shared object file: No such file or directory


well, it seems that the iemmatrix from deken was linked against 
libgsl25, so installing libgsl27 doesn't really help to resolve this 
dependency.


gdmsf
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] trying to test 'pdp library and 'pdp_scan~'

[IOhannes m zmoelnig]

On 1/16/24 17:12, Alexandre Torres Porres wrote:

Em ter., 16 de jan. de 2024 às 05:08, cyrille henry  escreveu:


Hello,
If you want to try scann synthesis, I suggest to try pmpd. specially
example 47.



Running this in Extended now, it looks amazing. Do we really need Gem
though? 


not at all.
Gem just does the visualiation, but the actual physical model runs 
within pmpd on the CPU.




As for pdp, it seems it tries to use the webcam or video sources and I
don't understand why.


because it does something different.
[pdp_scan~] will scan an image along a trajectory, and convert the 
traversed pixels to samples.
it's not really what "scanned synthesis" is referred to in the wikipedia 
article and the like.




Would love to dig more in it and provide an external myself but it looks
quite complex...


or you could just use pmpd?
i don't fully understand the benefit of re-implementing everything that 
is already out there.


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] trying to test 'pdp library and 'pdp_scan~'

[IOhannes m zmoelnig]

On 1/15/24 22:45, Alexandre Torres Porres wrote:

When reading about 'Scanned synthesis' in
https://en.wikipedia.org/wiki/Scanned_synthesis I see about the [pdp_scan~]
external from 'pdp', but I can't use it... I can still try extended in my
machine and it didn't really work back then, I get

Applications/Pd-extended.app/Contents/Resources/extra/pdp/pdp.pd_darwin,
10): Library not loaded: /usr/X11R6/lib/libX11.6.dylib


you need X11 for pdp. iirc, on macOS you can install it via XQuartz.

to quote from their homepage:
> it forms the X11.app that Apple shipped with OS X versions 10.5 
through 10.7.


which kind of explains why pdp worked with older versions of OSX, but 
not with current macOS.





Purr Data can't load it either.


obviously, you still need X11.



The 'pdp' version in deken (0-0extended) doesn't work either and all print
the same error.


as expected.



I wanted to check this object out, does anybody know where the source lives
and if we can try and compile it?


where all externals lived in the days of yore: the sourceforge SVN


a read-only git repository can be found at 




the code hasn't been touched in 12 years, it probably won't compile on 
modern systems.


Debian still provides pdp binaries, so there's a couple of patches that 
allow us to build on this platform. find them at 



these patches might be very Debian specific (solving problems that only 
exist on this platform), i have no idea whether they might help building 
on macOS.



and finally, there's of course the official homepage: https://zwizwa.be/pdp/

gmasdr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] How to deal with externals for both 64 and 32-bit Pd

[IOhannes m zmoelnig]

On 12/6/23 11:07, IOhannes m zmoelnig wrote:
now that i've written this, i notice that I haven't actually uploaded 
any of my new packages to deken yet (that's mostly because i haven't 
done any new release yet).


at least i've fixed the upload for zexy for now.

others might follow.


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] help needed: "conditional" help patches

[IOhannes m zmoelnig]

On 12/11/23 16:04, Christof Ressi wrote:


Interesting. The big disadvantage is that the roles are reversed: what 
should be a subpatch is now the root window, so when the user tries to 
close it, it closes the whole help patch... So I guess I'd rather prefer 
my current solution.


totally. i was just trying to come up with alternative solutions.



But thanks for your input!


so how about that one:
your object could do some context-check, and suppress the error message 
when it is invoked in a help patch.
(the simplest check would just be whether the filename of the containing 
patch ends with "-help.pd"; alternatively you could embed some magic 
string in your help patch (on patch-level) and suppress the error only 
if this string is (also) present.




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] help needed: "conditional" help patches

[IOhannes m zmoelnig]

On 12/11/23 15:29, Christof Ressi wrote:
Ok, I have a come up with the following solution: I moved the 
multichannel section into a dedicated patch and open it with [;pd open 
  1( when the user clicks a bang button in the main help 
patch. It's not perfect, but kind of works for my purposes.


so the user only gets the error if they click on the bang?
hmm.



I am still wondering if anyone has run into the same issue and found 
other solutions.



i don't, but here's my thoughts:

- i think class_sethelpsymbol() is evil in practically all cases (that 
do not deal with names that cannot be represented as filenames; and even 
these cases some hexmunging might be a better solution than 
class_sethelpsymbol())
- personally i wouldn't care to much about error messages in help 
patches (as in: going through hoops in order to avoid them). since in 
this case you control the actual error message make sure that it is 
friendly enough (e.g. just telling people that they will need a newer 
version of Pd in order to use this cool feature) - i strongly believe 
that we can expect people to actually read and understand an error 
message (and not just seek help just because "lines were red"). it's not 
that Pd's error messages are very obtrusive)


if you absolutely insist on not having error messages and do not share 
my aversion against class_sethelpsymbol() you could create two help 
patches and in the multichannel version *only* document the multichannel 
features and include the non-multichannel help patch as an ordinary 
object (probably with some "auto open" code. that way you wouldn't have 
to duplicate the common documentation.


mhdgs
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] alsa crashing on recent Pi OS

[IOhannes m zmoelnig]

i forgot a few more things...

On 12/7/23 12:27, IOhannes m zmoelnig wrote:


IEMberry provides only very few packages by itself, and instead relies 
on the Debian packages. It also has Debian/backports and the official 
Raspberry Pi OS repositories enabled (with Debian being preferred).


i've done a full upgrade ("apt update; apt full-upgrade") the other day.
this upgraded a bunch of packages (though I don't think anything related 
to Pd)




i've run the "humanCaller_test.pd" patch for about half an hour without 
any problems, using ALSA as the backend.



i do see the following lines:
```
restart alsa output
alsa xrun recovery apparently failed
```

but they they are printed only once at startup.




seeing that everything works, i've stopped Pd, launched jackd (again 
making sure to output to the headphones instead of the non-existant 
monitor) and tried with JACK as backend.

after another 10 minutes I decided that everything works great.



i've also started Pd with "-nogui" for both ALSA and JACK (still running 
a full-fledged Desktop over VNC though) and haven't experienced any 
problems so far.


gfmasdr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] alsa crashing on recent Pi OS

[IOhannes m zmoelnig]

On 12/4/23 21:23, Yann Seznec wrote:



I’ll answer both of these questions at once…to be more clear, the most 
obvious test of the Pi issues I was having is to launch 
“humanCaller_test.pd” from this project: 
https://github.com/yannseznec/humanCall 



It is a granular patch that will just play a stream of grains on startup.

When I was encountering issues, this patch would stop working after 
somewhere between 30-90 seconds, and print many instances of the error 
“restart alsa output alsa xrun recovery apparently failed”.


I am no longer having this issue, after compiling Pd 0.54.1 myself on 
the 32 bit Pi OS 11.


since I was just playing along with an RPi4 i thought i'd give it a try.



hardware: Raspberry Pi 4 (Model B, 4GB RAM; iirc!)
 using the onboard soundcard
operating system: IEMberry
graphics: running without monitors, but with a full Desktop connected to 
via VNC

Pd: Pd-0.53-1, as packaged
sound: ALSA

IEMberry is our in-house RPi4 distribution, it's basically a Raspberry 
Pi OS (32bit) with loads of audio and development tools preinstalled.

  https://iemberry.iem.at/
i'm using iemberry11.20231017 (as can be currently downloaded on the 
webpage), which is based on Raspberry Pi OS "Bullseye" 11 (the "with 
desktop and recommended software" flavour).
The image was generated Mid-October, so it obviously did *not* use 
"Raspberry Pi OS (Legacy)" as can be found on the RPi homepage right 
now, as the latter was released 2023-12-05. Instead, the base image was 
the last release of Rasbian available back then, which turns out to be 
have been released 2023-05-03).


IEMberry provides only very few packages by itself, and instead relies 
on the Debian packages. It also has Debian/backports and the official 
Raspberry Pi OS repositories enabled (with Debian being preferred).


IEMberry comes with Pd from Debian/bullseye-backports pre-installed:
```
$ pd -version
Pd-0.53-1 ("") compiled for Debian (0.53.1+ds-2~bpo11+1) on 2023/01/31 
at 6:55:52 UTC

```

in order to get your patch running, I did:
- disconnect the [print button] object
- switch the Output Device to "bcm2835 Headphones (hardware)" (for 
whatever reason it preferred the "HDMI 1" output, even though no monitor 
is connected; probably some VNC thing)

- make sure to disable audio input (as the onboard soundcard has no adc)

i've run the "humanCaller_test.pd" patch for about half an hour without 
any problems, using ALSA as the backend.


seeing that everything works, i've stopped Pd, launched jackd (again 
making sure to output to the headphones instead of the non-existant 
monitor) and tried with JACK as backend.

after another 10 minutes I decided that everything works great.

gmadsr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] How to deal with externals for both 64 and 32-bit Pd

[IOhannes m zmoelnig]

On 12/6/23 09:44, Lucas Cordiviola wrote:


On 06/12/2023 05:27, Alexandros Drymonitis wrote:
Sorry for the second question, now read the pd-lib-builder README. It 
states that 64-bit externals will indeed get a different name. 



essentialy you need to do 2 compilations (no need to use different 
m_pd.h as they are the same)


then you have 2 files:

  - my_lib.linux-amd64-32.so

  - my_lib.linux-amd64-64.so



while this will work with Pd>=0.54, i would advice everybody to use the 
old-style extensions for the Pd32 externals:


>   - my_lib.l_amd64
>   - my_lib.linux-amd64-64.so

old-style extensions will not be used by Pd64 (so there's no danger in 
accidentally loading the wrong binary), but they *can* be loaded by 
older versions of Pd (which are Pd32 only).


of course, if you are using newer features that require Pd>=0.54 anyhow 
(e.g. multichannel), then by all means use the new-style extensions for 
Pd32 as well.


gdmasr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] How to deal with externals for both 64 and 32-bit Pd

[IOhannes m zmoelnig]

On 12/6/23 09:12, Roman Haefeli wrote:

Just compile it against the m_pd.h of the double-precision edition of
Pd.


this won't work, as the "m_pd.h" for Pd64 and Pd32 are exactly the same.

instead set the "PD_FLOATSIZE" macro to 64 when building the external.

reasoning:
- just building with "-DPD_FLOATSIZE=64" should be simple enough
- using two headers with different names ("m_pd.h", "m_pd64.h") just 
moves the problem: the source code has to decide which header to 
include, and it most likely does this via some macro; so go back to 
square 1)
- shipping two different headers (with the only difference being the 
PD_FLOATSIZE macro) with the same name is going to breed confusion: 
where do you find which header (this mostly matters with systems where 
header-files are not bundled with an application, but installed to a 
global place, like /usr/include)
- for systems where the headers are bundled with application, i think we 
should bundle both Pd32 and Pd64 together (which we already can, its 
just that the downloadable packages don't do that yet). so back to square 3.



gfnsdrt
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] How to deal with externals for both 64 and 32-bit Pd

[IOhannes m zmoelnig]

On 12/6/23 08:43, Alexandros Drymonitis wrote:

Ahem, I should have guessed that...

The question now is how to have both versions run happily side by side? 



for Pd on Debian the answer is:
- install both "puredata" and "puredata64"
- if you are a cmdline person, launch pd32 by typing "pd", and pd64 by 
typing "pd64" in your favourite shell
- if you are a GUI person, just launch the Pd-GUI and select the falvour 
via the preferences (you need to restart Pd for this to have an effect).


On the 64-bit version I did find zexy (but some other libraries I 
searched for, including my own, neuralnet, were not available - not a 
surprise for my own, I haven't compiled it for the 64-bit version), but 
installing it through deken, breaks compatibility with the 32-bit 
version (I guess it overrides it). So when I open the 32-bit version, 
zexy is no longer available. If I install it through deken from the 
32-bit Pd, then it's not available for the 64-bit Pd.



the issue is, that when installing a library (e.g. "zexy") it will first 
attempt to uninstall older versions of it (by simply deleting the "zexy" 
folder in the target directory).
so if you first installed a version that only contains the 
Linux-amd64-32 version of zexy, and then install a version that *only* 
contains the Linux-amd64-64 version of zexy, the first installation will 
be removed, and you now can no longer load zexy in a Pd32.


there are three options to solve this issue:
1. user: disable the "Try to remove libraries before (re)installing 
them" option in the deken preferences
2. user: follow roman's advice of using different search paths for Pd32 
and Pd64

3. maintainer: ship both Pd32 and Pd64 binaries in your deken package

the 1st option is not really good, as you will accumulate cruft (e.g. 
outdated files that are no longer shipped in newer versions of the 
library will stay on the user's disk, leading to much confusion). that's 
the reason why we have this "uninstall" option in the first place


the 2nd option is probably okayish (and it's the best thing the user can 
do). one concern is that you need to install all libraries twice, even 
if they are just abstractions (and therefore could be shared between 
Pd32 and Pd64, and macOS and Windows; and ...).


my concern with both these options is, that each user has to fix their 
system themselves.


that's why i personally favour the 3rd option.
it does require some work on the maintainer side, but for the users it 
is pretty transparent.



in theory i have setup my builders to produce packages that have both 
Pd32 and Pd64 binaries, but obviously zexy-2.4.2 was built and uploaded 
before i decided on implementing this.


as a sidenote, when shipping both Pd32 and Pd64 packages, it turned out 
that the deken filename scheme can get to its limits.
i typically build my libraries for (macOS, Linux and Windows) for 
(amd64, i386, arm64 and armv7) and now for (Pd32 and Pd64) as well.
i do not build all combinations (no Windows/armv7/Pd64 packages), but i 
currently do build for 16 different architectures.
putting all these binaries into a single deken package will require a 
filename that has 264 characters solely for the architecture specifiers, 
which simply hits the maximum filename length on many OSs (practically 
*all* major filesystems only support up to 256 chars).


i do believe that it is beneficial to ship as little packages as 
possible, both for the user (who should only need to download once even 
if they use Win32/Pd32 and Win64/Pd64 and Win64/Pd32 on the same 
machine) and for our server infrastructure (there are some really big 
libraries like "ELSE": the size is mostly drowned in media files  which 
are shared between all packages; creating 16 different packages will eat 
about 1GB of server space just for a single release candidate)


so that's why i've started to create per-OS packages (there's a Windows 
download, a macOS download and a Linux download; each comes with 
multiple CPU-architectures and both Pd32 and Pd64)



now that i've written this, i notice that I haven't actually uploaded 
any of my new packages to deken yet (that's mostly because i haven't 
done any new release yet).


gfmasdr
IOhannes




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] alsa crashing on recent Pi OS

[IOhannes m zmoelnig]

On 12/1/23 09:03, Yann Seznec wrote:

Hi again,

I’m wondering if anyone else is having the same issue as me. I’m trying 
to run Pd patches on Raspberry Pi, and I (perhaps naively) thought that 
I would use the latest Pi OS.


I seem to be having far more issues than I had in the past, namely with 
alsa crashing. It seems like virtually any patch I run will sooner or 
later crash and print hundreds of lines of this error:

restartalsa output alsa xrun recovery apparently failed

Someone on the Pd Forums 
 suggested that this could be an issue with the latest Pi OS switching to PipeWire, which seems to make some sense. But before I attempt any fixes, I wanted to see if anyone else was running into this problem or might have some suggestions.


Alternatively, can anyone suggest to me a version of the raspberry pi 
operating system that works well for Pd? Perhaps it will be easiest for 
me to track down an old OS image and just stick to that.






personally, i would try getting PipeWire to run with Pd over the JACK 
interface.
However, I haven't tested this yet (on the RPi), and it might be that 
the default latency you get is really bad.


if this is not an option (and Pd is the only audio process), I would try 
to get rid of PipeWire altogether.



> - Trying to run a small granular patch like this
>  or a sampler/looper patch like
> this 

when you say "like this" do you mean, that exactly these two patches 
fail? (I'm just trying to make sure that if I test with these patches it 
actually makes sense)


gfasd
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd-list Digest, Vol 225, Issue 2

[IOhannes m zmoelnig]

On 12/4/23 13:00, Thomas Mayer wrote:

Hello,

On 04.12.23 10:55, Yann Seznec wrote:> As a side note, perhaps someone 
more knowledgeable than me could update
the version of Pd that is currently accessible from apt-get? I didn't 
mind compiling from source but it is pretty handy to be able to just 
do apt-get when setting up a new Pi.


i'm not sure i understand the question here.

you can always get the version of Pd by just running 'pd -version' (if 
you still have the "puredata-core" package installed, run '/usr/bin/pd 
-version' to not accidentally run your self-compiled one.


in any case, which version of Pd is shipped with Raspberry Pi OS depends 
of course on the version of Raspberry Pi OS itself.


the latest and greatest Raspberry Pi OS is based on Debian/bookworm, and 
therefore comes with Pd-0.53-1 (see 
)





I am unsure, if Raspberry Pi OS is based on Debian or is actually using 
the Debian sources


traditionally they (Raspberry Pi OS) provide their own binaries. iirc 
this is because they are really targetting armv6 (without FPU), as found 
in the Pi Zero, which is not supported by Debian's armhf flavour (which 
requires an FPU). (or maybe it's some other CPU feature, not the FPU; in 
any case: something along these lines).


i'm not sure about the situation for RPiOS/64bit.
as i don't have an RPi/64bit booted, i've checked 
, which seems to only come with 
a small subset of packages, so it's possible that they indeed switched 
to the official Debian repository)


.


You can look that up in /etc/apt/sources.list or a file in 
/etc/apt/sources.list.d/


If it contains a line like

deb http://ftp.de.debian.org/debian/ stable main contrib non-free


typically you would use http://deb.debian.org/debian/ instead of a 
country-specific URL (unless you have specific reasons not to, like an 
aversion against CDNs like CloudFlare or Fastly; or a specific mirror is 
really close to you).



fnsae
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] 2nd call: PhD position Sonic Interaction Design, IEM/ KUG, Graz, Austria

[IOhannes m zmoelnig]

[Apologies for cross-postings] [Please distribute]

(this is the 2nd call for a 4 year stay at the IEM and a great chance to 
get your PhD done. please apply!)



Dear all,

we are pleased to announce a fully funded

*4-year PhD position*

in the field of Sonic Interaction Design at the Institute of Electronic 
Music and Acoustics (IEM, https://iem.at/), University of Music and 
Performing Arts Graz, Austria. Current projects are compiled at 
https://sidlab.iem.sh/.


All details can be found in the call for applications (German, English): 
https://go.iem.at/sid23


We look forward to receiving your application by December 1st, 2023.

IOhannes m zmölnig


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] win11 deken sha256-problem

[IOhannes m zmoelnig]

On 11/21/23 10:57, ro...@dds.nl wrote:

no problems with my Win11 and Pd.0.54.1.


while i don't know about the actual cause of it, i was able to reproduce 
the problem (also with the zip package of Pd).


(it seems that on some systems the filename is included alongside the 
calculated hash, so the comparison with the hash (without the filename) 
fails)


i've opened a ticket on 


fgmdasr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] win11 deken sha256-problem

[IOhannes m zmoelnig]

On 11/20/23 10:37, Antoine Rousseau wrote:

yes, same here on a win11 machine.
I recently updated Pd to 0.54.1, I *think* it was working normally before,
with an older Pd/deken.


yes.
iirc, the version of deken thatships with the latest and greatest Pd now 
tries harder to validate the downloads.


gfmasdr
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] off topic: congrats Miller for the Silver Lion award from La Biennale di Venezia

[IOhannes m zmoelnig]

On 10/21/23 04:17, Alexandre Torres Porres wrote:

see https://www.labiennale.org/en/music/2023/silver-lion


without saying, this is very well deserved.

but i guess, in this case it is better to make it "with saying", so:
congratulations!

ghfdmast
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.54-0 testtone.pd

[IOhannes m zmoelnig]

On 10/23/23 11:54, Nick Burge via Pd-list wrote:

Dear pd-list, I’ve noticed that as I  adjust the Input Monitor gain in the 
testtone patch, the pd console prints the message “clip: no method for set”
Is this a bug? Thanks.


yes.

gasmdr
IOhannes



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] PhD position: Sonic Interaction Design, IEM/ KUG, Graz, Austria

[IOhannes m zmoelnig]

[Apologies for cross-postings] [Please distribute]

Dear all,

we are pleased to announce a

*4-year PhD position*

in the field of Sonic Interaction Design at the Institute of Electronic 
Music and Acoustics (IEM, https://iem.at/), University of Music and 
Performing Arts Graz, Austria. Current projects are compiled at 
https://sidlab.iem.sh/.


All details can be found in the call for applications (German, English): 
https://go.iem.at/sid23


We look forward to receiving your application by December 1st, 2023.

mgfsdr-ase
IOhannes


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] New Externals for the SoundScape Renderer + ASDF external

[IOhannes m zmoelnig]

On 8/1/23 09:43, Matthias Geier wrote:


However, I have just noticed that for some reason
"-mmacosx-version-min=10.15" gets added to the compiler invocation as well.



like that?


also: i think you need the entire dependency chain to be build with the 
proper -mmacosx-version-min.
that is: if you use dependencies that require a higher 
macosx-version-min, you might be out of luck anyhow:
> ld: warning: dylib (/usr/local/lib/libfftw3f.dylib) was built for 
newer macOS version (12.0) than being linked (10.15)
> ld: warning: dylib (/usr/local/lib/libsndfile.dylib) was built for 
newer macOS version (12.0) than being linked (10.15)
> ld: warning: dylib (/usr/local/lib/libmysofa.dylib) was built for 
newer macOS version (12.0) than being linked (10.15)
> ld: warning: dylib (/usr/local/lib/libmpg123.0.dylib) was built for 
newer macOS version (12.0) than being linked (10.15)
> ld: warning: dylib (/usr/local/lib/libmp3lame.0.dylib) was built for 
newer macOS version (12.0) than being linked (10.15)


gamsdrf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] For info: 3 minor issues with Pd 0.54.0 and ELSE 1.0-0 rc-8 under Linux Mint 21.1

[IOhannes m zmoelnig]

On 7/20/23 07:20, Alexandre Torres Porres wrote:

2) hmmm, where is the post for sigmund~ version?


should there be one?

while I see that you (@porres) have updated the version printout to show 
"sigmund~ version 0.08", this particular code-path is only called when 
compiling sigmung~ for Max/MSP.


dmjasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [resend] Re: For info: 3 minor issues with Pd 0.54.0 and ELSE 1.0-0 rc-8 under Linux Mint 21.1

[IOhannes m zmoelnig]

(one shouldn't write mails on a mobile phone when trying to clarify 
things; it tends to add autocorrection noise, which might make the 
"clarification" even harder to understand. so i'm re-sending this, 
hopefully with typos fixed)


On 7/16/23 14:10, Linux ROUEN Normandie wrote:

Duly noted!


On re-reading I figure that I came across rougher than intended...

My point was really:
2. Yes, there's a warning about obsolete objects, but it *is* somewhat 
hard to deprecate something, document its existence, warn about the 
deprecation and at the same time *not* emit a warning in the interactive 
documentation of an instance based programming language such as Pd. (the 
hard part is doing all of the above at the same time)


3. (The answer to this point sounded even gruffier, but what I meant 
is:) people have requested to enlargen the font size a bit, so that's 
why we changed it. However, it is possible to override these new 
defaults (using preferences), if they don't fit your workflow.


Sorry.


mfg.sfg.jfd
IOhannes




OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.54-0 released

[IOhannes m zmoelnig]

On 7/4/23 06:46, Miller Puckette wrote:

To Pd announce:

Pd version 0.54-0 is available from http://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data .


hooray!

for those who need to download via https, get it via 
https://puredata.info/downloads/pure-data/releases/0.54-0


I've also uploaded experimental double-precision builds (only for 64bit 
platforms):

https://puredata.info/downloads/pure-data/releases/0.54-0-pd64

have fun.

gfasdr
IOhannes

PS: there are no Debian packages yet (as I have to go through some 
bureaucratic hickups first; hopefully they will be available within the 
next week or so)


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] 0.54-0test2 released

[IOhannes m zmoelnig]

On 7/3/23 13:23, José de Abreu wrote:

about the bigger console, it triggered to me on test1 I think, but only
after I tried to change the font size of the console, then I don't know how
to go back...


ah thanks, that's the trick.

so the new resizing code kicks in if you ever change the default font of 
the Pd-console.
since this change is remembered in the GUI-settings, the console is 
resized for future restarts of Pd (until you clear all the settings).


it's probably something that ought to be fixed, but I think it's low 
priority (as in: let's not hold this back the Pd-0.54 release)


gfdasrtas
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Help with Gem on Fedora

[IOhannes m zmoelnig]

On 5/29/23 23:28, Francisco Medeiros wrote:

I need to play vídeo files with Gem on Nobara linux which is Fedora based
but when compiling Gem I can only get film-support to use QuickTime.
Does anyone know a way to install gmerin on Fedora?

i don't.
however, Gem in git has some prelaminary support for loading films with 
FFMPEG (gem_filmFFMPEG.so).


that's probably easier to install than gmerlin (it requires the usual 
ffmpeg-development libraries: libavformat libavutil libavcodec 
libswscale; i don't know how they are called on fedora)


gfmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Number atom box limits overstepped

[IOhannes m zmoelnig]

On 5/11/23 14:30, William Huston wrote:

Joao,

IIRC, some objects in pd-extended, like hsliders,
would always respect the limits whether dialed-in, or
when coming from an input.

When i finally switched to vanilla, I noticed the same thing,
limits were not respected on the inputs, and a lot of my patches broke.

I don't know whether the "sensible" behavior was ever in the
mainline branch, or only in -extended.


for me the "sensible" thing is to keep the GUI-objects as minimal as 
possible.
that would mean, that they cannot be used for "filtering" (out-of-bound 
values).
it's super-simple to just add a [clip 0 127] (or whatever) before or 
after the slider to achieve the behavior you are looking after.
otoh, it is not *so* super-simple to build a patch that prevents a user 
from dragging a numberbox out of bounds, so i understand why this 
functionality is in. (it's of course possible).


otoh, the GUI objects are already full of various cruft (starting with 
the possibility to set lower and upper ranges in sliders, and various 
characteristics... ideally they would just output 0..1 and the user can 
then map that to whatever they need).


but that is just my 2¢ (from a minimalistic POV).

masd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Raspberry pi 4 startup problem

[IOhannes m zmoelnig]

On 4/13/23 12:39, Simon Iten wrote:

Or as a workaround, is there a way to hit that apply button automagically from 
within a pd patch on loadbang?


yes, with the [mediasettings] library.

in RPi, you should be able to install it with
$ apt-get install pd-mediasettings

gfmasdr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] IEM Music Residency Programs 2023 - Call for Applications

[IOhannes m zmoelnig]

IEM Music Residency Programs 2023 - Call for Applications
University of Music and Performing Arts Graz (KUG)
https://iem.at/

(please distribute)

The IEM – Institute of Electronic Music and Acoustics – in Graz, Austria 
is happy to announce its calls for its 2023 residency program.


You can apply for two different residencies: the Artistic Residency (1) 
and the Artistic Research Residency (2).


(1) Artistic Residency

The residency is aimed at individuals wishing to pursue projects in 
performance, composition, installation, sound art, development of tools 
for art production, and related areas. Individuals are asked to submit a 
project proposal that is related to the following research fields of the 
IEM:


*  Algorithmic Composition
*  Algorithmic Experimentation
*  Audio-Visuality
*  Dynamical Systems
*  Experimental Game Design
*  Live Coding
*  Sonic Interaction Design
*  Spatialization/higher-order Ambisonics
*  Standard and non-standard Sound Synthesis

Duration of residency: 3 months
Start date: June 1st 2023 (negotiable)

APPLICATION DEADLINE: February 28th 2023

Please reply to the official call by KUG for a University Assistantship 
(in German and English):





(2) Artistic Research Residency

The residency is aimed at individuals wishing to pursue an artistic 
research project in close collaboration with an IEM staff member and 
related to the research fields of the IEM (see list above under (1)).


Duration of residency: 3 months
Start date: September 1st 2023 (negotiable)

APPLICATION DEADLINE: April 30th 2023

Please reply to the official call by KUG for a University Assistantship 
(in German and English):





The Institute:
The Institute of Electronic Music and Acoustics is a department of the 
University of Music and Performing Arts Graz founded in 1965. It is a 
leading institution in its field, with more than 35 staff members of 
researchers and artists. IEM offers education to students in composition 
and computer music, sound engineering, sound design, contemporary music 
performance, and musicology. It is well connected to the University of 
Technology, the University of Graz as well as to the University of 
Applied Sciences Joanneum through three joint study programs.


The project results will be released through the Institute's own Open 
CUBE and Signale concert series, as well as through various 
collaborations with international artists and institutions.


What we expect from applicants:
- A project proposal that adds new perspectives to the Institute's 
activities and resonates well with the interests of IEM.

- Willingness to work on-site in Graz for the most part of the Residency.
- Willingness to exchange and share ideas, knowledge and results with 
IEM staff members and students, and engage in scholarly discussions.

- The ability to work independently within the Institute.
- A dissemination strategy as part of the project proposal that ensures 
the publication of the work, or documentation thereof, in a suitable 
format. This could be achieved for example through the release of media, 
journal or conference publication, a project website, or other means 
that help to preserve the knowledge gained through the Residency and 
make it available to the public.
- A public presentation as e.g. a concert or installation, which 
presents the results of the Residency.


What we offer:
- 24/7 access to the facilities of the IEM.
- Exchange with competent and experienced staff members.
- A desk in a shared office space for the entire period and access to 
studios including the CUBE [1], according to availability.
- Extensive access to the studios of the IEM during the period from July 
1st until end of September.

- access to the IKOsahedron loudspeaker [2]
- access to the “Autoklavierspieler” [3]
- infrared motion tracking systems
- Regular possibilities for contact and exchange with peers from similar 
or other disciplines.
- Concert and presentation facilities (CUBE 30 channel loudspeaker 
concert space).


What we cannot offer to the successful applicant:
- We can not provide any housing.
- We also cannot provide continuous assistance and support, although the 
staff is generally willing to help where possible.

- We can not host artist duos or groups, because of spatial limitations.
- We can not offer any additional financial support for travel or 
material expenses.


Feel free to contact reside...@iem.at if you have any questions.

[1] The Cube has a 30-channel loudspeaker system
[2] https://iko.sonible.com/
[3] https://algo.mur.at/projects/autoklavierspieler


OpenPGP_signature
Description: OpenPGP digital 

Re: [PD] [PD-announce] PuREST JSON 2.0.0 "Medea" released

[IOhannes m zmoelnig]

On 1/31/23 13:16, Roman Haefeli wrote:

The included libraries are x86_64 only. Even if the the externals are
multiarch, they won't work on arm64.


are they installed with 'brew' (on the build-machine)?

brew will only install single-arch binaries (and only for the currently 
selected architecture).


gfmdasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] dwt~

[IOhannes m zmoelnig]

On 1/16/23 11:09, Roman Haefeli wrote:


On Mon, 2023-01-16 at 10:23 +0100, Paul Pignon wrote:

  Just reinstalled Debian 11 (got really wonky), now missing lots of
pd stuff.
  Need dwt~, not in creb anymore, though dwt~help.pd is there, oddly
enough.


Add:

[declare -lib creb]


this!



to your patch in order to load the creb library.

(Probably your patch does something like [declare -stdlib creb], but


[declare -stdlib creb] works nicely if you use the "creb" package from 
Debian ("apt-get install pd-creb")



gfasmdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce]  Ugly Patch Contest 2023  Call for submissions 

[IOhannes m zmoelnig]

Dear fellow patchers,

(please distribute in your favorite peer-group, on discord, telegram, 
IRC, fb, twitter^Dmastodon, whatever)


it's the time of the year where one reflects on their past achievements.
A perfect time for reviewing patches you have written in 2023 (or 2012; 
or whenever).


You might notice that would looked like a perfectly nice patch, is no 
longer digestible. You are not alone.

So why not share your experience?

I would therefore like to invite you to submit patches for the "Patch 
Beauty Competition 2023".


https://discipline.puredata.info/upc2023

They tell us that beauty lies in the eye of the beholder, so I'm looking 
for ugly patches instead.
If you have any patches lying around that you are not proud of, please 
submit them.
If you have any patches lying around that you *are* proud of, submit 
them nevertheless.


The patches are going to be used in an online survey - the community 
decides.


But fear not: patches are going to be anonymized, to the extend that 
it's no longer possible to guess their original function (or author).


If you are interested (or not) please head over to
  https://discipline.puredata.info/upc2023
for instructions on how to send in patches.

Cheers and a merry Christmas/Hanukkah/Hogswatch/Kwanzaa/Pancha 
Ganapati/Saturnalia/Winter solstice/Yalda/Yule or whatever you celebrate.


gdras
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Basic send historical issue 32 bits / 64 bits

[IOhannes m zmoelnig]

On 12/20/22 08:10, Lucas Cordiviola wrote:

hi,

you should *not* convert the list to a symbol:


totally.
[l2s] just adds a lot of overhead, for no benefit.


you should send a list so that later [route] can do its job:

[pack 0 0 ]
|
[list prepend send]
|
[netsend]



that should read

|
[list prepend send]
|
[list trim]
|
[netsend]

apart from that, i totally agree with lucas.

gfasdmr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [random] and seed value

[IOhannes m zmoelnig]

On 12/14/22 23:55, Julian Brooks wrote:


Yes, I'm one of those...


then i think you should start setting an explicit seed right now.

the simplest way i've found to force the currently hardcoded seed (for 
the first instantiated random generater), is something like this:


1. seed the random generator with 255406
2. discard the first 3186 random numbers

like so:
#N canvas 2082 640 533 344 12;
#X msg 307 69 seed 255406;
#X msg 327 123 3186;
#X obj 327 148 until;
#X obj 230 246 spigot;
#X msg 307 174 1;
#X obj 230 271 print;
#X msg 202 166 bang;
#X obj 307 94 t b b a b;
#X msg 367 172 0;
#X obj 230 221 random 100;
#X obj 281 197 t a;
#X obj 367 200 t f;
#X text 311 45 reset;
#X connect 0 0 7 0;
#X connect 1 0 2 0;
#X connect 2 0 10 0;
#X connect 3 0 5 0;
#X connect 4 0 11 0;
#X connect 6 0 9 0;
#X connect 7 0 4 0;
#X connect 7 1 1 0;
#X connect 7 2 10 0;
#X connect 7 3 8 0;
#X connect 8 0 11 0;
#X connect 9 0 3 0;
#X connect 10 0 9 0;
#X connect 11 0 3 1;


[random] seems to rear its head now & then.


of course it loops. it's a pseudo random generator.
however, i find that the underlying algorithm is somewhat perfect with 
regard to repetition (last time i checked, it required about 4294967295 
iterations to repeat, which is pretty good for a 32bit integer number).


that's not to say that the distribution for small ranges as output by 
[random] might *not* be ideal.



My memory is that when asked on here, Miller was a little coy about the algo 
(when was highlighted on-list as an 'interesting' [non-standard] 
implementation:)


iirc, miller always claimed that he was just blindly hitting the number 
keys to generate large numbers.


i don't fully trust this statement for the actual random generator 
(given that it consumes all possible numbers before repeating), but for 
the seed generator this is somewhat plausible, as this one only takes 
536870912 iterations to repeat itself (so the PRNG itself has an 8-times 
longer period)


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] poly help patch bug?

[IOhannes m zmoelnig]

On 11/15/22 08:13, IOhannes m zmoelnig wrote:

On 11/15/22 07:36, Chris McCormick wrote:

Hi,

The help patch for [poly] looks a bit odd to me. The output from poly 
is connected to the first text toggle, and nothing is connected to the 
[print]. I'm on Pd 0.51.3.


just a quick idea:
the updated poly-help.pd uses the new list gatom - which was introduced 
with Pd-0.52-0.
you probably are opening a new help-patch with an old Pd. try opening 
the poly-help.pd that comes with the version of Pd you are using.


gfamdsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] poly help patch bug?

[IOhannes m zmoelnig]

On 11/15/22 07:36, Chris McCormick wrote:

Hi,

The help patch for [poly] looks a bit odd to me. The output from poly is 
connected to the first text toggle, and nothing is connected to the 
[print]. I'm on Pd 0.51.3.


On Pd-0.53-0 it looks nice and porrish (see attachment).

I also downloaded pd-0.51-3.src.tar.gz from miller's site, and there are 
no toggles in poly-help.pd.



fdamsr
IOhannes


PS: chkdsk c:


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patch won't open

[IOhannes m zmoelnig]

On 11/10/22 17:35, Peter P. wrote:

* IOhannes m zmoelnig  [2022-11-10 16:21]:
[...]

this in turn was triggered by a gruesome regression in Pd-0.53's iemgui

Do you mean the now vanilla GUI objects once introduced by IEM, or the
iemgui external library?



with "Pd-0.53's iemgui" i mean the built-in iemgui objects (like [tgl]).

but to keep the confusion going, i stumbled upon the issue while 
updating the iemgui external library.


gmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Patch won't open

[IOhannes m zmoelnig]

On 11/10/22 16:04, Alexandros wrote:
I remade the patch and now it opens. I've no idea why. I did set log to 
4, but nothing concerning this patch was being printed. Also, I did 
launch Pd from a terminal and there was nothing there either. Pretty 
mysterious. Anyway, now the patch opens again. I'll come back here if I 
encounter this strange issue again.



i just had something similar.
the reason why the patch would not open was, that the patch file was empty.

this happened, because Pd crashed while saving the file (right between 
clearing the original contents and writing the new content).


this in turn was triggered by a gruesome regression in Pd-0.53's iemgui 
(courtesy of yours sincerely).




gasmdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] undefined symbol

[IOhannes m zmoelnig]

On 11/7/22 10:13, Alexandros wrote:
I'm trying to make an external with the source being split in five 
files, where all are included in the main file that creates the object. 
This is someone else's code (given freely), not aimed at Pd, and I would 
like to maintain this structure, rather than write everything in the 
main file.


I'm using pdlibbuilder's Makefile and the compilation process succeeds 
with a few warnings about unused parameters, but when I try to create 
the object in Pd, I get the following error:


undefined symbol: set_char_to_indx

set_char_to_indx is a function defined in one of the files included in 
the main file and it is used in one place in the main file. How can it 
be solved?


hard to tell without more info.
if you write "included in the main file", what exactly does this mean?
is it only the header-file you are "#include"ing?
if so, you must also compile the C file where 'set_char_to_indx' is 
implemented and then link it into the final binary (external).


the simplest way to do that is using pd-lib-builders 'common.sources' 
variable (which will statically link the given files to all externals 
built by the project).


gfmadsr
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Biased waveform display?

[IOhannes m zmoelnig]

On 10/10/22 12:21, jayrope wrote:

A quick question:

In Vanilla, is it possible to bias solely the display of a waveform in
an array in such a manner, that lower volumes visibly appear louder than
they are?



logarithmic scale on the y-axis (or x-axis, for spectral info)?
i'm afraid, the answer is "no" (so you have to perform any data mangling 
first, and then show it on a 2nd display-only array)



Very dynamic audio often would love such a display feature here, however
without touching the actual data - and copying large arrays of audio
likes to incite dsp dropouts.


it shouldn't take much longer than filling the primary array though. so 
if you are able to do this without dropouts, you should be able to do 
the data mangling as well.
that is: if you are recording live into the primary array, do a 
simultaneous recording of the mangled data into the secondary array.


if this is not an option, you might want to check the "iem_tab" library.

gamfsd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Alternative for array to show curves?

[IOhannes m zmoelnig]

hi.

no soluteion, just a quick comment:

On 10/9/22 10:16, Ingo wrote:


I have already spent countless hours in replacing number boxes and faders
with using canvases on top of the number boxes and faders.


this will actually make things worse!
from Pd's POV, you are now showing a number box *and* a canvas, so 
there's approx twice as much to "draw" (and "handle": e.g. moving the 
mouse will check both numberbox and canvas whether it it interested in 
the mouse position)


(although, as you have noticed, the canvas labels will at least show :-/)


fgamdrs
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [hidraw] pre Deken release. was:(Reading/writing a HID device current best practice?)

[IOhannes m zmoelnig]

On 10/6/22 17:14, Lucas Cordiviola wrote:

That would be fantastic. Please let me know when its done.


and then there is 
 
which is what I use on our CI-infrastructure to codesign Pd-externals.


it's not a ready-to-use script, as it is wrapped in a YAML-file, but 
hopefully you get the idea.


fgmdasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD 0.52 bug ? ... [bang~ driven playback]

[IOhannes m zmoelnig]

On 10/6/22 12:32, Dan Wilcox wrote:

Howdy Oliver,

Actually, use the pure-data develop branch. I don't believe Miller has merged 
this fix into master yet.


this one has been merged into master a few weeks ago.



If you are unsure about building Pd yourself, I could possibly make a test 
build tonight.


you can (always) get builds for the current master from


the topmost pipeline should have a "download" icon on the far right 
side, where you can pick your platform.


gfasmrf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] C externals in M1 give errors

[IOhannes m zmoelnig]

On 8/15/22 08:29, Jaime Oliver wrote:


The specific error I'm getting right now is that it is reading that number
32 as 29. Again, this same code works fine in all other OSs I've tried.

I'm assuming the issue is in the pow() function and all the typecasting
(int), (double) as Chris suggested?


[...]



int readbarfile(int a[][8], FILE *f){
 int i, ii, j, jj, strsize, temp;
 char * line = NULL;
 size_t len = 0;
 ssize_t read;
 char ss[10];
 temp=j=0;

 ii=0;
 while ((read = getline(, , f)) != -1) {



[...]

my suggestion for a completely different approach:
rather than brewing your own file-reader: how about using [text] (or 
whatever existing object you prefer) to parse the file contents into an 
atom list and then use only messages to set the internal state of your 
object?


in general this makes your object much more flexible, e.g. you can write 
patches that do not need your "barfile" *at all, but instead store the 
entire configuration in the patch.


gfasmdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] using 'audio-setapi' without dialog popping-up

[IOhannes m zmoelnig]

On 7/7/22 11:40, Roman Haefeli wrote:

Hi all

Is there a way to change audio backends programmatically (with 'audio-
setapi' message or any other) _without_ the audio settings dialog
popping up? Or is there a way to hide it again after it pops up?



use the [mediasettings] library.

it is *exactly* for this usecase (as in: it will internally use 
'audio-setapi' and what not, but completely hide this from the user).


gfmadrs
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Call-for-Help: tips of the day

[IOhannes m zmoelnig]

TL;DR if you know any quick tips for using Pd, submit them at
  https://github.com/pd-externals/tipoftheday-plugin/issues/new/choose



long version:

as you all know, Pd comes with a built-in documentation, that 
illustrates how to use various objects and stuff (and alex has done a 
fantastic job in revising these patches in the last months).


for a deeper understanding of Pd, there's the HTML manual (which looks 
nice, after lucarda added some CSS).



however, i think that there are a couple of things that need 
documentation which cannot really be covered by either help patches nor 
manuals.
e.g. "intelligent patching" (where i've spent a bit of time to get it 
working) or other workflow tricks do not fit well in either category:
if they are explained in some help-patches then only people who actively 
walk through those patches will ever see them (and i believe most people 
just open the help-patch of a given object they are interested; but what 
would you open for a non-object that you don't even know about).
similarly, i have a feeling that the manual is not the best place for 
this either (first, the manual deals with the "larger picture" rather 
than interface tricks; second, the manual is more of an off-line 
resource (that you may read when not sitting in front of a running 
instance of Pd).


just recently i mentioned the "triggerize" functionality to someone, and 
they never ever heard of it!



to fix this, i've created a small GUI-plugin to display a "tip of the 
day" whenever Pd is started.


i think this (Pd's startup phase) is the right time to learn something 
new (in tiny bits) - after all, other applications (like my trusted MS 
VisualStudio 6) did the same).


the tips are super-simple: just a short text, with an optional URL for 
more information and support for displaying (animated) GIFs (patching is 
oft explained better by showing).



the GUI-plugin is available on
  https://github.com/pd-externals/tipoftheday-plugin/

but there's no release (and thus no deken package) yet.

There's also an experimental webinterface where you can browse the 
existing tips at 



so far so good.
The only drawback right now is, that there are only a very few tips 
available yet (a total of *4*, mainly for testing).


so before this is going to be released to the public, I'd like to 
collect a few (hundred) more tips


this is where you come into play:
if you know any quick tips, patching tricks or hacks, please submit them 
in the issue-tracker at 

(the "Tip of the Day" issue-type will give you a form that you should 
fill in; this should keep the entry barrier to creating new tips low).



thanks for helping out.

gmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [command] can't execute "ls | wc -l"

[IOhannes m zmoelnig]

On 6/8/22 09:43, Alexandros wrote:
While [ggee/shell] outputs the correct number of files in a directory 
with the message "ls | wc -l", [command] outputs an error code 2 with 
"exec ls | wc -l" and doesn't output anything.


Is this intentional? If so, how can this command be executed by [command]?


probably by chaining up multiple [command]s?


but more importantly: "ls | wc -l" is an anti-pattern: you shouldn't 
parse the output of `ls` [1]
e.g. your script breaks as soon as your directory contains files with a 
newline in their name.


a safer way would be to run
> find * -maxdepth 0 -type f  -exec printf . ";" | wc -c

but this is absymally slow (and still has the problem with the pipe).

a faster way would be to run this simple shell-script:
```sh
i=0
for f in *; do
  i=$((i+1))
done
echo $i
```

you can run this by creating a single symbol (without the quotes)
"i=0; for f in *; do i=$((i+1)); done; echo $i"

and then send a message "exec bash -c $1" (with $1 replaced by the 
symbol) to [command].
this will launch a full-fledged bash that will then interpret your 
little script.



an even better way would be to just use [file glob]


fmgasdr
IOhannes


[1] http://mywiki.wooledge.org/ParsingLs


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] accountant's amends: deken v0.9.2 released

[IOhannes m zmoelnig]

hi

i'd like to announce the release of deken-v0.9.2

  https://github.com/pure-data/deken/releases/v0.9.2

the GUI-plugin can be installed via deken.
just go to "Help -> Find externals" and enter
"deken-plugin" as the search string.

this is the first bugfix release of deken-v0.9, which solves an 
important regression (aka: crash) on some older versions of Pd on macOS.
i hope this is now ready for inclusion in the next Pd release as the 
standard "find externals" implementation.


in any case: please test!


changes since 0.9:

deken-plugin ("Find externals" within Pd)
=

- fix crash on some macOS versions of Pd (basically reverting to the old 
list view in selected cases)
- double-click on the "library" heading now will open/close all library 
nodes
- double-click on any other heading (e.g. "version") will also re-sort 
the libraries
  - (single-click will only re-sort packages within each library node, 
but leave the library-sorting itself intact)


deken-xtra-apt-plugin
=

- fix the deken-extension to also include packages installed via 
`apt-get` (on Debian and derivatives)



deken cmdline (create and upload packages)
==

- fix overriding of destination URL with `--destination`
- minor fixes in the GPG/SHA256 verification code
- make flags for enabling/disabling certain features consistent
- make wrapper script POSIX compliant
- fixes to help Debian packaging of the the cmdline tool
- update Docker image
  - reduce size
  - prepare Docker image for GPG signing

binaries and a Docker image for the cmdline tool are available from the 
releases page.




happy patching

gfmdasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-announce mailing list
pd-annou...@lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] two sliders on top of each other (XY-Controller)?

[IOhannes m zmoelnig]

On 5/12/22 13:54, Peter P. wrote:

Hi list,

jus tried if two sliders placed on top of each other could work as a
simple XY-contoller. They do not, but more interestingly it is the lower
of the two slider that receives the mouse clicks while the upper is
visible. Is this intentional?


yes.
for example see the [pd example discrete] in the hslider help-patch.



Could GUI objects be transparent in color as well as for clicks in any
way?


i'm not sure i understand the question.
as for transparent colors, it seems there's no definitive answer.
canvas-widgets (for lack of a better word) can be made transparent if 
they have no (fill) color at all (like ordinary [object] boxes), but 
iemguis always have a fill color (and the color picker has no "no color" 
either).
also iirc, *some* iemguis might actually use the object color to hide 
things (most notably the vu-meter, although you are probably not talking 
about that).
afaik, there definitely isn't any "alpha" channel available in Tcl/Tk 
(so no semi-transparency)




I know about the canvas-objects reporting their positions (and it would
be cool if they would report mouse-downs and -ups as well), but don't
like the fact that I have to be in edit mode to move them.


nobody does.

in any case: i don't really think that the [cnv] is the proper object 
for this though (it's main purpose is creating solid colored rectangles; 
and having them respond to mouse interaction, will make them quite 
CPU-hungry).


the iemgui *library* (available via deken, but i don't know whether it 
still works with recent Pd) has an [iem_event] object that i think does 
what you want.


something like this might be a good addition to Pd-vanilla.




It seems there is no other vanilla way for xy-controllers then...


data structures, obviously.

gfmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [key], [keyup] and operating system key reapat

[IOhannes m zmoelnig]

On 5/4/22 09:49, Peter P. wrote:
>> i guess this would be great for many users of Tcl/Tk.
>> you might want to file a (wishlist) bug there.
> If this doesn't provoke nightmares I'd be happy to do, perhaps for
> documentation purposes only.

it won't provoke nightmares for me (as i wouldn't even know what you are 
doing in the Tcl/Tk bugtracker). YMMV.


On 5/4/22 09:49, Peter P. wrote:


PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *not*
willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me from
a few nightmares

Thanks, just to be clear as I am not involved in this coding: The
problem lies within Tcl/Tk right (and is known within that community of
coders)?


i have no idea.

the Tcl/Tk community might be aware of the fact, but not see it as a 
problem.


like so many things this is probably just a result of different 
decisions that were made on the OS level. (and I assume that Tcl/Tk is 
just passing through the system characteristics).


e.g. on macOS there is this UX guideline, that whenever you change 
something in a properties window, the change is applied immediately.
otoh, Linux and Windows systems typically use a distinct "Apply" button, 
that you have to actively press in order to apply your changes.
now we *could* create a dialog that behaves the same on all platforms, 
which is great as there is now a consistent behaviour of Pd across OSs.
but if we pick the macOS UX guideline, users of Linux or Windows will 
probably be unhappy. or vice-versa.


similar with key repeat: the designers of your desktop environment 
probably (hopefully!) spent some thought on why key repeat behaves as it 
does, but (unfortunately) they came to different solutions as what 
should be the "correct" behaviour.
but if Tcl/Tk chose to abstract that behaviour away to a (new) 
behaviour, that is consistent across all platforms, wouldn't this make 
Tcl/Tk applications behave "weird" in the experience of users who work 
on a system that usually has a behaviour that *differs* from the one 
chosen by Tcl/Tk.


the simplistic answer is of course: if you want your dialogs to behave 
like on Windows, you shouldn't use macOS. if you want your keys to 
repeat like on Linux, you shouldn't use Windows.


in practice this is of course a straw man, as people don't typically 
pick their OSs because they like a given keyrepeat or dialog behaviour.
but it hopefully explains why it's often not so simple to "fix" 
differences between OSs.


having said all that: the Tcl/Tk community might be able to give more 
informed feedback on such a feature request.


gfmadsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [key], [keyup] and operating system key reapat

[IOhannes m zmoelnig]

On 5/4/22 08:04, Peter P. wrote:

It would be great to have more unified behavior since so much work has
already gone into this issue.


i guess this would be great for many users of Tcl/Tk.
you might want to file a (wishlist) bug there.

gdmasdr
IOhannes


PS: i'm happy to fix bugs in the Pd sources; but unlike Dan, I am *ont* 
willing to patch the Tcl/Tk engine for Pd's sake. i guess this saves me 
from a few nightmares


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] 1st Release Candidate of ELSE 1.0-0 (with Live Electronics Tutorial)

[IOhannes m zmoelnig]

On 4/20/22 09:19, Alexandre Torres Porres wrote:

Hey, first update of ELSE and the tutorial in 2022 has been released.



congratulations!


The Live Electronics Tutorial has also been updated, check detailed
changelog at: https://github.com/porres/pd-else/releases/tag/v1.0-rc1


one thing i never understood (and forgive me if i asked before and 
forgot): why is the "with live electronics tutorial" string part of the 
version? (i can think of a number of technical reasons, but conceptually 
i think it shouldn't be part of the version but rather of the description)



you *can* change the 'title' of uploaded files on the portal, and deken 
will display this instead of the filename.



see the deadkeys-hotfix-plugin (search for "*hotfix*") or the 
"mediasettings" library.
(as can be seen in these examples, there are obviously some problems 
with reserved HTML-characters - e.g. "<" is currently rendered as "" 
- so best to avoid them).

this allows you to show some information to the user beyond the filename,
descriptions are not searchable (but versions are neither), and will not 
be taken into account for filtering or sorting.


here's how to do it:
- login to puredata.info
- open the URL containing your uploads
- click on the package file
- at the to pof the page you should see an "Edit" tab (below the 
breadcrumb) - click it

- change the "Title" to something of your liking, e.g.
  "ELSE - with Live Electronics Tutorial (macOS/Linux/Windows 64bit)"
- hit "Save" (near the bottom of the page)

mgfdasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] how to compile fat externals for apple with d_i386/d_amd64/d_arm64?)

[IOhannes m zmoelnig]

On 4/19/22 13:11, IOhannes m zmoelnig wrote:
1. i *think*, on macOS Pd should first try to load the arch-specific 
extensions (`.d_i386`), and only then it should fall back to loading the 
fat binary (`.d_fat`).

obviously it doesn't do that [1] right now.
in the meantime, you could try to force the extension for the fat binary 
to ".pd_darwin" (which is searched for after the arch-specific extensions).


i'm not sure whether pd-lib-builder handles this correctly, but 
something like this might do the trick:


```
make extension="pd_darwin" arch="x86_64 arm64"
```

gmndas
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] how to compile fat externals for apple with d_i386/d_amd64/d_arm64?)

[IOhannes m zmoelnig]

On 4/17/22 19:14, Alexandre Torres Porres wrote:

So, yeah, doesn't seem possible, but I'm still not sure yet, and other
than, it seems I can't mix in the download a fat binary (with 64/arm) along
with some other binary for 32 bits (darwin or 'd_i386'). If I'm using Pd 32
bits it won't be able to load the correct one as it tries to load the fat
one and fails!


hmm.

i guess there's two separate bugs here

1. i *think*, on macOS Pd should first try to load the arch-specific 
extensions (`.d_i386`), and only then it should fall back to loading the 
fat binary (`.d_fat`).

obviously it doesn't do that [1] right now.

2. if it fails to open a given binary (e.g. because of the wrong 
architecture), it should continue to try the other file extensions.
could you provide the full (related) output of the Pd-console, when it 
tries (and fails) to load the i386 binary?



mfasr
IOhannes


[1] 



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Deken filename too long for certain filesystems (ecryptfs on ext4)

[IOhannes m zmoelnig]

On 4/9/22 23:48, Roman Haefeli wrote:

I think having a lower limit than the common 255 characters is silly. I
don't think that Deken packages should assume a smaller filename limit
than 255. However, we see that the above example is not that far from
that (support for a few additional archs or double-precision could
reach it). Also, I wanted to share my experience. Maybe it has an
impact on the recent external double-precision file extension
discussion.


please create a bugreport on https://github.com/pure-data/deken/issues

there is no real reason that the name of the downloaded file must have 
the full long name.


in the meantime, you can
1. right-click the package you want to install and select "Copy package URL"
2. paste the URL in your favourite browser
3. let the browser download the file, but rename it to something shorter
4. use the "Install DEK file..." menu (hidden under the [More...] 
button) to install the manually downloaded file
(alternatively, you could also just drag the .dek file  onto the deken 
window)


when renaming the .dek file, make sure to keep the library-name (esp. if 
you use the "Try to remove the library before reinstalling it" 
functionality); and of course keep the .dek extension.


gfasmf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Most recent Pd packaged for Ubuntu (and derivatives)

[IOhannes m zmoelnig]

On 4/6/22 13:03, Kaj Ailomaa wrote:

Any universal packaging changes should be done in Debian directly, though.


i've now added some metadata to the Debian packages (but none are 
uploaded yet).


if somebody (e.g. roman), wants to test them, they can grab my changes 
from https://salsa.debian.org/multimedia-team/pd/puredata/


and see whether this fixes anything.

(please don't upload any packages build from the repository yet; but 
feedback is of course welcome)


gfmdas
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.52-2 released

[IOhannes m zmoelnig]

On 3/30/22 17:30, Dan Wilcox wrote:

How many externals are there, really?


there's a total of 146 externals that have macOS binaries (of any form).
of these, there are 10 externals that provide M1 binaries.



I'd argue that more time has been spent writing emails on this issue than it 
would take for each person to take one external, make a fat build, and upload 
to deken.


+1


today i've uploaded two more (for which i feel some slight responsibility)


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.52-2 released

[IOhannes m zmoelnig]

On 3/29/22 16:10, Christof Ressi wrote:
If you have an apple silicon, it'll run under the hood the arm code 
and then it will only find and load 'arm64' externals?
 From my understanding, yes. For that reason, I guess it's not a good 
idea to provide universal binaries at this point and we should rather 
ship seperate binaries. 



i'm utterly confused.

it was my feeling that the situation for Pd-0.52-1 where we did just 
that was not ideal.
i remember people complaining that there was no M1 binary in the first 
place.


now people seem to all agree that it was much better way back then.

before anyone starts providing an x86_64-only binary, consider 
rebuilding the externals for arm64 and upload them.
this will be a net-win for the future, rather than trying to keep the 
past alive.


i did some quick stats of the macOS downloads in the last 10 days.
here's the top 10 (which make for 66% of all the macOS downloads):

cyclone
zexy
else
comport
Gem
iemlib
ggee
freeverb~
mrpeach
pddp


at least zexy and comport already provide m1 binaries.
the only library where i would expect any problems for compiling for 
Darwin-arm64 is Gem (actually building is fine; the problem is more 
about including all the relevant helper libraries in the deken package - 
homebrew just sucks when it comes to multi-architecture).


ghdfs
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Compiling cyclone for Darwin-arm6

[IOhannes m zmoelnig]

On 3/24/22 15:44, Philip Stone via Pd-list wrote:

Hi Christof,

Thank you for the pointers. Running ‘make’ on its own does indeed build 
cyclone, and since I’m doing it on an M1 macbook, it generates arm64 
executables, and ‘install’ puts them in ~/lib/cyclone. (? - Is that right?), 
and they actually work!

However, I was hoping to generate fat, single-library binaries for Deken, and I 
thought CMake might make that easier. I will look into the necessary flags for 
doing it with ‘make’.


```
make arch="arm64 x86_64 i386 ppc"
```

leave out the architectures you do not want or know (and those that the 
compiler is not able to produce, which most likely includes all but the 
first two)



mdfgasd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] more features for [file] (Get directory of current patch)

[IOhannes m zmoelnig]

On 3/23/22 20:44, Alexandre Torres Porres wrote:


So, one thing I'd like, just get the filename and extension from [file
split] as an option, so I wouldn't need [list split]. 


i think the best would be if [list split] would accept negative indices 
(counting from the end), to simply extraxt the last element of a list.



Also, something weird
happened and files with space in its name came out as 'lists', not symbols.


i'm not sure i can follow.
[file split] always outputs a list, regardless of spaces.
ifa filename contains spaces, i here get something like:
[list foo\ bar.pd(
(that's a "list"-message with a single symbol-atom "foo bar.pd")

however, i noticed that my unit-tests (that are automatically run on 
linux, windows and macOS) do not cover splitting files with spaces.

so i might have missed some cross-platform thing.



Another thing is just an easier way to 'seek' for files with a specific
extension and also get the number of found files.


that seems very high-level to me.

(aka: build your abstraction around [file] to get this and a graphical 
pull-down menu for chosing files and playing the soundfile)




And yes, getting the patch's directory by default would make things easier
and bypass the need of [pdcontrol].


there's an open PR that adds [file patchpath] (and more).


gfdmasrf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd 0.52-1 - frozen dsp and gui in ubuntu 20.04

[IOhannes m zmoelnig]

On 3/22/22 15:06, Roman Haefeli wrote:

On Tue, 2022-03-22 at 14:56 +0100, Christof Ressi wrote:

Anyway, I can open an issue to describe that in my case DSP only
works with callbacks on.

  Yes, please! The Jack backend is supposed to work regardless of the
"callback" setting.


But not regardless of the "delay (ms)" setting. If it is too low, Pd
won't process audio. I don't know if there is a way to know beforehand
what 'too low' is. It isn't necessarily a bug in Pd, I'd say.



it's probably a bug in Pd if the DSP and the GUI both freeze.
(e.g. a solution as suggested by christof is to ensure the value is sane 
- at least if we have some possibility to determine that beforehand)


gfmadr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] M1 Externals

[IOhannes m zmoelnig]

On 3/21/22 14:03, me.grimm wrote:

but unless you are planning to maintain the object for the next decade


I agree, I don't want to do this :)

so this is my lobby.


the best lobby is of course an open issue (or a PR) :-)



so this IS the official repo? https://git.iem.at/pd/comport


i would say so.



can I send you pull requests? only really familiar with github. maybe move
the official repo there?


i'd rather not.

sending PRs to git.iem.at is a bit tricky atm (i guess the best right 
now is to do a fork to some public git hoster of your liking (e.g. 
gitlab, github, bitbucket or whatever) and then attach a link to that 
repo to the ticket.

i understand that this is not the best UX.


anyhow: this time, your lobbying defeated space and time and 
comport_v1.2 is already available on deken.


fnase
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] plugin.tcl not changing anything, linux

[IOhannes m zmoelnig]

On 3/4/22 04:31, Samuel Burt wrote:

IOhannes and James. Thanks for the replies.

I found the relevant line in pdtk_canvas.tcl. I know modifying that isn't
permanent, because the next update might break it, but it did let me
replace -background white with -background gray95, which is cool. Now, I'll
just have to figure out if it's possible to reuse this command in a tcl
plugin file.



like this "mybackground-plugin.tcl"?

```
bind PatchWindow  "+%W.c configure -background yellow"
```

this adds a hook, so that whenever a PatchWindow is updated (that is: 
created, or moved around,...), it will re-configure the background 
property to your liking.


gfmdsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] plugin.tcl not changing anything, Linux

[IOhannes m zmoelnig]

On 3/3/22 15:59, Samuel Burt wrote:

Hi, list.

In Pop_OS (Debian derivative), I created a file called
*canvasgrey-plugin.tcl* and populated it with:

set ::canvas_fill "gray75"
set ::text_color "#222"

I've openned Pd, created new windows, saved the preferences, but seen no
change in the canvas or text color. Any suggestions?

This page  seems recent


this page refers to pd-extended (long dead), and doesn't apply to pd 
(vanilla).


theres currently no way to set the colors in Pd, but there's a [196] 
that tries to add this possibility.


gasmr
IOhannes


[196] https://github.com/pure-data/pure-data/pull/196


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] will 64bit Pd solve large table indexing issue?

[IOhannes m zmoelnig]

On 3/1/22 11:43, Peter P. wrote:

Hi,

will a 64bit Pd 


what's a "64bit Pd"?

fgmadrs
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] should 'flags' always come first?

[IOhannes m zmoelnig]

On 2/28/22 17:47, Alexandre Torres Porres wrote:

I know, that's because they should come first! This is why I think it's
confusing that sigmund~ doesn't complain and it just works...


i doubt that it is confusing.
but: if you do find it confusing, just put the flags at the beginning.

it's not like Pd is *forcing* you to put the sigmund~ flags at the end, 
and the flags for all other objects at the beginning. (*that* would be 
an inconsistency, and deserve some attention).


it's not even documented, that you can put the flags at the end.
and i agree with christof, that there's no benefit in documenting that 
you can put them at the end.


so just forget it, and the source for the confusion will be gone.




[netreceive -u 5000] will listen to port 5000 and will use udp protocol,

but
[netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is
ignored in this case...


yup, wrong order, so it gets ignored, but a warning should be given
that the order is wrong, so it's ignored!



i agree that a warning should be given if there are any ignored (and 
probably also: unknown) arguments (for objects with a complex invocation).



in general i think:
it is confusing if things don't work.
it isn't confusing if things do work.


fmgdasr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [midifile]

[IOhannes m zmoelnig]

On 2/10/22 10:30, Roman Haefeli wrote:

2) I believe it's more valuable if people do not fanning connections
because they understand their implications rather than because a
message tells them to avoid them.


but maybe they can be made aware of the implications if they were made 
explicit.




3) I'm personally not so fond of the idea of giving people patching
advice.


i understand that.

on a related note:
since Pd-0.52 it is no longer possible to connect a single outlet to 
single inlet twice.
after reading this thread , i wonder whether this was premature and 
whether we should undo that change.


gfmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] fan-out (was Re: Pd-list Digest, Vol 203, Issue 12)

[IOhannes m zmoelnig]

hi.

it would be super-cool if you could change the subject to something 
meaningful before replying to a digest mail.


On 2/10/22 14:39, Samuel Burt wrote:

Having used Pd for two decades, this still catches me occasionally. I was


that's the reason why i think that statements like "Fanning out to cold 
control inlets is perfectly fine" and "I also admit to using fanning 
when I know order isn't as important for that case" are problematic.
not because they are wrong (they are objectively correct), but because 
they encourage bad habits which are hard to come by.




only able to debug the problem because I knew this could be an issue. Guess
the UI doesn't allow for some kind of subtle indication that you've fanned
connections from an outlet. Would be nice though if a little "x2", "x3",
and "x4" would pop up next to your mouse cursor when you are making a
connection and mouse over the next inlet. 


dunno.
if you are currently creating a fan-out you are hopefully aware that you 
are doing just that (i think it's *really* hard to not notice that an 
outlet already has a connection going out).
so the problem is not to make people aware that they are fanning out, 
but to make people aware that this might introduce message ordering 
problems.


in the meantime, use triggerize (Ctrl+a Ctrl+t) to resolve all your 
fan-outs.


gfmkdf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [midifile]

[IOhannes m zmoelnig]

On 2/10/22 12:53, Dan Wilcox wrote:

I feel like often these problems also come from people trying Pd out after being more 
familiar with Max. Perhaps it would be good if Pd included a mini "Pd for Max 
users" guide which starts with execution order differences,


hmm.
i'd prefer a "tip-of-the-day".
order of execution is important enough that everybody should be aware of 
it, whether they come from max, , csound or out of the blue.


i figure your argument is, that most of these have to learn Pd from 
scratch anyhow and will eventually come to the "use [trigger]" section 
in the documentation, whereas the max users would just dive into it (as 
Pd has been sold to them as something you can use your Max-skills with 
without having to pay the license).


my argument is that people who find tips-of-the-day useful are not power 
users yet and as such an occasional reminder won't hurt.


gfdmas
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [command] output

[IOhannes m zmoelnig]

On 2/2/22 09:04, martin brinkmann wrote:

On 01/02/2022 22:25, Roman Haefeli wrote:


As I tried to explain previously, this is expected behavior in Pd land.


yes, but the float is coming out of the leftmost output, and this only 
happens when the commands output is a number (and only a number).


"exec echo 123456789" for example,
while "exec echo number123456789" works



well, this is just how FUDI works.
- everything that looks like a number, is interpreted as a number.
- numbers are internally represented as single-precision floating point
and Pd will not show you the *exact* number, but "print" it using %g to 
make it more visually pleasant.


(I'm not going into details; this has been discussed in the past. more 
than once; check the archives if you are interested).


so:
- if your script outputs "123456789", this looks very much like a number 
and is thus converted to one.
- since the number is a single precision floating point number, it will 
not be *exactly* "123456789" (since this number cannot be represented by 
a 32bit floating point number). instead it will be stored as 123456792.0f
- if you display your number with [print] or a numberbox, it will show 
as "1.23457e+08". the same string-conversion happens if you use $arg 
expansion (e.g. "[open mysound.$1.wav(").


you can use your own conversion if you send the number to [makefilename].
e.g. [makefilename mysound.%d.wav] will give you the integer part of the 
full number (but it's still a 32bit floating point number, so you won't 
get  "123456789")





adding a string, and afterwards splitting it off is a workaround.


this is of course very ugly.
Pd is not exactly good at string manipulation.

better use zexy's [date] and [time], create a list of the values you are 
interested in and then do a piecewise assembly:


[12 34 56 79 90]
|
[open mysound.$1$2$3$4$5.wav(


flag implemented. However, only the released version v0.1 is available
through Deken.


i use

command[v0.1](Linux-amd64-32).dek
 Uploaded by rdz @ 2021-10-01 22:20:51

installed via deken a few days ago



i just like to confirm that the version available via deken will indeed 
output single number printout on the 1st outlet.


https://github.com/pd-externals/command/issues/9

dgnfsa+
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] What does this element do on the Pd-Window?

[IOhannes m zmoelnig]

On 2/1/22 16:50, Christof Ressi wrote:
It switches to "Audio On" if DSP is ticked. Not particularly useful to 
be honest. 


and if you turn it off?
this label is *not* a status indicator for the DSP engine.

There is also the "I/O Error" message that appears on some 
backends when dropouts occur. Is this message displayed on the same 
label? I'm too lazy to check...


no that's a different label. (the "I/O Error" label is just not visible 
by default)


gfmadrs
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] What does this element do on the Pd-Window?

[IOhannes m zmoelnig]

i just stumbled upon this "Audio Off" label in the Pd-console (mostly 
because i have been annoyed for the past few years that has a fixed font 
size), and i have seriously no idea what it is supposed to tell me.


i have even consulted the Pd manual, but it doesn't even mention it.

could anybody shed a light why we need this?
could we get rid of it and be none the wiser?

if not, could we change it's wording (e.g. replace "On" with "connected" 
or "available" or somesuch?).
and change it from a fixed font-size to the default size (so you can 
change it)


gfmnsadf
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] ggee shell does not work in 0.52

[IOhannes m zmoelnig]

On 1/27/22 10:10, martin brinkmann wrote:

thanks, i'll do that. i used [shell] basically for getting a random-seed
(and filenames) via date, and it affects only a few patches,
and should be easy to change to [command].


if you need to read the date, you probably should use zexy's [date] 
(resp [time]).
it works on all platforms, and is *much* faster than a call to an 
external program.



if you want to generate a seed for your random number, you can use the 
new built in [file] to read some bytes from /dev/random (from your usage 
use [shell] together with date, i figure you already use a unix-like 
system).

the randomness should be much better than just using some date-based thingy.


mfgadr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] ggee shell does not work in 0.52

[IOhannes m zmoelnig]

On 1/26/22 10:21, martin brinkmann wrote:

or at least getting something from stdout does not work
anymore. (everything is fine in older versions
(0.51 and below).

example: the shell help-patch "getting the date".

it receives a bang from the right outlet, but nothing from
the left outlet. ggee is version 0.28, but it happend
with an older version (and current pd) as well.
i wonder if this affects other externals too...




i cannot reproduce this with:
- Pd-0.52.1-1 (as found in Debian/sid on amd64)
- pd-ggee 0.26-7¹ (as found in Debian/sid on amd64)

ggee-0.28 switched from `system()` to `execve()` to actually run the 
commands with [shell], which might well be the culprit here...



fdmsatg
IOhannes

¹ that reminds me that i obviously missed ggee-0.28, so there are no 
newer Debian packages available...


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.52-0 test 4 released

[IOhannes m zmoelnig]

On 1/26/22 00:03, Alexandre Torres Porres wrote:

but once we have it available, we can star providing those :)


that's a false conclusion.

- for providing a Darwin_arm64 external you need a compiler that can 
produce such binaries

- you do *not* need a Darwin_arm64 Pd for compilation¹

therefore: *all* you need to provide Darwin_arm64 externals is the right 
compiler.

not having a Pd for this architecture is therefore not an excuse.


- for *using* such an external the requirements are different:
  - you need a Pd/Darwin_arm64
  - you need the hardware (afaiu, rosetta emulates x86_64 on the arm64, 
but not the other way round)


if - as a developer - you want to test your externals before you share 
them², you need all three (hardware, compiler, Pd).
however, you already do have a compiler, so what keeps you from 
compiling Pd yourself?


mgfdasr
IOhannes

¹ on macOS and Linux
² which you should do of course.


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.52-0 test 4 released

[IOhannes m zmoelnig]

On 1/24/22 17:18, Dan Wilcox wrote:

There was an issue with building Tk Wish 8.6.12 as a universal build which 
stopped this for now.


no.
this is not really true, and more importantly i think it spreads confusion.

the truth (according to john) is:
- for newer macOS versions, miller uses binaries produced by the iem-ci
- the iem-ci currently does not build arm64 binaries
  - simply because the XCode version installed there is too old
- this means that Pd-core (on the downloads) is only x86_64
- the iem-ci does not build Tcl/Tk *at all*
  - instead it uses a pre-built binary (similar to the one found in 
mac/stuff.tgz)
  - this pre-built blob is Tcl/Tk-8.6.12 and it is a universal build 
for arm64 and x86_64



this raises the following questions:
Q1: why is the iem-ci not updated to a newer XCode that allows to build 
arm64 binaries for macOS?

A1: because I haven't found the time yet to do so

Q2: why isn't Tcl/Tk build along with Pd
A2: because I don't want our CI to spend time compiling a helper library 
that we is not actively developed by *us*



because of the situation with the externals, i do not consider the 
current situation extremely bad.



gfdmst
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] permute lists?

[IOhannes m zmoelnig]

On 1/14/22 08:09, Peter P. wrote:

Thanks José! This works really nicely and I am still trying to
understand how this is done!


similar to how you would create a randomly permutated list:
- pick a random element from the input list and append it to the output list
- repeat until the input list is exhausted

since the input list shrinks over time, the [random] generator's maximum 
value is decremented for each iteration.


gmadsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Store data in memory more efficiently than in arrays

[IOhannes m zmoelnig]

On 1/13/22 15:41, José de Abreu wrote:

Roman, maybe you could use iem16?


[...]

[table16] uses only 16bit (2bytes) to store the values, which is half of
the memory."

So maybe it is exactly what you need?



i don't really think so.
afaict, roman is mainly concerned about a *potential waste* of memory.
in his words:
> Not that I ever hit a memory limit, I'm just curious.


so to answer roman's question first (possibly repeating what christof said):

of course it would be possible to store data in a more packed format, 
saving quite a lot of memory (a factor of 8 on an 64bit system!).

however, it would complicate the internal data handling a lot.
right now, there's a unified data model, where each message (or array) 
consists of *atoms* of a single size: this allows us to write code 
*once* for multiple cases (and whenever there's a bug, it only needs to 
be fixed once) rather than special-casing different data-layouts with 
similar but subtly different code (and whenever there's a bug, it needs 
to be fixed in each place separately, with the possibility to forget one 
of those places every time we do it...).

it also allows us to have "data structures".

so we are trading code complexity for memory consumption.

this is a trade i would do any time (favouring more memory over more 
complex code).


obviously this comes with problems: since we need more memory, we might 
hit the physical RAM size, in which case we get into trouble.


but since - as you say - you've never actually hit the memory limit (and 
according to the number of times this is being discussed on the list, it 
seems that hardly anybody ever does), i'd classify this as "premature 
optimization".


sidenote: of course we are not alone.
take for example the most popular programming language¹ of the last few 
years:

a boolean value ideally requires a single bit to be stored accurately.
now in python (tested on Python3.9 on a 64bit linux system), it doesn't 
take 1 bit, or even 1 byte, but instead it takes 8 bytes.


>>> sys.getsizeof([True]*3)-sys.getsizeof([True]*2)
8

at least, if you store the boolean in an array (a single boolean value 
(outside of an array) has some extra metadata, that take 28 bytes in total)²


>>> sys.getsizeof(True)
28




now about "iem16":

that library was indeed written to store data more efficiently.
i wrote it in 2003 or so (according to the VCS history and some comments 
in the code) to implement the live electronics for a piece that required 
a long (IIRC: 20 minutes) multichannel (IIRC: 4 channels) delayline.


back then, Pd was practically everywhere 32bit (the first amd64 
processor was released in 2003; the first windows to run on a 64bit 
address space was released in 2005), so a single number stored in an 
array would require (only) 4 byte.
if my math serves me right, the required delay line would need a 
laughable 200MiB or RAM.
otoh, a "PowerBook G4 (late 2002)" would be equipped with 256MB by 
default³. specs for PC laptops would probably be about the same.
so it was practically impossible to run a 200MB delayline on such 
systems (at least if you also wanted to run Pd and an OS), and we had to 
trim down the memory consumption so the patch could be used on the 
musicians' laptops.


i don't remember having had a need for this library since then.

mtgasr
IOhannes


¹ according to PYPL: https://pypl.github.io/PYPL.html
² this argument is somewhat flawed, as python also gives us as 'bytes' 
class to store data in byte-arrays, where each byte consumes exactly 1 byte.

³ https://en.wikipedia.org/wiki/PowerBook_G4


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pager : list patches using [file] and open them

[IOhannes m zmoelnig]

On 12/22/21 01:11, Jérôme Abel wrote:

Hi list,

Thank for this new Pd release !

I'm trying to implement the [+pager] patch from Hans Christoph Steiner 
with these new features : [file glob], [file splitname] and [list store].


It is a patch which list all pd files in  the current directory, close 
and open them.


first of all: nice.

issues spotted so far:

i personally find this a bit too eagerly opening files (esp, i don't 
like it that it opens the first available file at loadbang time)


i find the fan-out after [pdcontrol] a bit fishy (even if it doesn't do 
any real harm right now) - it's very hard to reason about the order of 
execution if both [send] and fan-outs are involved.


counters are not reset (you are obviously assuming that the globbing is 
only triggered once, but then there's a [bng] that invites you to 
re-trigger it, at which point the count becomes bogus)


when testing your patch, i triggered a bug in Pd (that i didn't know 
about yet): recursive loadbangs...

https://github.com/pure-data/pure-data/issues/1523

if you rename the patch (and open the renamed version), it will freeze Pd.
the underlying problem is of course that there is no introspection to 
find out the name of an abstraction itself.




I wonder how to find the size of [list store] also


count the elements you added?



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.52-0 test 4 released

[IOhannes m zmoelnig]

On 12/16/21 15:28, Alexandre Torres Porres wrote:


First, replying to emails from pd-announce sends to 'pd-l...@iem.at' and
not 'pd-list@lists.iem.at', which results in undeliverable messages that
return back.


thanks for finding the long lost reference to the old and outdated address.
it's now fixed.


Questions: - Will we provide downloads for M1 macs?


most likely not.

gfmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Testing Pd builds with JACK

[IOhannes m zmoelnig]

On 12/16/21 11:08, IOhannes m zmoelnig wrote:

i don't know


just to be sure: what i suggested is in no way canonical.

i only discovered that there is this jack2-osx-files.txt file and it 
seems to contain a ("the"?) list of files installed by the package.


i guess the only people who can answer this are the JACK-devs (eg. #jack 
on liberaIRC)


gmsad
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Testing Pd builds with JACK

[IOhannes m zmoelnig]

On 12/16/21 10:20, Roman Haefeli wrote:

On Thu, 2021-12-16 at 10:05 +0100, Roman Haefeli wrote:

  I usually wiped


* all jack* binaries in /usr/local/bin
* /usr/local/include/jack directory

I forgot to mention /usr/local/lib/libjack*

(those are probably the most crucial when it comes to Pd detecting
JACK)


the jack2-osx-1.9.19.pkg installs a file that contains its contents:

~~~
cat /usr/local/share/jack2/jack2-osx-files.txt | while read f; do
  rm "${f}"
  rmdir "${f%/*}" 2>/dev/null
done
~~~

or just:
$ rm $(cat /usr/local/share/jack2/jack2-osx-files.txt)



i don't know whether the pkg does something else (like changing some 
settings), and how to undo those.
it's a pity that it doesn't come with an uninstall script (the olde 
JackOSX package had something like this)


gfdsrm
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] JACK on macOS

[IOhannes m zmoelnig]

On 12/14/21 14:45, Christof Ressi wrote:
2. turn on "callbacks" in Pd's audio settings (it seems that this is 
required on macOS) 
Are you sure? 


i'm not sure at all.

however, i'm testing mostly with the "dummy" backend (rather than a 
"real" soundcard-based backend like "coreaudio"), and in my tests i need 
to enable "callbacks" to have Pd do anything.
my test usually is just looping back the output of Pd to it's input (so 
i dont really need a soundcard, but i still know whether Pd can send 
data to JACK and receive data from JACK)


dfksard
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] JACK on macOS

[IOhannes m zmoelnig]

On 12/14/21 13:49, Csaba Láng wrote:

Iohannes,
I tested jack on Big Sur (11.6.1) but looks like no audio is coming out.
[image: Screenshot 2021-12-14 at 13.46.31.png]

Output device must be the same as input, I cannot change it in Pd.
Portaudio works fine but Jack is without sound.


1. make sure that you have connected Pd to your soundcard in qJackCtl 
(using the `Graph` resp `Connect` button)
2. turn on "callbacks" in Pd's audio settings (it seems that this is 
required on macOS)



thanks for testing.

gfmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] JACK on macOS

[IOhannes m zmoelnig]

On 12/13/21 22:06, IOhannes m zmölnig wrote:
>
>
> once it finished building, the dmg will be available on
 


>
> could you please be so kind and test with that version as well?

my first tests show that this version indeed works (at least on Catalina).
could someone on Big Sur or Monterey confirm this?


gfsdr
IOhannes


PS: here's a bit more in-depth tech babble, for those interested what (I 
think) is going on:




this info in the issue was incredibly helpful:
 > JACK protocol mismatch 8

afaict it tries to tell us that Pd and jackd speak different (and 
obviously incompatible) protocols.


i'm currently trying to create a new binary on our CI that finally uses 
the pre-built binaries from jackaudio.org (as dan always suggested).


hopefully this will get the protocol version right.


i now think that this was a red hering.

the problem really seems to be that depending on whether Pd is linked 
against  JACK from homebrew or jackaudio.org it will look for the 
library in /usr/local/opt/jack/lib/ resp. /usr/local/lib/.
for reasons i do not fully understand yet, a homebrew-jacked Pd (that 
looks for libjack.so.0.1.0 in /usr/local/opt/jack/lib/) will refuse to 
load the library if it is found in /usr/local/lib/ (even though this is 
a standard search path for libraries).
copying/symlinking the libjack.so to the searched for directory, makes 
binaries work.


$ mkdir /usr/local/opt/jack/lib/
$ ln -s /usr/local/lib/libjack.0.1.0.dylib /usr/local/opt/jack/lib/


of course this is not really practical


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Vanilla: getting the content of a folder

[IOhannes m zmoelnig]

On 12/14/21 09:58, Pierre Alexandre Tremblay wrote:

Dear all

I am banging my head against the wall, trying to get [openpanel 1] to give me 
the content of the folder in question. I was hoping that I could:

- use [textfile]’s read to get the content of the folder somehow
- use [text define xx]’s read message

But no cigar. Is there any other avenue or hack or way around? I sometimes have 
regrets of sticking to vanilla for FluCoMa dependencies…




[file glob]

(requires Pd-0.52)

gdsmrd
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] JACK on macOS (was Re: [PD-announce] Pd version 0.52-0test3 released)

[IOhannes m zmoelnig]

On 12/13/21 14:56, William Brent wrote:


If I then start Dan's most recent build of test3
(Pd-0.52-0test3-x86_64-jack.app) from this email thread, choosing "jack"
from the Media menu results in no error and "pure_data" shows up in the
JACK connection graph.


thanks for the info.

i'm having a bit trouble finding the relevant infos in this growing 
thread (getting old, i guess), so i've started a ticket on github to 
collect all this information.


https://github.com/pure-data/pure-data/issues/1512

it would be supercool if you could add your info as well.
(there's no need to test with JackOSX like I did - i only did this 
because Jack-1.9.19 was not really working on ElCapitan)



Thanks and let me know if I can test other attempts to fix this. I'll keep
an eye on this thread.



could you also try the "iem-ci" build that is linked in the ticket? (it 
links to a disk image, that should be signed and notarized)

that would be great.

gfmadsr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd version 0.52-0test3 released

[IOhannes m zmoelnig]

On 12/13/21 11:25, IOhannes m zmoelnig wrote:


hmm, which dmg?

my plan was:
- download the .tgz



ah.
re-reading your emails i see:

On 12/12/21 23:01, Dan Wilcox wrote:
> I use the distribution from http://jack.org which is
> equivalent to the old JackOSX distribution:
> https://jackaudio.org/downloads/


now i downloaded from https://jackaudio.org/downloads/.
where *should* I download from instead?
http://jack.org seems to be very wrong - health related rather than 
audio related...


gmasdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd version 0.52-0test3 released

[IOhannes m zmoelnig]

On 12/13/21 10:53, Dan Wilcox wrote:

FYI IOhannes:

For a project at work which uses JACK, I set up the build system to download 
the prebuilt JACK dmg and extract it to a local build directory. This seems to 
work fine for both building *and* distribution as user systems which have 
(non-homebrew) JACK installed are able to run the program with JACK.


hmm, which dmg?

my plan was:
- download the .tgz
- extract the .pkg from the .tgz
- run `installer -pkg ./*.pkg -target /`

afaict, there's no way to tell `installer` to extract to a specific 
directory (as opposed to (disk) volume).


but anyhow: for somewhat unrelated reasons i like this more that 
installing "jack" via homebrew (given that with homebrew you quickly end 
up rebuilding your entire system if you are not running the very latest 
macOS - something that is rather detrimental to the idea of a CI)




I have a feeling that, like JackOSX before it, the JACK distribution builds do some extra 
step which makes this "magic" work (weak linking?) while the Homebrew builds do 
not (linked applications expect same lib path). As to why exactly, I don't know, maybe 
changing the dylib path? In any case, I think it's easier for most people to run an 
installer rather than ask them to copy/paste and run command line incantations to use 
JACK via Homebrew. :)


but isn't this what i'm seeing (as described in my previous mail): JACK 
being "somehow" weekly linked.


i somehow have the feeling i'm looking at the wrong places for the issue 
you seem to be having.


how can i quickly test whether my builds work as expected?

gf,msdrt
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list