Pd-list March 2022

pd-list@lists.iem.at

32 participants
56 discussions

M1 Externals
by me.grimm 21 Mar '22

21 Mar '22

hello, my old mac dead so had to get new M1 and starting from scratch. I see only a few externals so far compiled for the Darwin-amd64-32 looking for the [comport] to give compiling a whirl i see v 0.2 from 2012 here: https://puredata.info/downloads/comport that's the most recent repo? just checking in case im missing something. btw also running dans build and seems to work well. the build from millers site never gave me a Pd window. m -- ____________________ m.e.grimm, m.f.a, ed.m. cornell u., tc3 megrimm.net ____________________

4 6

Re: [PD] M1 Externals
by Philip Stone 21 Mar '22

21 Mar '22

>anyhow: this time, your lobbying defeated space and time and > comport_v1.2 is already available on deken. >fnase >IOhannes Thank you, IOhannes! Phil

1 0

Re: [PD] Pd-list Digest, Vol 204, Issue 29
by Philip Stone 21 Mar '22

21 Mar '22

I finally took the plunge (don’t know why I’ve never done this before) and figured out how to compile an external, trying ‘comport’ for arm64 to start with, and got the same result as me.grimm. XCode version is 13.3 if that matters, but I called make directly from the shell. Sorry for my ignorance on the compiling aspect, but I do wish to learn, now that I have some time. Phil * *comport.c:693:9: **error: **implicit declaration of function 'error' is invalid in C99 [-Werror,-Wimplicit-function-declaration]* error("[comport]: %ld not valid, using closest value: %ld", *baud, baudratetable[i]); * ^* changed "error" to "pd_error" and compiles and loads. lots of warnings though. forked here: https://github.com/megrimm/pd-comport m

2 1

Re: [PD] M1 Externals
by Philip Stone 20 Mar '22

20 Mar '22

Hi, I’m going through the same process; it has spurred me to cut my dependence on externals to the bone, but I also badly need [comport], cyclone, and a few others that I can’t replace, like [tof/pmenu]. I’d like to help in this process of getting externals compiled for Darwin-arm64, but don’t know where to start. Best, Phil Stone University of California, Davis me.grimm writes: Date: Fri, 18 Mar 2022 18:04:52 -0400 From: "me.grimm" <megrimm(a)gmail.com> To: Pd-List <pd-list(a)lists.iem.at> Subject: [PD] M1 Externals Message-ID: <CACE5Q17bx4FJRUV79ykcUNU+n8tPvaaB8YJ9V09bzJocribmng(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" hello, my old mac dead so had to get new M1 and starting from scratch. I see only a few externals so far compiled for the Darwin-amd64-32 looking for the [comport] to give compiling a whirl i see v 0.2 from 2012 here: https://puredata.info/downloads/comport that's the most recent repo? just checking in case im missing something. btw also running dans build and seems to work well. the build from millers site never gave me a Pd window. m -- ____________________ m.e.grimm, m.f.a, ed.m. cornell u., tc3 megrimm.net ____________________

1 0

Silicon Mac issues
by Philip Stone 18 Mar '22

18 Mar '22

Hello all, I’m moving to an M1 MacBook and trying to get my Pd system configured. I’ve installed 0.52-1.really, copied my libraries and patches, set my paths, and can actually load and get sound out of one of my synth objects. However, when I try to load my (large) configuration, Pd quits immediately. 1. Is there any way to collect more error diagnostics – which startup flag(s) might be useful here? 2. I may have botched an earlier install – how do I insure there are no lingering (bad) settings from it? I worry that some system security setting is silently failing me. If anybody has had similar experience with a Silicon Mac, please chime in. Thanks very much. Phil Stone University of California, Davis Davis, CA. USA

1 2

Re: [PD] whats the '-ascii' flag in [pd~] for?
by Dan Wilcox 18 Mar '22

18 Mar '22

It looks like a bool which seems to control whether message passing is via binbuf or string: https://github.com/pure-data/pure-data/blob/master/extra/pd~/pd~.c#L458 <https://github.com/pure-data/pure-data/blob/master/extra/pd~/pd~.c#L458> > On Mar 2, 2022, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 1 > Date: Tue, 1 Mar 2022 17:37:49 -0300 > From: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>> > To: Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: [PD] whats the '-ascii' flag in [pd~] for? > Message-ID: > <CAEAsFmjCYBHghJj54dtCaoTS9m7Yk=HbLffPZmi42SMjVkmYxw(a)mail.gmail.com <mailto:CAEAsFmjCYBHghJj54dtCaoTS9m7Yk=HbLffPZmi42SMjVkmYxw@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Here's another one, there's an undocumented '-ascii' flag in [pd~] we need > to document. > > see https://github.com/pure-data/pure-data/blob/master/extra/pd~/pd~.c#L1136 <https://github.com/pure-data/pure-data/blob/master/extra/pd~/pd~.c#L1136> > > cheers -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

3 2

Re: [PD] should 'flags' always come first?
by Dan Wilcox 18 Mar '22

18 Mar '22

My take is that this is more or less how most unix commands work: some require specific ordering of "flags" before "arguments" while other don't. That's not based on "enforcing" or "eschewing" convention but more on personal style and/or age of the tool. I suppose if you wanted, you could open an issue with each and every unix tool, but it's simpler to use the order which works for both in documentation and not worry much beyond that: flags before arguments. I say this also follows for Pd objects and I don't see sigmund's handling as a bug or anything that needs to be changed. In fact, you are likely to break people's patches if you make it have a new, strict handling. It follows that you would then need to push for 3rd0party externals to have similar behavior or things would be "confusing" if such behavior is mandated in all the documentation. I saw just document it as such but *without* writing a pedantic list of rules. > On Mar 1, 2022, at 6:43 AM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Mon, 28 Feb 2022 18:13:50 +0100 > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] should 'flags' always come first? > Message-ID: <6e75e36e-14ef-0793-6e9f-4b1b1cbfe6fc(a)iem.at <mailto:6e75e36e-14ef-0793-6e9f-4b1b1cbfe6fc@iem.at>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 2/28/22 17:47, Alexandre Torres Porres wrote: >> I know, that's because they should come first! This is why I think it's >> confusing that sigmund~ doesn't complain and it just works... > > i doubt that it is confusing. > but: if you do find it confusing, just put the flags at the beginning. > > it's not like Pd is *forcing* you to put the sigmund~ flags at the end, > and the flags for all other objects at the beginning. (*that* would be > an inconsistency, and deserve some attention). > > it's not even documented, that you can put the flags at the end. > and i agree with christof, that there's no benefit in documenting that > you can put them at the end. > > so just forget it, and the source for the confusion will be gone. > > >> >> [netreceive -u 5000] will listen to port 5000 and will use udp protocol, >>> but >>> [netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is >>> ignored in this case... >>> >> yup, wrong order, so it gets ignored, but a warning should be given >> that the order is wrong, so it's ignored! >> > > i agree that a warning should be given if there are any ignored (and > probably also: unknown) arguments (for objects with a complex invocation). > > > in general i think: > it is confusing if things don't work. > it isn't confusing if things do work. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] [SPAM] Re: [SPAM] Re: Choices of IPC when using fast-forward
by cyrille henry 17 Mar '22

17 Mar '22

Hello Le 17/03/2022 à 10:05, Lucas Cordiviola a écrit : > > On 17/03/2022 05:55, cyrille henry wrote: >> I did not find any binary on deken so I don't know where they are! > > > On Deken's preferences un-tick "Hide foreign architectures" thanks! so, V1.0 is on deken for darwin, linux and windows, all of them for 32 and 64 bit. to correct my last mail : Latest source are on my github : https://github.com/ch-nry/pd_shmem but they don't compile for windows. that's probably why I never made a version 1.1. cheers C > > It will show the Windows version. > > > -- > > Mensaje telepatico asistido por maquinas. > > .

2 1

phasor~ phase reset detection
by Jeppi Jeppi 17 Mar '22

17 Mar '22

Hi there, I assume this has been discussed many times before but...what could be simplest and most concise way to detect a phase reset of a phasor~ with only plain vanilla objects? I only need one bang when it goes back to 0. It seems I should need snapshot~ and fexpr~ which is not that elegant...

4 3

Re: phasor~ phase reset detection
by Samuel Burt 17 Mar '22

17 Mar '22

Here's how I like to do it these days: [phasor~] | [expr~ $v1 < 0.5] | [snapshot~] (with [bang~] | [change] | [sel 1] | BANG! If you need it to be sample accurate, you can set [block~ 1]. Even better if you can keep it all in the signal domain and skip the [snapshot~], but it depends on your purpose. Sam > Content-Type: text/plain; charset="iso-8859-1" > > Hi there, > I assume this has been discussed many times before but...what could be > simplest and most concise way to detect a phase reset of a phasor~ with > only plain vanilla objects? > I only need one bang when it goes back to 0. > It seems I should need snapshot~ and fexpr~ which is not that elegant... >

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 March 2022