Pd-list August 2020

pd-list@lists.iem.at

37 participants
45 discussions

[PD-announce] quacktrip 0.6 released (point-to-point network audio)
by Miller Puckette via Pd-announce 15 Aug '20

15 Aug '20

To Pd announce Version 0.6 of quacktrip is up on http://msp.ucsd.edu/tools/quacktrip/ . It's pretty stable now. I've added a variant I call Netty McNetface that supports groups using a centralized repeater. This partly overlaps with AOO's functionality but has a simpler implementation. cheers Miller _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

0.51-1-test1 issues
by Alexandre Torres Porres 15 Aug '20

15 Aug '20

Hi, t hasn't been announced yet, but since yesterday I've been using 0.51-1-test1 that was just released and is already available at http://msp.ucsd.edu/software.html; so anyway, I have a few issues (I tried github but IOhannes convinced me to go ahead and bring it up here). Here they go: 1- I see a grayish background (macOS mojave), which seems like an unintended change (aka bug). 2- For the sample rate buttons, it feels more intuitive to me that it starts with 44.1k and then goes higher to 48k and 96k, now maybe also add 88.2 and 192k? Those are also pretty common. Then it'd be better to have "Use Callbacks" and "block size" in a new level below or rearrange things differently. 3- As for the release notes, I pointed a couple of issues here: https://github.com/pure-data/pure-data/commit/740212e66012d35ee14eb0fc3fb9a… For last, since I see some changes/fixes were made to inlet/inlet~, perhaps we could also take care of this bug https://github.com/pure-data/pure-data/issues/1111 cheers!

4 14

Fwd: soundfiler read with offset?
by tim vets 15 Aug '20

15 Aug '20

---------- Forwarded message --------- Van: tim vets <timvets(a)gmail.com> Date: za 15 aug. 2020 om 01:56 Subject: Re: [PD] soundfiler read with offset? To: Christof Ressi <info(a)christofressi.com> Thanks for your suggestion, I haven't tried it out yet, but it looks like a good solution... Tim Op do 13 aug. 2020 om 03:38 schreef Christof Ressi <info(a)christofressi.com>: > Right now this is not possible, but it would be a nice feature. Please > make a feature request on GitHub! > > In the meantime there's a simple (but inefficient) workaround: read the > soundfile into a different array and then copy it over with [array get] / > [array set]. > > Christof > On 13.08.2020 02:09, tim vets wrote: > > Is there a possibility with [soundfiler] to load a sound file into a table > at an offset? > Say I want to load one sound into the first half of a table > and a different one into the second half...? > Thank you! > Tim > > _______________________________________________Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list >

1 0

recording 192khz
by iftah gabbai 15 Aug '20

15 Aug '20

hi there, im attempting to record a stereo file (192khz, 24bit) using writesf~ on a rpi3b running headless using the inputs of my usb class compliant soundcard (presonus 24c), so far with no luck, i get crackles after around 10sec of recordings. the weird thing is that the pd process uses around 16% of one core - so theoretically it should be fine, right? i even tried to up the -audiobuf to 100ms but this does not help either. i write the recordings to an external usb stick that can handle much higher speeds than teh equivalent of 1s/192/24 so i dont think its this either, while i dont run a realtime kernel i have my scaling_governor set to performance. i wonder if anyone have any leads? or is this only possible with rt kernel? best

2 5

any way to change the name of delay line used by [vd~] with message?
by William Huston 15 Aug '20

15 Aug '20

Hi, Is there any way to change the name of the delay line used by [vd~] with a message? Alternatively, I think it would be nice for PD to have a mechanism of indirect reference. In this case, [vd~ $0-delay] $0-delay refers to the name of the delay line. What I'd like is a way to put a name like DELAY1 inside a variable which I can set and change. So something like [vd~ ($0-DelayName)] Where $0-DelayName is something I can set to DELAY1. Are either of these possible? The reason this has come up, is I'm trying to build an N-band flanger using [clone]. As it stands, it seems like I have to hard-code the name of the delay line read by each instance which is cloned. Since [clone] can only use an abstraction, this means the instances have a different $0 context than the parent patch. So it seems I have to hard-code the name of the delay line used, which means I can have only one of my N-band flangers per patch. That's probably OK, but I would prefer not to use global variable names if possible. Thanks! BH -- William Huston: WilliamAHuston(a)gmail.com Binghamton NY *Public Service Mapping / Videography / Research / Education / Safety Advocacy* Blog <http://WilliamAHuston.blogspot.com> -- Facebook <http://facebook.com/billhuston> -- Twitter <http://twitter.com/WilliamAHuston>-- Youtube <https://www.youtube.com/channel/UCGijK1amWOLglT3YeTyEBNQ?sub_congfirmation=1> * -- Podcast Blog <https://billhustonpodcast.blogspot.com/>* *Document collections*: VirtualPipelines <http://TinyURL.com/VirtualPipelines> -- BHDCSDimockArchive <http://bit.ly/BHDCSDimockArchive> *Please support my work! -- *TinyURL.com/DonateToBillHuston

2 1

Re: [PD] 0.51-1-test1 issues
by Dan Wilcox 14 Aug '20

14 Aug '20

Howdy all, I don't use dark mode, so I never noticed this personally. I'm surprised it hasn't come up before, actually. From a short search, it seems the easiest fix is to tell the system to ignore dark mode for Pd so it will stay "light" but at least everything will be legible: https://www.techjunkie.com/exclude-app-dark-mode-macos-mojave/ <https://www.techjunkie.com/exclude-app-dark-mode-macos-mojave/> You can try it on your own by running the following in Terminal, then (re)starting the Pd gui: defaults write org.puredata.pd-gui NSRequiresAquaSystemAppearance -bool true What's happening is that some elements are being changed to dark mode while others clearly are not. For instance, some of the canvas draw commands pick up the light gray/white from dark mode but are drawn over a white background. This is down to how Tk handles/doesn't handle dark mode and the default colors specified to Tk from Pd. A proper implementation of this would involve having light and dark color schemes for Pd and possibly the GUI while updating Tk to use the non-color specific tint defaults and handle the color mode change Cocoa events, if it doesn't already do so. I will add a bug fix PR which sets this automatically when you start the GUI, as with a couple of other settings which Pd needs by default. I honestly do not have the time to dig any further into this, ie. full dark mode support. > On Aug 13, 2020, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Date: Wed, 12 Aug 2020 18:43:05 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: "Scott R. Looney" <scottrlooney(a)gmail.com <mailto:scottrlooney@gmail.com>>, Pd-List > <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] 0.51-1-test1 issues > Message-ID: > <CAEAsFmiJv-JYDZw4XX47gL8J0_RZWxinXw_4vuZJ2pwXzv_WiA(a)mail.gmail.com <mailto:CAEAsFmiJv-JYDZw4XX47gL8J0_RZWxinXw_4vuZJ2pwXzv_WiA@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Hi, I think we should address this in the pd list, I mean it as a request > for the feature to be available out of the box ;) hence I'm replying and > bringing this back to the list. > > Anyway, here's Scott's message > > Em qua., 12 de ago. de 2020 às 18:33, Scott R. Looney < > scottrlooney(a)gmail.com <mailto:scottrlooney@gmail.com>> escreveu: > >> hey Alex saw your comment on dark mode - regarding dark mode as far as i >> know it's a pretty easy fix to change the default Tcl/Tk BG color . hit up >> Mike (Fress Prench) on Discord for details. here's the relevant info from >> his post: >> >> *"Add this to the end of your pd-gui.tcl file >> (Applications/Pd/Contents/Resources/tcl) option add >> *PatchWindow*Canvas.background #ffe5b5"* >> >> best, >> scott >> >> On Wed, Aug 12, 2020 at 2:22 PM Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> >> wrote: >> >>> btw, having dark mode working on macos and other systems would be >>> wonderful for owls like me who spent the night patching :) >>> >>> Em qua., 12 de ago. de 2020 às 18:13, ffdd cchh <camarafede(a)gmail.com <mailto:camarafede@gmail.com>> >>> escreveu: >>> >>>> Hi Alex, et al, >>>> >>>> Some comments on colors in macos: >>>> I also see the greyish on the wish app (using Wish Tk 8.6.10 compiled or >>>> from software.html). That is while you have the Light Appearance enabled. >>>> Try switching your mac to Dark Appearance on your System Preferences, and >>>> you'll note that the greyish turns blackish (!). Most concerning: while >>>> cords and object boxes are bright, everything else is almost invisible. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 5

deken re-detects platform on rpi4
by Andrew Lyons 13 Aug '20

13 Aug '20

Hi, I'm setting up a raspberry pi4 for pd and various midi inputs, and I'm noticing the following lines in the console after startup: Loading plugin: /usr/lib/puredata/tcl/pd_deken.tcl [deken] Platform detected: Linux-armv7l-float32 Loading plugin: /usr/lib/puredata/tcl/pd_docsdir.tcl [deken] Platform detected: Linux-armv6-float32 The pi4 is armv7l - but in deken preferences the default platform is listed as Linux-armv6-float32, so unless I setup a User-defined platform and set it to Linux-armv7l-float32 I cannot see builds of certain libraries. Is this a known problem? ============================================= Andrew D Lyons | Tools Developer | http://www.tstex.com =============================================

4 4

Re: [PD] no midi input
by Dan Wilcox 13 Aug '20

13 Aug '20

Howdy Paul, Here is a quick response without knowing your background or experience with Pd/MIDI/Linux... 1. Do you have Pd's MIDI input enabled? I don't see one listed, just the "Pure Data Midi-Out 1" 2. Are you connecting devices? By default, aconnect doesn't connect anything automatically. I did a quick search and found this which may be helpful if you are not familiar with aconnect or aconnect-gui: https://howchoo.com/g/zmm2zdi3ody/raspberry-pi-midi-keyboard-synthesizer#co… <https://howchoo.com/g/zmm2zdi3ody/raspberry-pi-midi-keyboard-synthesizer#co…> If you use aconnect-gui, basically just connect you devices output to Pd's input. > On Aug 13, 2020, at 2:51 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Thu, 13 Aug 2020 13:27:24 +0200 > From: Paul Pignon <paulspignon(a)gmail.com <mailto:paulspignon@gmail.com>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: [PD] no midi input > Message-ID: <1694f7ee-de4f-702a-eaf3-91ad9302acfb(a)gmail.com <mailto:1694f7ee-de4f-702a-eaf3-91ad9302acfb@gmail.com>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I'm running pd-l2ork/purr-data > > > I cannot get any midi input, probably due to a woeful lack of > skill/knowledge. > aconnect -i > client 0: 'System' [type=kernel] > 0 'Timer ' > 1 'Announce ' > client 14: 'Midi Through' [type=kernel] > 0 'Midi Through Port-0' > client 16: 'Mbox 2' [type=kernel,card=0] > 0 'Mbox 2 MIDI 1 ' > client 20: 'USB Midi Controller' [type=kernel,card=1] > 0 'USB Midi Controller MIDI 1' > client 32: 'MidiSport 2x2' [type=kernel,card=4] > 0 'MidiSport 2x2 MIDI 1' > 1 'MidiSport 2x2 MIDI 2' > client 128: 'Pure Data' [type=user,pid=22170] > 3 'Pure Data Midi-Out 1' > > aseqdump -p 32 > shows a well-behaved midi data stream from my WX5. > testone.pd however shows no midi input from any device. > > Can anyone help me to get that midi data into my patches? > > Best regards, > > /Paul > > -- > Paul [Stephen] Pignon > The DP Works HB > Södra Jordbrovägen 177/II > 13762 Jordbro > Sweden > +46 729311141,[+46 705508655] -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 5

no midi input
by Paul Pignon 13 Aug '20

13 Aug '20

I'm running pd-l2ork/purr-data I cannot get any midi input, probably due to a woeful lack of skill/knowledge. aconnect -i client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce ' client 14: 'Midi Through' [type=kernel] 0 'Midi Through Port-0' client 16: 'Mbox 2' [type=kernel,card=0] 0 'Mbox 2 MIDI 1 ' client 20: 'USB Midi Controller' [type=kernel,card=1] 0 'USB Midi Controller MIDI 1' client 32: 'MidiSport 2x2' [type=kernel,card=4] 0 'MidiSport 2x2 MIDI 1' 1 'MidiSport 2x2 MIDI 2' client 128: 'Pure Data' [type=user,pid=22170] 3 'Pure Data Midi-Out 1' aseqdump -p 32 shows a well-behaved midi data stream from my WX5. testone.pd however shows no midi input from any device. Can anyone help me to get that midi data into my patches? Best regards, /Paul -- Paul [Stephen] Pignon The DP Works HB Södra Jordbrovägen 177/II 13762 Jordbro Sweden +46 729311141,[+46 705508655]

1 0

soundfiler read with offset?
by tim vets 13 Aug '20

13 Aug '20

Is there a possibility with [soundfiler] to load a sound file into a table at an offset? Say I want to load one sound into the first half of a table and a different one into the second half...? Thank you! Tim

2 1

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