Pd-list July 2021

pd-list@lists.iem.at

29 participants
28 discussions

Preset management for Pd Vanilla
by Alexandre Torres Porres 13 Nov '23

13 Nov '23

Never really needed fancy preset management other than storing messages in a basic vanilla way. But I've seen people mention how Pd lacks a nice preset system. Not that I know what a fancy one actually needs since I never felt the demand. So I'm here to ask what people use in Pd Vanilla, be it a pure vanilla solution or an external. And also to ask what people miss. This is what I came up with as a pure vanilla abstraction, it's based on [text] and [savestate]. Here's the thing: https://drive.google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=… In short, the preset abstraction takes messages and stores them. You can have many of these on your patch and use them to recall presets for any parameters. It takes any kind of messages. I'm making use of built-in sends and receives in the number boxes to make the patch cleaner. Just think that you can have separate control of each parameter having its own preset or group all of them together globally, or a group here and another there, whatever... Once you save the patch, the presets you saved get stored in the patch. As for my current idea for my ELSE library, I'm using an object similar to grab to take messages from [receive] objects. It's a development over this original vanilla abstraction. My first draft is this, I hope that sharing the screenshot give you a nice idea. [image: Screen Shot 2021-01-21 at 04.47.42.png] You can check what's up in my repository for more details... https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd cheers

13 36

soundtouch~ for Pd Vanilla
by Alexandre Torres Porres 31 Oct '23

31 Oct '23

Hi folks, I'm on a vibe of uploading missing libraries and objects for Pd Vanilla on deken. On the list I have FFTease, Lyonpotpourri, CICM-Tools and more stuff that I'm looking into, just so you know... Now, I see there's an old soundtouch~ external here: http://www.katjaas.nl/pitchshift/soundtouch~.html - it's "version 0.9" by Katja Vetter. It was developed with SoundTouch version 1.6 and Pure Data version 0.42. I tested on Pd 0.51-4 32 bits on mac and it works fine. There are binaries for download on the link above, but not for 64 bits. I wonder if anyone wants to help me build these with pd-lib-builder and all. Now, the ceammc librarym (and Pd-ceammc distribution) has a soundtouch~ external too. It's the same name, but not the same external, this one is marked as "version 0.1". So we do already have "a" soundtouch~ for vanilla, but I wanted to also get katja's external up there. So I just uploaded the download from that page here https://github.com/porres/pd-soundtouch - It's just the download as it is and we need to change to hopefully use pd-lib-builder, which would make things easier. I did try that and it didn't work. So, anyone onboard with this? cheers

7 21

MIDI specifications for Multidimensional Polyphonic Expression (MPE) in Pd
by Alexandre Torres Porres 26 Oct '23

26 Oct '23

some new objects for MPE Midi is on Max's new update, just googled it to see what it was http://expressiveness.org/2015/04/24/midi-specifications-for-multidimension… wonder if you guys know anything about this and if anyone would be into bringing this to Pd. cheers

2 5

variable speed tabwrite~?
by Peter P. 16 Aug '21

16 Aug '21

Hi list, hope you are fine! I am trying to build a variable speed looper which can change its reading and writing speed by the same factor. How could this be done? It seems there is no object that allows writing to a table (or delay line) at fractional speed. There is some discussion about [tabrwrite4~] or [ipoke~] in the list archives, but it seems it never led somewhere near an implementation, unless I am missing something. Could it work by placing order-forced [tabwrite~] and [tabread~] into a resampled subpatch perhaps? It would not allow seemlessly variable speed if it worked at all... thanks for all ideas/pointers! P

6 8

Pd files on Linux: MIME type and (document) icons
by Max 04 Aug '21

04 Aug '21

Hi list, Linux doesn't let you define that a file extension .pd shall be opened with pd-gui. Since .pd files are of the texfile MIME type, if you set them to be opened by pd-gui, also every double click on a text document will launch pd-gui. Instead, when you want .pd files to be opened with the pd-gui executable, you first need to register a new MIME type. This is done by installing an XML file of the freedesktop standard "shared-mime-info". Albert Graef has made one for pd-l2ork/Purr Data, which you can find here: https://github.com/pd-l2ork/pd/blob/master/debuild/debian/sharedmimeinfo I've adapted that to Pure Data: https://github.com/chairaudio/pd-icon/blob/mime-install/x-puredata.xml Dan Wilcox made this repository with icons for Pure Data: https://github.com/pure-data/pd-icon I have forked that and added a method to install the mime type https://github.com/chairaudio/pd-icon/tree/mime-install The command "make mime-register" will add the MIME type. It's adapted from what I found here: https://stackoverflow.com/questions/30931/register-file-extensions-mime-typ… There are some comments on my pull request by IOhannes: https://github.com/pure-data/pd-icon/pull/6 Anyway, maybe someone more knowledgable can take over here, the goal is to include this to the Pd installation so that Pd documents on Linux have the Pd file icon and are opened by pd-gui by default. m.

3 3

Re: [PD] JACK2 support on macOS
by Dan Wilcox 31 Jul '21

31 Jul '21

As I mentioned in the Github issue, we should move to the following model * Builds for *old* versions of macOS, should use jack weak linking to work with *old* builds of JackOSX (if they can find it). * Builds for *newer* versions of macOS, should be built linking to the newer official Jack mac builds. This requires a newer build system and Jack pre-installed. > On Jul 31, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > This is on 10.15.7. I don't have access to other macOS versions right > now and I fully support being cautious. But contrary to your statement > that JACK1 is more 'compatible', the Pd.app I get from Miller's site > doesn't run with JACK2, which I believe is what users normally install > these days. The site http://www.jackosx.com <http://www.jackosx.com/> mentioned in INSTALL.txt > doesn't exist anymore. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

JACK2 support on macOS
by Roman Haefeli 30 Jul '21

30 Jul '21

Hey all On macOS, I used to download a package named JackOSX for installing JACK (which seems to be the JACK1 implementation). Since a while now, the prominent source to get JACK seems https://jackaudio.org where you get JACK2 installers for macOS (and other platforms). Pd downloaded from Miller's site doesn't see the JACK2 server on macOS. However, when I build a Pd.app against JACK2, I end up with a Pd that works with both, JACK1 and JACK2. To me it looks like the official builds are built against JACK1. Is there a reason to stick with JACK1, when building against JACK2 seems to support both? I'm not totally sure how far that support goes. I know about some instances where Pd.app built against JACK2 didn't see the JACK1 server. I didn't figure out why this was the case on one such system, but not on others. Anyway, my impression is that someone installing JACK on macOS now is more likely to find JACK2 than JACK1. Roman

2 4

JACK affects UDP rate
by Roman Haefeli 28 Jul '21

28 Jul '21

Hi all, We experience "unexpected" latency with our software tpf-client [1] on macOS. When using JACK as audio-backend and using a blocksize [2] of 64, latency grows over time, growing whenever there are dropped packets. The issue appears only when all three criteria are met: * Pd is running on macOS * Pd is using JACK as backend * blocksize is 64 On Linux, the patch runs fine, even with JACK as backend and using blocksize=64. When using CoreAudio on macOS, there is also no growing latency. Using JACK on macOS also works when using blocksize=128. I can only guess what is going on, but it seems that with JACK Pd can only digest a limited number of incoming UDP packets. With blocksize=64, it would receive one packet per DSP block on average. Maybe Pd can only consume one packet per DSP tick with JACK as backend? I once made a test patch for measuring maximum UDP throughput that showed some hard limit. Because I didn't get the same values on two different runs, I decided to pursue some deeper investigation another time and suspected a problem in my test patch. It didn't occur to me back then that the difference was between -jack and -nosound. The difference with the test patch is significant also on Linux, though the problem described above appears only on macOS. This is with: * Pd 0.51.4 * macOS 10.15.7 * JACK 0.92.3 (but happens also with newer JACK 1.9) The tpf-client patch is using [iemnet/udpclient] for sending and receiving JackTrip packets. The test patch shows similar difference for both, [netsend -u -b] and [iemnet/udpclient]. Even if it can be fixed, I'm interested in having a deeper understanding of what is going on. Curiously, Roman [1] https://github.com/zhdk/tpf-client (Pd-patch) [2] blocksize here is an application internal parameter unrelated to Pd's or JACK's blocksize. It defines how many samples per channel go into one JackTrip packet.

3 16

Re: [PD] JACK affects UDP rate
by Dan Wilcox 26 Jul '21

26 Jul '21

(Sending again with correct subject line. :P) Note, there is Peter's C atomics ringbuffer.c implementation from libpd now in the Pd sources. It's limited to lengths of a multiple of 256 bytes I believe but easy to use. I have used it successfully in the iOS Audio Unit to handle differing input and output buffer sizes due to sample rate conversion outside libpd. > On Jul 25, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at <mailto:pd-list-request@lists.iem.at> wrote: > > If my analysis is correct (if not, please let me know!), I think the > Jack backend should really adapt the lock-free FIFO from the Portaudio > backend. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Re: [PD] Pd-list Digest, Vol 196, Issue 28
by Dan Wilcox 26 Jul '21

26 Jul '21

Note, there is Peter's C atomics ringbuffer.c implementation from libpd now in the Pd sources. It's limited to lengths of a multiple of 256 bytes I believe but easy to use. > On Jul 25, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > If my analysis is correct (if not, please let me know!), I think the > Jack backend should really adapt the lock-free FIFO from the Portaudio > backend. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list July 2021