Pd-list

pd-list@lists.iem.at

19 participants
33278 discussions

Re: Isn't there a way to decrease the amount of time it takes to load externals in new macOS systems?
by Dan Wilcox 25 Sep '24

25 Sep '24

Consider signing and notarizing? https://github.com/zkmkarlsruhe/mac-dist-helper-examples?tab=readme-ov-file… Note: This would require a developer account. > On Sep 25, 2024, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Tue, 24 Sep 2024 21:54:13 -0300 > From: Alexandre <porres(a)gmail.com <mailto:porres@gmail.com>> > Subject: [PD] Re: Isn't there a way to decrease the amount of time it > takes to load externals in new macOS systems? > To: Linux Rouen Normandie <linux.rouen(a)free.fr <mailto:linux.rouen@free.fr>> > Cc: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Message-ID: > <CAEAsFmi_fQ8vS0GA-zCzfv38LprcZpJc_b16p86Tid05Cu86LA(a)mail.gmail.com <mailto:CAEAsFmi_fQ8vS0GA-zCzfv38LprcZpJc_b16p86Tid05Cu86LA@mail.gmail.com>> > Content-Type: multipart/alternative; > boundary="00000000000047372c0622e71035" > > It's not an internet thing, it's a macOS thing. I'm counting that time lag > after the download was finished and deken mentions 'successfully installed > else'. But then it took now over than 2 minutes last time to load the > README.deken.pd file on my M3 macbook air. > > But yeah, I know it's not an issue on Linux, and I bet it's also not in > windows. > > cheers -------- Dan Wilcox danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 2

Isn't there a way to decrease the amount of time it takes to load externals in new macOS systems?
by Alexandre 25 Sep '24

25 Sep '24

Hi, I recently upgraded to a new arm mac and have been using it. You see, with my old machines running older systems, I can load externals just fine, but at some point, I don't know why, it takes a lot of time to load them for the first time. I just timed this now with my recent ELSE upload to deken. And when we download it from deken now I automatically open a readme file that loads all objects, which forces us to wait until all externals are loaded, and it took about 2 minutes to load in my M3 mac. Almost 2:30 minutes in an older intel running Monterey. I know I'm not codesigning or anything, just building and uploading to deken. So, can I do anything about it at all? Or just tell people to deal with it for the first time? thanks

2 2

Help compiling else 1.0-0 RC12 for linux and windows
by Alexandre 24 Sep '24

24 Sep '24

Hi, I'm releasing an update of ELSE but I now have a whole new build system with cmake, see https://github.com/porres/pd-else?tab=readme-ov-file#building-else-for-pd-v… And I need help compiling it for Linux and Windows. By the way, building for double precision Pd is now possible, and I was able to compile for macOS just fine, but more tests need to be made. I am putting this up in deken for tests. Here's the link to the tagged release https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 Please get in touch and let me know if you can help. I am looking for binaries for raspberry pi, linux and windows, both single and double precision. thanks

4 8

[PD-announce] ELSE 1.0 RC12 with Live Electronics Tutorial Released
by Alexandre 24 Sep '24

24 Sep '24

Hi, it's been a while, here we go: -------------------------------------- RELEASE NOTES: -------------------------------------- Hi, it's been almost 8 months without an update and I never took this long!!! So there's a lot of new stuff to cover, because it's not like I've been just sleeping around ;) The reason for the delay is that I'm trying to pair up with the release cycles of PlugData and we're having trouble syncing up. PlugData 0.9.0 came out recently after a delay of 6 months and we couldn't really sync and pair up then... we had no luck in syncing for a new update now, so now I'm just releasing it up cause enough is enough, and hopefully in the next plugdata release we can sync and offer the same version. As usual, the development pace is always quite busy and I'm just arbitrarily wrapping things up in the middle of adding more and more things that will just have to wait. First, I had promised support for double precision. I made changes so we can build for it, but it's not really working yet when I uploaded to deken and tested it. So, next time? *And now for the biggest announcement:* - I'm finally and officially releasing a new pack as a submodule, which is a set of abstractions inspired by EuroRack Modules, so I'm thinking of VCV like things but into the Pd paradigm. Some similar stuff has been made for Pd over the years, most notably and famously "Automatonism", but I'm really proud of what I'm offering. I'm not trying to pretend Pd is a modular rack and I'm taking advantage of being in Pd. I'm naming this submodule "Modular EuroRacks Dancing Along" (💩 M.E.R.D.A 💩) and I've been working on it for a year and a half now (amongst many other things I do). PlugData has been offering this for a while now, by the way. Not really fully in sync though. MERDA modules are polyphonic, thanks to multichannel connections introduced in Pd 0.54! There are 20 modules so far and some are quite high level. I'm offering a PLAITS module based on the Mutable Instruments version. I have a 6-Op Phase Modulation module. A "Gendyn" module which is pretty cool. I'm also including an "extra" module that is not really quite a modular thing at all but fits well called "brane", which was a vanilla patch I first wrote like 15 years ago and is a cool granular live sampler and harmonizer. You'll also find the basics, like oscillators, filters, ADSR envelope and stuff I'm still working on. Lastly, a cool thing is that it has a nice presets system that still needs more work but is doing the job so far. There are ideas and plans to add hundreds more MERDA modules, let's see when and if I can. People can collaborate and help me and create modules that follow the template by the way ;) Thanks to Tim Schoen, [play.file~] is now a compiled object instead of an abstraction and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS audio file extensions. A new [sfload] object can import these files into arrays (but still needs lots of more work). There are many other player objects in ELSE that can load and play samples but these don't yet support these new formats (hang in there for the next version update). Tim also worked on new [pdlink] and [pdlink~] objects, which send control and signal data to/from Pd instances, versions and even forks of Pure Data (it's like [send]/[receive] and [send~]/[receive~], all you need is a symbol, no complicated network or OSC configuration!). And yes, it works via UDP between different computers on the same network. And hell yeah, [pdlink~] has multichannel connections support! By the way, you can also communicate to a [pd~] subprocess. This will be part of ELSE and PlugData of course, and will allow easy communication between PlugData and Pd-Vanilla for instance. The great pd-lib-build system has been replaced for a 'cmake' build process called 'pd.build' by Pierre Guillot. This was supposed to simplify things. Also, the [sfont~] object was a nightmare to build and with several dependencies that was simply hell to manage, now we have a new and much simpler system and NO DEPENDENCIES AT ALL!!! Some very rare file formats with obscure and seldom sound file extensions may not work though... (and I don't care, most and the 'sane' ones will work). The object now also dumps all preset information with a new message and backwards compatibility broke a bit :( I'm now back to offering a modified version of [pdlua] as part of ELSE, which has recently seen major upgrades by Tim to support graphics and signals! This is currently needed in ELSE to provide a new version of [circle] that needed to be rewritten in lua so it'd look the same in PlugData. Ideally I'd hope I could only offer compiled GUI objects, but... things are not ideal :) The lua loader works by just loading the ELSE library, no need for anything "else". I'm not providing the actual [pdlua] and [pdluax] objects as they are not necessary, and this is basically the only modification. Since PlugData provides support for externals in lua, if you load ELSE you can make use of stuff made for PlugData with lua without the need to install [pdlua] in Pd-Vanilla. For next, we're working on a [lua] object that will allow inline scripting and will also work for audio signals (again, wait for the next version)! Also for the next version, I'm saving Ben Wesch's nice 3d oscilloscope made in lua (it'll be called [scope3d~]). There's a lot going on with the lua development, which is very exciting. As for more actual new objects I'm including, we have [vcf2~] and [damp.osc~]. The first is a complex one pole resonant filter that provides a damping oscillation for a ringing time you can set, the next is an oscillator based on it. There's also the new [velvet~] object, a cool and multichannel velvet noise generator that you can also adjust to morph into white noise. I wasn't able to add multichannel capabilities to many existing objects in ELSE in this one, just a couple of them ([cosine~] and [pimp~]). Total number of objects that are multichannel aware now are: 92! This is almost a third of the number of audio objects in ELSE. I think that a bit over half might be a reasonably desired target. More multichannel support for existing objects to come in the next releases. *Total number of objects in the ELSE library is now 551! * As for the Live Electronics tutorial, as usual, there are new examples for new objects, and I made a good revision of the advanced filter section, where I added many examples to better explain how [slop~] works, with equivalent [fexpr~] implementations. *Total number of examples in the Live Electronics Tutorial is now 528!* There are more details of course, and breaking changes as usual, but these are the highlights! For a full changelog, check https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 (or below at this email). As mentioned, unfortunately, ELSE RC12 is not yet fully merged, paired up and 100% synced in PlugData. PlugData is now at version 0.9.1, reaching the 1.0 version soon. Since ELSE is currently so tightly synced to the development of PlugData, the idea is to finally offer a final 1.0 version of ELSE when PlugData 1.0 is out. Hence, it's getting closer than ever :) Hopefully we will have a 100% synced ELSE/PlugData release when 0.9.2 is out (with a RC 13 maybe?). Please support me on Patreon https://www.patreon.com/porres You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/ cheers ps. Binaries for mac/linux/windows are available via deken. I needed help for raspberry pi -------------------------------------- CHANGELOG: -------------------------------------- **LIBRARY:** Breaking changes: - [oscope~] renamed to [scope~] - [plaits~] changed inlet order of modulation inputs and some method/flags name. If a MIDI pitch of 0 or less input is given, it becomes a '0hz'. - [gbman~] changed signal output range, it is now filtered to remove DC and rescaled to a sane -1 to 1 audio range. - [dust~] and [dust2~] go now up to the sample rate and become white noise (removed restriction that forced actual impulses, that is, no conscutive non zero values) - [cmul~] object removed (this was only used in the old conv~ abstraction to try and reduce a bit the terrible CPU load) - [findfile] object removed (use vanilla's [file which] now that it has been updated in Pd 0.55-0) - [voices] swapped retrig modes 0 and 1, 'voices' renamed to 'n', now it always changes voice number by default as in [poly] (this was already happening unintentionally as a bug when one voice was already taken). The 'split' mode was removed (just use [route], will you?) - [voices~] was also affected by changes in [voices] of course, such as 'voices' message being renamed to 'n'. - [sr~]/[nyquist] changed output loading time to 'init' bang - [sample~] object was significantly redesigned and lots of stuff changed, new messages and flags, added support for 64-bit audio files (Pd 0.55 in double precision and ELSE compiled for 64 bits is required for this). Info outlet now also outputs values for lenght in ms and bit depth. - [sfont~] uses now a simpler build system and this might not load very very rare and unusual sound formats. Enhancements/fixes/other changes: - builds for double precision is now supposedly supported, by the way, the build system was changed from pd-lib-builder to pd.build by Pierre Guillot. - [play.file~] is now a compiled object instead of an abstraction thanks to Tim Schoen, and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS file extensions. - Support for double precision compilation was improved and should be working for all objects (not yet providing binaries and fully tested yet by the way). - The ELSE binary now loads a modified version of [pdlua], but no [pdlua] and [pdluax] objects are provided. - added signal to 2nd inlet of [rm~]. - fixed 'glide' message for [mono~]. - fixed [voices] consistency check bug in rightmost outlet and other minor bugs, added flags for 'n', 'steal' and offset. - [gain~] and [gain2~] changed learn/forget shortcut - [knob] fixed sending messages to 'empty' when it shouldn't, ignore nan/inf, prevent a tcl/tk error if lower and upper values are the same; added "learn/forget" messages and shortcut for a midi learn mechanism. - [mpe.in] now outputs port number and you can select which port to listen to. - Other MIDI in objects now deal with port number encoded to channel as native Pd objects. Objects affected are [midi.learn], [midi.in], [note.in], [ctl.in], [bend.in], [pgm.in], [touch.in] and [ptouch.in]. - [pi]/[e] now takes a value name argument. - [sr~]/[nyquist~] take clicks now and a value name argument. - fixed phase modulation issues with [impulse~] and [pimp~]. - [cosine~] fixed sync input. - added multichannel features to [cosine~] and [pimp~]. - [plaits~] added a new 'transp' message and a functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]), fixed MIDI velocity. - [pluck~] added a new functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]). - 26 new objects, [velvet~], [vcf2~], [damp.osc~], [sfload], [pdlink] and [pdlink~], plus abstractions from a newly included submodule called "Modular Euro Racks Dancing Along" (M.E.R.D.A)! Warning, this is all just very very experimental still, the object are: [adsr.m~], [brane.m~], [chorus.m~], [delay.m~], [drive.m~], [flanger.m~], [gendyn.m~], [lfo.m~], [phaser.m~], [plaits.m~], [plate.rev.m~], [pluck.m~], [pm6.m~], [presets.m], [rm.m~], [seq8.m~], [sig.m~], [vca.m~], [vcf.m~] and [vco.m~] (6 of these are multichannel aware). Objects count: total of 551 (307 signal objects [92 of which are MC aware] and 244 control objects)! - 311 coded objects (203 signal objects / 108 control objects - 240 abstractions (104 signal objects / 136 control objects) -------------------------------------- **TUTORIAL:** - New examples and revisions to add the new objects, features and breaking changes in ELSE. - Added a couple of examples for network communication via FUDI and [pdlink]/[pdlink~] - Section 36-Filters(Advanced) revised, added more examples and details on how [slop~] works. - Total number of examples is now 528! -------------------------------------- _______________________________________________ Pd-announce mailing list -- pd-announce(a)lists.iem.at To unsubscribe send an email to pd-announce-leave(a)lists.iem.at

1 0

clone object protection
by Patko nytkophilus 23 Sep '24

23 Sep '24

Hello, I'm actually working with the great [clone] object for doing additive synthesis, and I'd like to report to list how pd crashing is painful because the cloned abstraction have not been saved by inadvertance when clone object is reinitialized. How about introducing the handful warning message that prevent an abstraction to loose changes with clone object? Best regards, Patco

2 1

Egregore 32bit on MacM1
by Johnny Mauser 22 Sep '24

22 Sep '24

Dear list, dear Cyrille, I want to revisit some egregore modification patch I made a while back. I am not able to run it in current MacOS on an M1 based mac. Is there an existing 64bit version of the egregore underlaying objects? Or any other way I can use 32bit pd on this machine? Thx for hints, Jonas

2 3

how to draw array labels
by Patko nytkophilus 22 Sep '24

22 Sep '24

Hello, On Pd-0.55.1 on apple silicon, I'd like to draw array ticks and labels using messages, as barely explained in help files I do send the following message: [xlabels 0 1 2 3 4 5 6( but the console do answer: array: no method for 'xlabels' Maybe I'm doing something wrong, but I couldn't figure it out. I've also tried to draw ticks with messages, and it do works but the process is able to crash pd is the number of ticks is raised using a numberbox, I think I can go with it but maybe there is something wrong with this method. best regards Pat'

3 4

clear message of vcf~ is gone
by Hans Roels 20 Sep '24

20 Sep '24

Hello, If a [clear( message is sent to the 1st inlet of vcf~ the main window prints a /no method for 'clear'/ message, both in Pd 0.54.0 and Pd 0.54.1 (on Linux). The clear message is mentioned in the reference subpatch of the vcf~-help patch (also on the iem website with an overview of all Pd objects and help files). best, Hans

3 7

small errors and/or omissions, Pd-0.55-1
by marclaperrouze＠lemanege.com 19 Sep '24

19 Sep '24

Hello, a big thank you to everyone for this wonderful programme and to the contributors, forgive me if I'm not posting in the right place, I'm not familiar with the way you work, just a few comments : 3.audio.examples In "D10.sampler.notes.pd" If you click "record 1" or "record 2", error "sample%1: no such array" In pd init-samples, "makefilename sample%1" instead "makefilename sample%d", no ? Idem for "D11.sampler.poly.pd", "D11.sampler.poly.pd" In "F03.pulse.spectrum.pd" No receive "freq" value, lack in "pd ftt", [bang~]-[samplerate~]-[/256]-[s freq] Or in "pd init" no receive for [r fundamental] In "7.stuff/synth/..." synthesizer sound has changed, doesn't like before, after "Pd-0.52-1-really" (MacOs), since "Pd-0.52-2" I'd say.... Cheers ml

3 3

Pd for Espressif ESP32 updated, still janky
by Miller Puckette 18 Sep '24

18 Sep '24

I don't know if anyone besides me is using Pd on Espressif ESP32 boards but in case it's useful I've updated it to work with Pd 0.51-1. It's on msp.ucs.edu/ideas/ . I'm currently getting it to run on generic ESP32 boards (which cost about $10 but you have to hook up your own audio I/O hardware). It should be adaptable to the LyraT boards ($20-ish) - the previous version worked on those but I haven't tested the current version for them yet. This is all working toward an upcoming performance with Kerry Hagan so there are likely to be changes and fixes coming along soon. cheers Miller

3 4

← Newer
1
...
4
5
6
7
8
9
10
...
3328
Older →

Jump to page:

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