Pd-list September 2020

pd-list@lists.iem.at

44 participants
48 discussions

[PD-announce] [vstplugin~] v0.4.0 released!
by Christof Ressi 06 Sep '20

06 Sep '20

I'm happy to announce the release of [vstplugin~] v0.4.0 - a Pd external to load VST plugins on Windows, macOS and Linux! Binaries are available on Deken or can be downloaded here: https://git.iem.at/pd/vstplugin/-/releases <https://git.iem.at/pd/vstplugin/-/releases> If possible, please report any issues at https://git.iem.at/pd/vstplugin/issues, otherwise leave a comment here: https://forum.pdpatchrepo.info/topic/13013/vstplugin-v0-4-0-released --- Here are the major new features: * automatic bit bridging (load 32-bit plugins on a 64-bit Pd and vice versa). * |[open(|: new flags "-p" for sandboxing and "-b" for bridging. Both options allow plugins to crash safely without taking down the Pd. This can be handy for buggy/unstable plugins (especially during live shows :-) * |[open(|: new "-t" flag for multithreading (process plugins in seperate helper threads to utilize more CPU cores) * |[latency(| message is sent whenever the plugin's processing latency changes See the release page for the full change log. Have fun! Christof _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 1

Re: [PD] pd~ binary for max/msp - not really working yet
by jayrope 05 Sep '20

05 Sep '20

Thank you, Miller, for looking into this Using pd~ 0.4 in Max 7.34 with PD 0.50-2 on Mac OS 10.9. i find this error: [pd~ -ninsig 2 -noutsig 2 -fifo 10] leads to right channel (2) not receive anything from PD, while the max patch (same with the help file associated with pd~) the right channel shows complete overload on the meter. Just for a difference i tried 3 channels instead [pd~ -ninsig 3 -noutsig 3 -fifo 10] moves the problem (including displayed overload) to channel 3, now channel two works with PD. Might help debugging. -- jayrope +++ jayrope.com aircushionfinish.com kliklak.net

3 2

[PD-announce] jmmmp library Version 0.60 - [jp.coll]
by João Pais 05 Sep '20

05 Sep '20

Hello everyone, The jmmmp library of abstractions has been updated to version 0.60. Added [jp.coll], an abstraction to store/edit message collections VERY SIMILAR to cyclone/coll, but in vanilla. You can download it soon through deken, or in http://bit.ly/jmmmp_060 <https://bit.ly/jmmmp_060?fbclid=IwAR1AmnRc3wBfBjjdD0RjUtxIMFOJmMLrhfkpoAjXz…> Best, João Pais _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

2 7

Ideas about double precision
by José de Abreu 03 Sep '20

03 Sep '20

Hello list, i'm excited about some possibilities of double precision, and i had some ideas, but instead of making an issue on github, i think that would be interesting to put here, so maybe this would create some discussion if these make sense before asking a feature request haha As this is implemented now, I noticed that when you type on boxes, numbers get truncated so you lose precision and there was a good argument on github that is best to show 440 instead of 439.99999243521 or something like that. But what if we could type an extra d to show to pd that we want to keep that number in full precision? It would be, for example [* 3.1415926535d] and voila, pd doesn't truncate to [* 3.14159] and this could be used in other contexts, print could receive a flag -d to show full precision on console, so [print -d] would be the decision of the user to not truncate numbers, and maybe number boxes could have one flag in the properties so the user could choose if he want to see the number full or truncated, what do you think? But one thing that i missed that is the really the reason that i am thinking about this, is that in data structures, the numbers are also truncated, and i was excited to see pd double precision to be able to record these numbers in data structures, so, what about introducing double to force data structures to keep these as double? the struct object could be, for example [struct foo float x float y double piJustForExample double myAnotherNumber] and then in the file maybe this large number would be in this other format, 3.1415926535d with d appended. In my use case, i have an old patch that used data structures to calculate frequencies from ratios, and this keep the ratios as a fraction, numerator and denominator separately, so i could show the ratios and do some crazy math with harmonics and subharmonics, and when i multiply many times these numbers were truncated by lost in precision, so i wasn't able to multiply and then come back as the numbers were getting large and start to give errors (not real errors, just wrong numbers, as they were lost in the process), i know this is confusing and over simplified, but if i could keep these numbers with full precision i would be very happy haha

1 0

[PD-announce] r_cycle | Pd library for creative coding with Launchpads
by Mario Buoninfante 03 Sep '20

03 Sep '20

Hi, I'm really glad to announce the release of r_cycle, a project I've been working on recently, initially presented at the end of last year in London in the form of a workshop. r_cycle is a Pd (Vanilla) library developed to work with Launchpads (old and new) that can also be used for other purposes (of course it's open source). r_cycle allows users to interact with the Launchpad controllers and create widgets on the device on-the-fly. For example in your Pd patch you create a [KEYBOARD] object and this will appear on the Launchpad, you delete the object in Pd and this disappears on the Launchpad. You press a pad that is part of the widget and the object returns some value in Pd. The arguments of the object determine its characteristics (position, pitch, color, etc.). r_cycle doesn't only include "widgets" but audio and MIDI objects as well, simple things that made my life easier and I thought would be worth sharing. You can find more info here: https://novationmusic.com/en/news/hack-making-music and a simple introduction video here: https://vimeo.com/442976991 Cheers, Mario _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

2 1

[pii2c] won't send more than 32 bytes
by Alexandros 02 Sep '20

02 Sep '20

The MAX_I2C_BUF_SIZE macro in pii2c.c is set to 64, but still when I try to send 64 bytes to a slave Teensy, only 32 go through, the rest 32 are all 0s. Raising this value to an even greater number, like 128 (which is something I would like to implement), gives similar results. The same behavior occurs whether I set the I2C address as an argument to the object, or if I pass it through the "write" message. I checked the code and couldn't find where this occurs. I added this: `post("%d", x->x_xferbuf[i-1]);` to line 348 to make sure the bytes are stored in the object's buffer, and they do get stored properly. The only place I found they end up in is a "write()" function, called in line 293, inside the pii2c_writer() function. I guess this function is from one of the header files included in the object, as I couldn't find it in the code. Long story short, is it possible to send more than 32 bytes over I2C in the Pi? I really like [pii2c], and since wiringPi is now deprecated, I'd like to stick to this object.

2 2

Re: [PD] pd~ binary for max/msp - test version available
by Fede Camara Halac 02 Sep '20

02 Sep '20

Woa! This is great news! Thanks a lot, Miller! fdch.github.io > On Sep 1, 2020, at 11:58 PM, Miller Puckette via Pd-list <pd-list(a)lists.iem.at> wrote: >

3 3

Re: [PD] Binural externals
by José Rafael Subía Valdez 01 Sep '20

01 Sep '20

Hello Julian thank you so much for this one, I am very interested. I will download and test it and be in touch with you. congrats on your work. best On Mon, Aug 31, 2020 at 7:15 PM Julián Villegas <villegas.julian(a)gmail.com> wrote: > (This is a resend, somehow the first time I sent this didn’t reach the > list) > > Hi Jose, > > I’m sorry for arriving late to the party, but I think you maybe interested > in [hrir~], a spatializer that allows you modify distance besides azimuth > and elevation. This object is based on Qu et al. database, I have equalized > it to remove the effect of the measurement apparatus, and resampled it to > use it with different sampling rates. Note that [earplug~] is based on the > MIT database recorded at a fixed distance (1.4 m, IIRC) and a sampling rate > of 44.1 kHz. That means that if you want to use it at a different sampling > rate, the binaural image gets distorted. > > Binaries, source code and databases at different sampling rates are here: > > http://onkyo.u-aizu.ac.jp/HRIR > > My student and I are working on a new version that includes the two > different pinna simulators used by Qu and colleagues (currently, only the > right —small—pinna is used). We’re also working on improving the > scalability of the object. If you’re interested, on learning more, please > let me know. > > Details of our method are found here: > > [1] J. Villegas, “Locating virtual sound sources at arbitrary distances in > real-time binaural reproduction,” Virtual Reality, vol. 19, pp. 201–212, > Oct 2015. > [2] C. Arevalo and J. Villegas, “Compressing head-related transfer > function databases by eigen decomposi- tion,” in IEEE Int. Wkshp. on > Multimedia Signal Processing (MMSP), (Tampere, Finland), Sep 2020. > > Let me know if you have questions, > > Julian. -- José Rafael Subía Valdez www.jrsv.net

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 September 2020