Pd-list September 2019

pd-list@lists.iem.at

48 participants
61 discussions

Cyclone 0.4 released
by Alexandre Torres Porres 16 Sep '19

16 Sep '19

Cyclone 0.4 is out! It needs at least Pd Vanilla 0.50.0 (thanks to the new [pdcontrol] object from 0.50.0, cyclone/buffer~ can now load files relative to its owner patch). There's also a few fixes and improvements, but more importantly, we're removing the capital letters aliases (this was warned in the cyclone 0.3 release). Find more details and binaries at: https://github.com/porres/pd-cyclone/releases/tag/cyclone0.4 <https://github.com/porres/pd-cyclone/releases/tag/cyclone0.4?fbclid=IwAR205…> Hold on for them being available in deken in a day or so... (raspberry pi binaries will take a little bit more to appear) cheers

1 0

pd~ and rpi
by iftah gabbai 15 Sep '19

15 Sep '19

hello list, its my first email ever so i really hope i do the guidelines justice i tried searching the list and google and couldn’t find too much info so i try here: im attempting to use (pd~) in a patch in order to use multicore processing on my rpi 3b+. it works fine on my mac using pd 0.50 but does not seem to work on my rpi running strech lite headless and pd 0.47. the closest i got is to get it to print info out of stdout and this is happening only when i start the dsp in the sub process which kinda contradicts the documantaion. i tested also using atest patch which is just an osc~ connected to a dac~ in the sub process but still no luck. i wonder if anyone ever got this to work? is it related to 0.47 and should i go thru the trouble of compiling / installing a newer version since 0.47 is the latest version available for strech lite as far as i understated? thank you very much

1 0

Patching in Linux - the "sweet spot" ...
by oliver 13 Sep '19

13 Sep '19

Hi, 2 questions about patching in PD in a LINUX environment: 1.) i am having a little bit of trouble making patchcord connections under LINUX (Debian 10) as i find the "sweet spot" (the area where the cursor changes and the connection can be made) quite small. feels like a mere 3 pixels to me, that i have to hit very precisely ... coming from Windows i find that the "sweet spot" is much easier to grab there, it really feels different and much easier. As far as i know, the height of an object is 16 pixels, so i figure it would be safe to have something like 5 or 6 pixels as a "connection area" on both ends. Anyway, i think it should be a little larger than it is right now. Or is it maybe again just my system that's acting strange ? 2.) just a small thing: when my cursor changes to "ready for connection", i am getting a ring icon on windows. on linux i get a weird icon that implies "action impossible". i can patch alright, but it's irritating. does anybody know where i could easily change this design ? thanks for any help oliver -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\ ////////////////////////////////////////////////////////

5 4

8 channel circle panner, how?
by Alexandre Torres Porres 13 Sep '19

13 Sep '19

Hi, how would one code an 8 channel panner, considering a circle speaker setup? I'm not looking for an external, I wanna know how to do it as a patch, then as an external into my externals library - as a request :) But if there's an external around, maybe I could check it out how it's done ;) thanks

12 17

Re: [PD] 8 channel circle panner, how?
by Dudley Brooks 12 Sep '19

12 Sep '19

On 9/12/19 6:35 AM, Winfried Ritsch wrote: > Am Mittwoch, 11. September 2019, 01:01:01 CEST schrieb Dudley Brooks: >> A quick question, of purely academic interest: >> >> In theory, wouldn't it be possible to get 3D spatialization with just >> four speakers arranged in, say, the corners of a tetrahedron, such as >> one directly above and three in an equilateral triangle below the >> listener's "horizon" (i.e. the plane of the listener's ears)? I'm sure >> that six speakers would be preferable -- maybe fewer "dead spots"? >> But, strictly speaking, four could do it, right? > yes, > > ... done 1951 with pupitre d'espace, even with 3D-Soundcontroller, the > function of controlling a weigthed Amplification matrix like done in > Ambisonics, so you can use it as Ambisonics 1st order,.. ;-). > > see https://books.google.at/books? > id=psKyCwAAQBAJ&pg=PA205&lpg=PA205&dq=pupitre+de+espace#v=onepage&q&f=false > > mfg > winfried Thank you, Winfried! I was sure it was possible. Mathematically, four non-coplanar points allow you to define three axes which span 3D space. The tetrahedral placement I described gives you one speaker above your ears and three below, so that up and down are defined; one in front (and below) and two behind (and below), so that front and back are defined; and one left (and behind and below) and one right (and behind and below), so that right and left are defined. Thus any (x,y,z) can be specified, and Ambisonics can translate any (x,y,z) into this speaker placement. Perhaps there are "dead spots" because of the shape of the coverage of the individual speakers. I don't know anything about that aspect of the problem. -- Dudley >> On 9/10/19 12:39 PM, Roman Haefeli wrote: >>> On Tue, 2019-09-10 at 14:43 -0300, Alexandre Torres Porres wrote: >>>> Em ter, 10 de set de 2019 às 06:15, Roman Haefeli <reduzent(a)gmail.com >>>> >>>>> escreveu: >>>>> For true spatialization >>>> what is "true spatialization"? >>> I mean true spatialization as opposed to simple panning. You asked for >>> a panner and you were given a panner. Then you said you were thinking >>> of a more sophisticated panner. And I said what you want might be >>> spatialization that not only emulates a sound source traveling along a >>> virtual circle, but that is able to emulate also every position in >>> between. Sounds to me like true spatialization. But I'm only guessing. >>> I can't read your mind, don't know what you really want. I can only >>> read you mails. Only apt has super-cow powers. >>> >>>> And why would else/pan4~ not be "truthful"? >>> Did I say it is not "truthful"? I'm sure it's a very true panner. It's >>> even 2D (it positions the sound source anywhere between the speakers, >>> not only on the outlines). Now, isn't that exactly what you want, but >>> only with four channels? I'm confused now. >>> >>>>> - it sounds to me that is what you're aiming at >>>>> - use Ambisonics[1]. >>>> hmm, I don't really know, and here's a silly question. It seems to me >>>> ambisonics tries to locate a sound source in a 3D sphere, but the >>>> idea would actually be to pan the sound source in a 2D circle space. >>> It's a totally fine question. I'm not an expert either. Ambisonics is >>> able to render in 3D, but you can also do 2D (for instance, if you >>> place all speakers on the same plane). What I understand is special >>> about Ambisonics, is that you do not need to know beforehand for which >>> speaker setup you're making a recording or a rendering for. Only the >>> decoder needs to know the exact configuration of the speakers. This >>> allows for setups that are not a perfect circle or sphere. >>> >>>> So, can ambisonics help there or is it overcomplicated for that >>>> matter? And how is it possible with 8 speakers to simulate a 3D >>>> sphere? >>> Again, not an expert speaking here, but depending on your goals you >>> need that complexity. If your speaker setup is for some reason not a >>> perfect circle, or the positions are not evenly spaced, the image of >>> your virtual sound source(s) is distorted. If you want to account for >>> that, it's probably easier to use Ambisonics than figuring out all the >>> calculations on your own. Do you care for a good reproduction of >>> spatial image? Do you need the flexibility that Ambisoncis gives you? >>> Do you want re-invent things each time the setup is different? Would >>> like to be able to switch between 2D and 3D with the same system? Do >>> you want your piece to be played "correctly" at some other venue that >>> is not the studio where you worked on your piece? >>> >>> I'm not saying you want all that. I'm just thinking that the more you >>> deal with the stuff, the more those aspect are going to matter. >>> >>>>> There seem to be Pd externals for this. >>>> yeah, I know, just not sure if all the complicated encoding and >>>> everything is indispensable and stuff >>> I don't know. I'm not sure if what you want is different from >>> [else/pan4~], but with 8 channels... >>> >>> Roman >>> >>> _______________________________________________ >>> Pd-list(a)lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list

1 0

Tcl/Tk error in slop~ helpfile
by oliver 12 Sep '19

12 Sep '19

hi, i'm getting a TCL/TK error in the PD console window when i click on the "open HTML documentation in help browser" button in the helpfile for the new [slop~] object: (Tcl) UNHANDLED ERROR: wrong # args: should be "::pd_menucommands::menu_openfile filename" while executing "::pd_menucommands::menu_openfile C:/Program Files/Pd/doc/5.reference/../8.topics/slop-tilde.htm" ("uplevel" body line 2) invoked from within "uplevel #0 $docmds" this is with a freshly installed PD 0.50 in windows (installer version) and i'm pressty sure it's because of the space in the path. because when i do the same with the standalone (.zip) version, where i don't have paths with spaces in it, the error doesn't occur. best oliver -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\ ////////////////////////////////////////////////////////

2 1

Key onsets are suppressed while Alt_L is pressed
by Roman Haefeli 11 Sep '19

11 Sep '19

Hi all I noticed that [keyname] doesn't output key onsets while Alt_L key is pressed. The pressing and releasing of Alt_L is reported correctly, though. This is with Pd 0.50.0 on Linux (Ubuntu 18.04). I'm interested in implementing some key commands and intended to use Shift_L, Control_L, Alt_L as modifier keys. Would that work on other OSs? Is that something that is coming from Tk and cannot be fixed in Pd? On a related note: If I have many instances of the patch listening to key commands open, I wouldn't want all of them to perform the key commands. Is there a way to detect which canvas is the active window? Roman

1 0

Re: [PD] font issues - once again ...
by Dan Wilcox 11 Sep '19

11 Sep '19

> On Sep 11, 2019, at 12:03 AM, pd-list-request(a)lists.iem.at wrote: > > I somewhat got tired from nagging about this issue, especially since I > don't feel enabled to help in any way. Those font rendering issues seem > really confusing, complicated, and hard to tackle, but they still > bother me, because it is not only a matter of appearance, but sometimes > even of functionality. Since the fonts are now the same across platforms and we ported the Pd-extended box sizing, font issues now are largely due to system settings and issues with Tk. (Hopefully.) I remember looking into Tk's scaling a year ago (or so) and Tk *still* is not consistent regarding HiDPI screens, especially on Linux. Windows is not great either. Ideally we could ask for the screen scaling metric and adjust canvas size & drawing with that. On macOS it works great, but that's largely down to the window manager handling scaling in an easy way for applications to deal with. This topic might be worth revisiting to see if we could use the scaling value instead of setting it to 1.0 at startup as we currently do. > On Sep 11, 2019, at 12:03 AM, pd-list-request(a)lists.iem.at wrote: > > This probably should be mentioned in PD's README, so people know where > to look for possible culprits concerning font issues. There is also the fonts/README.txt that documents info about Pd's font usage. https://github.com/pure-data/pure-data/tree/master/font <https://github.com/pure-data/pure-data/tree/master/font> Perhaps this is a good place for this kind of info? Can the two of you, who have experience in debugging this issue, look into adding a section about this? Either there or on the wiki somewhere. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

font issues - once again ...
by oliver 11 Sep '19

11 Sep '19

hi ! i am aware, that font (compatibility) issues have been discussed here quite often, but i'd like to open it once again ... recently when i tried to check a couple of my abstractions for cross-platform compatibility, i discovered a huge difference in size when the default font (DejaVu Sans Mono) was used on either windows/osx and linux. But "DejaVu Sans Mono" on Linux (Ubuntu 19.04) has a much larger spacing than on both other platroms, making text designs in PD patches incredibly difficult to be cross-platform. i'm not talking "not 100% precise", it's way more than that, as you can see on the screenhot i made with the attached patch on 3 different systems. only on linux the text is way too long for the background canvas and becomes invisible (because it's white ...) (or see the screenshots here:) https://wolke.klingt.org/index.php/s/sAJg9z4VqRaeB9G Some questions: 1.) Do other Linux users have the same font experience, or is my distro messed up ? 2.) I installed 3 fairly recent PD versions on each system (0.50 in win/osx, 0.49 on ubuntu via apt-get). why do they all use different TK versions ? 3.) why is the windows default font-weight bold ? it looks ... well ... fuzzy to me ... (though it's no big deal as i can change it in the preferences - but what's the design decision here ?) 4.) why "times" ? ;-) (i won't even bring up the subject that the three standard PD fonts (DejaVu Sans Mono, Helvetica, Times) all look quite different on either platform, but since the spacing is more or less correct - safe for "times" which i never use - i don't really mind.) thanks for help or clarifications best oliver -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\ ////////////////////////////////////////////////////////

4 8

[PD-announce] PD Auto Complete Plugin v0.47.0
by Henri Augusto Bisognini 10 Sep '19

10 Sep '19

Pure Data Auto Complete plugin v0.47.0 released! It fixes a lot of bugs in 0.47.0test1. Now it should be usable with pd 0.50. Get it on Deken. If you find any bug please report it on the github issue's page. https://github.com/HenriAugusto/completion-plugin Cheers, Henri. _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

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 2019