Pd-dev September 2019

pd-dev@lists.iem.at

12 participants
13 discussions

Doppler effect implementation
by Frodo Jedi 01 May '22

01 May '22

Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested? Cheers FJ

9 15

pd compiled for web with emscripten
by Claude Heiland-Allen 26 Nov '19

26 Nov '19

Hi! As a proof of concept I modified pure-data and libpd just enough to get it to compile with Emscripten and run some patches: https://mathr.co.uk/empd/ Only -nogui mode. You can make GUIs using SDL2 and OpenGL, or using other web APIs (HTML forms, SVG, etc). Performance (provided you compile in Release mode) is about 2x worse than native in one of my tests. Changes were mainly annoying rather than hard: - Emscripten is stricter about calling function pointers with the correct type, this means pd_typedmess explodes from 6 cases to 60. - I also needed to special-case pd_objectmaker in more places, because its methods have return values other than void. - These type errors are only visible at runtime, so I may have missed some - please report. Some other smaller fixes I may make pull-requests for soon. Claude -- https://mathr.co.uk

3 3

networking updates
by Dan Wilcox 11 Oct '19

11 Oct '19

Howdy all, Christoph and I have more or less finished some work that updates Pd's networking and also fixes some bugs and a couple pain points: * IPv6 support * multicast * netsend: optional from hostname & port outlet * netsend: connectionless UDP, no more connection refused (fire & forget without having to manually reconnect) * netreceive: settable timeout which defaults to 10 seconds (no more super-long frozen Pd) * improved error printing with netsend and netrceive Find Last Error support * various small bug fixes (no more polling errors after socket is closed) The pdsend & pdreceive utils are similarly updated. The discussion & pull request on Github: https://github.com/pure-data/pure-data/pull/577 <https://github.com/pure-data/pure-data/pull/577> If you can build Pd and want to try this out, the branch is called feature/netobject-updates The overall approach taken is to keep IPv4 as default and detect IPv6 addresses so this should not affect existing patches. The IP version handling should also degrade gracefully based if IPv6 is not available. An added bonus is hostnames now resolve (ie. google.com <http://google.com/>) and you can also listen on a hostname if your system can grab it (ie. computername.local). One current limitation is that Tcl 8.5 does not have IPv6 support, so the core communication with the GUI remains IPv4. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

4 5

Re: [PD-dev] First complete keyboard navigation prototype
by Dan Wilcox 10 Oct '19

10 Oct '19

*Not really feedback, but just a general response.* One thing I would suggest would be to make this an optional feature in some way. Maybe we can work together with IOhannes and Christof to propose changes to the Pd sources to allow for adding in this kind of functionality without *requiring* it to be built into the core itself. I have been thinking of these kinds of approaches since I see this being a greta feature for the GUI but basically unused for something like libpd. In the latter case, I'd like to simply not compile it and the easiest way would if the main functionality is in a separate set of files that can be left out. This might be a process that has to happen later on, but something to think of for now in order to balance the addition of new features while maintaining the possibility for a fast, slim core. > On Jun 10, 2019, at 10:30 AM, pd-dev-request(a)lists.iem.at wrote: > > Date: Sun, 9 Jun 2019 19:16:36 +0000 > From: Henri Augusto Bisognini <msndohenri(a)hotmail.com <mailto:msndohenri@hotmail.com>> > To: "pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>" <pd-dev(a)lists.iem.at <mailto:pd-dev@lists.iem.at>> > Subject: Re: [PD-dev] First complete keyboard navigation prototype > Message-ID: > <CP2PR80MB0386C0D2C66D1CE34F458BE3CC120(a)CP2PR80MB0386.lamprd80.prod.outlook.com <mailto:CP2PR80MB0386C0D2C66D1CE34F458BE3CC120@CP2PR80MB0386.lamprd80.prod.outlook.com>> > > Content-Type: text/plain; charset="iso-8859-1" > > Thanks Christof! Indeed it's already been very nice to use it during my tests. > > I'l probably wrap up a small file containing some basic infos about how everything works to make it easier for more people to modify the code and test ideas. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 10

Re: [PD-dev] Naming of patch when doing a "save as"
by Dan Wilcox 19 Sep '19

19 Sep '19

> Am 15. September 2019 19:46:10 MESZ schrieb jakob skouborg <syntaxerror60(a)hotmail.com <mailto:syntaxerror60@hotmail.com>>: >> >> What are your thoughts about this? >> > > to be honest, i didnt even notice. > usually, if i "save as" any suggested filename is wrong. One reason this was changed, I believe, is that some people were accidentally overwriting there patches when they forgot to change the original name. When you don't want to change the name, you'd use "Save" or at least that makes sense to me. > the only suggestion i think "wrongest" would be "Copy of <orgname>.pd" Hah, most macOS apps now make a "duplicate" named "<orgname> copy". -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 8

Re: [PD-dev] Naming of patch when doing a "save as"
by Dan Wilcox 19 Sep '19

19 Sep '19

I think that the actual answer is: there is no rationale, it's a bug. I can't think of anything else, other than the possible reason I came upon with earlier which was pointed out as wrong anyway. It might have been something introduced when we were doing some updates to the Pd GUI. If I find anything more, I will respond to the Github issue. > On Sep 18, 2019, at 9:26 PM, pd-dev-request(a)lists.iem.at wrote: > > Anyway, I am just curious about that the rationale is for starting from “untitled”, > instead of last saved name? Cause to me it doesn’t make sense at all. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

Re: [PD-dev] [PD] Naming of patch when doing a "save as"
by jakob skouborg 18 Sep '19

18 Sep '19

Done! Thank you for the hint, Antoine ;) Jakob https://github.com/pure-data/pure-data/issues/746 On 18 Sep 2019, at 20:47, Antoine Rousseau <antoine(a)metalu.net<mailto:antoine@metalu.net>> wrote: Regarding the bug report, you can just fill a new issue in the github repo: https://github.com/pure-data/pure-data Antoine Le mer. 18 sept. 2019 à 19:57, jakob skouborg <syntaxerror60(a)hotmail.com<mailto:syntaxerror60@hotmail.com>> a écrit : > I have to agree - I'm used to having the "save as" start up with the existing > filename, with the text selected so that you can just type in a new one from > scratch, or hit the right-arrow to just edit the last letter or digit of the > name. Yes, to me that makes the most sense too, rather than starting from “untitled”. >> I hope we all agree on that :-) "save as" should start at the current file name, that's the convention and IMO there's absolutely no reason for doing it differently. As people have already noted, the "save as" dialog will already warn you when you try to overwrite an existing file. >> >> I would do a PR but I'm busy right now. You might file a bug report, so we don't forget. >> >> Christof Thanks, I will do the bug report. I actually already did that long time ago, but it was closed it pretty much right away. I don’t remember how to do the bug report, but I will find out again and do it ASAP. Thanks for the understanding and have a great day! Jakob > On 18 Sep 2019, at 19:54, Miller Puckette <msp(a)ucsd.edu<mailto:msp@ucsd.edu>> wrote: > > I have to agree - I'm used to having the "save as" start up with the existing > filename, with the text selected so that you can just type in a new one from > scratch, or hit the right-arrow to just edit the last letter or digit of the > name. > > Git's cool, but when I'm working with others the name+number convention > often helps a lot. > > cheers > Miller > > On Wed, Sep 18, 2019 at 07:50:36PM +0200, Christof Ressi wrote: >>> Cause to me it doesn???t make sense at all. >> >> I hope we all agree on that :-) "save as" should start at the current file name, that's the convention and IMO there's absolutely no reason for doing it differently. As people have already noted, the "save as" dialog will already warn you when you try to overwrite an existing file. >> >> I would do a PR but I'm busy right now. You might file a bug report, so we don't forget. >> >> Christof >> >>> Gesendet: Mittwoch, 18. September 2019 um 19:26 Uhr >>> Von: "jakob skouborg" <syntaxerror60(a)hotmail.com<mailto:syntaxerror60@hotmail.com>> >>> An: "IOhannes m zmoelnig" <zmoelnig(a)iem.at<mailto:zmoelnig@iem.at>> >>> Cc: "Pd-dev(a)lists.iem.at<mailto:Pd-dev@lists.iem.at>" <Pd-dev(a)lists.iem.at<mailto:Pd-dev@lists.iem.at>> >>> Betreff: Re: [PD-dev] Naming of patch when doing a "save as" >>> >>> >>> >>> >>>> the days of "Copy of Copy of Kopie von Comb filter 1.2 (17.12.1997) >>>> final copy.pd" ought to be gone for good. >>> >>> That is not what what I am saying or expecting. >>> >>> It is really very simple, just start from the name of last time the patch was saved, >>> like basically any other app in the world does today. Then anyone can write what >>> they want from there. >>> >>> >>>> if you want to do versioning of patches, you probably should look into a >>>> proper version-control-system, like 'git'. >>>> seriously. >>> >>> >>> I think that is overcomplicating the "save as" function a little bit. >>> >>> >>>> and while i still don't have much of an opinion about the suggested >>>> filename, i think that the suggestion shouldn't contain spaces at all >>>> (alternatively you find a simple way to load abstractions with spaces in >>>> their name). >>> >>> >>> The name heres was just an example. >>> >>> Of course I call abstractions something else, without spaces. >>> >>> I am talking about main/master patches. All though you can still call them ???Patchname1???, etc. >>> >>> Anyway, I am just curious about that the rationale is for starting from ???untitled???, >>> instead of last saved name? Cause to me it doesn???t make sense at all. >>> >>> Cheers! >>> >>> >>> >>>> On 17 Sep 2019, at 10:00, IOhannes m zmoelnig <zmoelnig(a)iem.at<mailto:zmoelnig@iem.at>> wrote: >>>> >>>> On 16.09.19 18:05, jakob skouborg wrote: >>>>> >>>>> I often do a lot of versioning when making complex patches, to avoid >>>>> ruining them. So most of my patches have numbers included. >>>>> >>>>> Like for example "Comb filter 1.0??? >>>> >>>> ah yes, *that* use-case. >>>> >>>> if you want to do versioning of patches, you probably should look into a >>>> proper version-control-system, like 'git'. >>>> seriously. >>>> the days of "Copy of Copy of Kopie von Comb filter 1.2 (17.12.1997) >>>> final copy.pd" ought to be gone for good. >>>> >>>> >>>> and while i still don't have much of an opinion about the suggested >>>> filename, i think that the suggestion shouldn't contain spaces at all >>>> (alternatively you find a simple way to load abstractions with spaces in >>>> their name). >>>> >>>> gmasdr >>>> IOhannes >>>> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev(a)lists.iem.at<mailto:Pd-dev@lists.iem.at> >>>> https://lists.puredata.info/listinfo/pd-dev >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev(a)lists.iem.at<mailto:Pd-dev@lists.iem.at> >>> https://lists.puredata.info/listinfo/pd-dev >>> >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at<mailto:Pd-list@lists.iem.at> mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-dev mailing list Pd-dev(a)lists.iem.at<mailto:Pd-dev@lists.iem.at> https://lists.puredata.info/listinfo/pd-dev

1 0

Re: [PD-dev] [PD] Naming of patch when doing a "save as"
by jakob skouborg 18 Sep '19

18 Sep '19

> I have to agree - I'm used to having the "save as" start up with the existing > filename, with the text selected so that you can just type in a new one from > scratch, or hit the right-arrow to just edit the last letter or digit of the > name. Yes, to me that makes the most sense too, rather than starting from “untitled”. >> I hope we all agree on that :-) "save as" should start at the current file name, that's the convention and IMO there's absolutely no reason for doing it differently. As people have already noted, the "save as" dialog will already warn you when you try to overwrite an existing file. >> >> I would do a PR but I'm busy right now. You might file a bug report, so we don't forget. >> >> Christof Thanks, I will do the bug report. I actually already did that long time ago, but it was closed it pretty much right away. I don’t remember how to do the bug report, but I will find out again and do it ASAP. Thanks for the understanding and have a great day! Jakob > On 18 Sep 2019, at 19:54, Miller Puckette <msp(a)ucsd.edu> wrote: > > I have to agree - I'm used to having the "save as" start up with the existing > filename, with the text selected so that you can just type in a new one from > scratch, or hit the right-arrow to just edit the last letter or digit of the > name. > > Git's cool, but when I'm working with others the name+number convention > often helps a lot. > > cheers > Miller > > On Wed, Sep 18, 2019 at 07:50:36PM +0200, Christof Ressi wrote: >>> Cause to me it doesn???t make sense at all. >> >> I hope we all agree on that :-) "save as" should start at the current file name, that's the convention and IMO there's absolutely no reason for doing it differently. As people have already noted, the "save as" dialog will already warn you when you try to overwrite an existing file. >> >> I would do a PR but I'm busy right now. You might file a bug report, so we don't forget. >> >> Christof >> >>> Gesendet: Mittwoch, 18. September 2019 um 19:26 Uhr >>> Von: "jakob skouborg" <syntaxerror60(a)hotmail.com> >>> An: "IOhannes m zmoelnig" <zmoelnig(a)iem.at> >>> Cc: "Pd-dev(a)lists.iem.at" <Pd-dev(a)lists.iem.at> >>> Betreff: Re: [PD-dev] Naming of patch when doing a "save as" >>> >>> >>> >>> >>>> the days of "Copy of Copy of Kopie von Comb filter 1.2 (17.12.1997) >>>> final copy.pd" ought to be gone for good. >>> >>> That is not what what I am saying or expecting. >>> >>> It is really very simple, just start from the name of last time the patch was saved, >>> like basically any other app in the world does today. Then anyone can write what >>> they want from there. >>> >>> >>>> if you want to do versioning of patches, you probably should look into a >>>> proper version-control-system, like 'git'. >>>> seriously. >>> >>> >>> I think that is overcomplicating the "save as" function a little bit. >>> >>> >>>> and while i still don't have much of an opinion about the suggested >>>> filename, i think that the suggestion shouldn't contain spaces at all >>>> (alternatively you find a simple way to load abstractions with spaces in >>>> their name). >>> >>> >>> The name heres was just an example. >>> >>> Of course I call abstractions something else, without spaces. >>> >>> I am talking about main/master patches. All though you can still call them ???Patchname1???, etc. >>> >>> Anyway, I am just curious about that the rationale is for starting from ???untitled???, >>> instead of last saved name? Cause to me it doesn???t make sense at all. >>> >>> Cheers! >>> >>> >>> >>>> On 17 Sep 2019, at 10:00, IOhannes m zmoelnig <zmoelnig(a)iem.at> wrote: >>>> >>>> On 16.09.19 18:05, jakob skouborg wrote: >>>>> >>>>> I often do a lot of versioning when making complex patches, to avoid >>>>> ruining them. So most of my patches have numbers included. >>>>> >>>>> Like for example "Comb filter 1.0??? >>>> >>>> ah yes, *that* use-case. >>>> >>>> if you want to do versioning of patches, you probably should look into a >>>> proper version-control-system, like 'git'. >>>> seriously. >>>> the days of "Copy of Copy of Kopie von Comb filter 1.2 (17.12.1997) >>>> final copy.pd" ought to be gone for good. >>>> >>>> >>>> and while i still don't have much of an opinion about the suggested >>>> filename, i think that the suggestion shouldn't contain spaces at all >>>> (alternatively you find a simple way to load abstractions with spaces in >>>> their name). >>>> >>>> gmasdr >>>> IOhannes >>>> >>>> _______________________________________________ >>>> Pd-dev mailing list >>>> Pd-dev(a)lists.iem.at >>>> https://lists.puredata.info/listinfo/pd-dev >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev(a)lists.iem.at >>> https://lists.puredata.info/listinfo/pd-dev >>> >> >> >> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

1 0

Naming of patch when doing a "save as"
by jakob skouborg 16 Sep '19

16 Sep '19

Hello developers :) I have been thinking about this since PD was upgraded from version 0.47 and thought I’d swing it by the developer mailing list here: In 0.47 and down, when you did a “save as”, you started with the last saved name of the patch. So in 0.47, if you push "save as” you would for example start from “Comb Filter 1.0”, if that was the last name you save to the patch. In 0.48 and up, this has been changed to when you do a save as, it always starts from “untitled”, no matter what the patch was saved as, last time it was saved. To me the “save as” behaviour in 0.47 and down, seems to be the correct behaviour, as pretty much all other apps behaves like that. I did make a video that show it here, if my explanation wasn’t clear: https://www.youtube.com/watch?v=lv3a83yzmJc What are your thoughts about this? Best wishes, Jakob

3 2

Re: [PD-dev] dynamic patching - is iemguts the way to go?
by Nick Porcaro 13 Sep '19

13 Sep '19

Hi Miller- > On Aug 20, 2019, at 7:08 PM, Miller Puckette <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> wrote: > > actually I wrote that before I thought the whole thing out :) > > No, if you "tick" a pdlib instance you tick all the patches in it - so teh > way to get different patches in different orders is to call up a separate > Pd instance for each of them, and use "adc~" and "dac~" objects to get > audio in and out - that incurs zero latency (once you've buffered 64 > samples in the first place). I tried this two ways: - Create separate Pd instances for each patch wrapped in adc~ and dac~ - Use a single Pd instance with multiple patches, with each patch wrapped in adc~ and dac~ Then I have a simple JUCE app (based on the sampler example) that drives these pd patches. There is no problem with doing switch~ and such, but I am getting distortion that seems like clipping in both cases (one pd instance with many patches or multiple pd instances with one patch) To be more clear these wrapper patches are like: Patch 1: [adc~] -> [lop~ 200] -> [dac~] Patch 2: [adc~] -> [hip~ 200] -> [dac~] These wrapper patches also have a loadbang to pd dsp 1; Then the code that calls these patches does something like this calling libpd: for (each buffer from the audio callback) { for (a smaller buffer that’s the pd block size (eg 64)) { pd->processFloat (oneTick, smallBufferIn, smallBufferOut); } } I tried scaling the input and output to these wrapper patches after the adc~ and before the dac~ and that does not solve the distortion/clipping problem either. There are a couple of more things I can try: - make the wrapper patches even simpler, just scaling instead of the filters. - dump the samples to a file and maybe that will shed some light on the problem. - making a much simpler example program that I can share will you all. I have libpd and pd source directly compiled into my example Any other ideas would be greatly appreciated! > > OR, within one pd instance, in libpd or in Pd, you can use switch~ objects, > switched off, to control each sub-patch. Send the switch~ objects bangs in > whatever orders you wish. In this scenario, tabsend~ and tabreceive~ would > be the simplemt way to pass signals between them. In libpd you can do this > zero-latency (just stuff your inpuits into arrays before sending all the > tick messages and copy the results out afterward). This approach works well, but the problem is I can’t insert non-Pd signal processing anywhere I’d like in the Pd patch so that’s why I went with the first approach. > > Within the Pd app, you can do teh same thing but you incur one tick extra > latency, because copying the autio into the tables has to happen on the > previous tick form the one on which you get the outputs back. > > If you like danger, you can write an external tilde object that, for its > "dsp" action, sends a message to teh patch that can "tick" the switch~ > objects right in the middle of Pd/s DSP tick. This is not part of Pd > because it could cause major confusion if general-purpose Pd messages > got sent around in mid-tick. > > cheers > Miller > > On Tue, Aug 20, 2019 at 11:55:58PM +0200, Roman Haefeli wrote: >> On Tue, 2019-08-20 at 12:09 -0700, Miller Puckette wrote: >>> I think the way to do this in libpd is to open them all as separate >>> patches >>> within one instance of Pd (so that symbols are shared) and use >>> "tabsend" >>> and "tabreceive" to route signals to/from them, using shared names >>> like >>> "channel1" as both inputs and outputs so you can rearrange them in >>> any >>> order. >>> >>> (Beware of allowing patches to _write_ andy of their output channels >>> before >>> reading all the input channels, if you're re-using the same channels >>> as >>> inputs and outputs :) >> >> Do I understand right: When loading them as separate patches, you can >> dynamically re-order the signal flow by using [tabsend~]/[tabreceive~] >> (which you could with abstractions, too) _without_ adding latency? >> >> And: When changing the symbol of [tabsend~] or [tabreceive~], is the >> DSP graph re-calculated? >> >> Roman > > > >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> >> https://lists.puredata.info/listinfo/pd-dev > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at <mailto:Pd-dev@lists.iem.at> > https://lists.puredata.info/listinfo/pd-dev > >

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev September 2019