Pd-dev

pd-dev@lists.iem.at

2 participants
9620 discussions

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

Re: [PD-dev] Binaural spatialisation in PD (Claude Heiland-Allen)
by Julián Villegas 10 Sep '19

10 Sep '19

Hi Frodo, you could try [hrir~], an external that I created based on Qu’s HRIR database. Besides the traditional azimuth and elevation, this database has recordings at distances between 20 and 160 cm, so you could truly spatialize sounds, not limited to the surface of a sphere as in the case of other databases. Here’s the link: http://onkyo.u-aizu.ac.jp/software/hrir/ Cheers, Julian. > On Sep 9, 2019, at 19:00 PM, pd-dev-request(a)lists.iem.at wrote: > > Send Pd-dev mailing list submissions to > pd-dev(a)lists.iem.at > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.puredata.info/listinfo/pd-dev > or, via email, send a message with subject or body 'help' to > pd-dev-request(a)lists.iem.at > > You can reach the person managing the list at > pd-dev-owner(a)lists.iem.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pd-dev digest..." > > > Today's Topics: > > 1. Binaural spatialisation in PD (Frodo Jedi) > 2. Re: Binaural spatialisation in PD (Claude Heiland-Allen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 8 Sep 2019 15:26:31 +0200 > From: Frodo Jedi <frodojedi.mailinglist(a)gmail.com> > To: pd-dev <pd-dev(a)lists.iem.at> > Subject: [PD-dev] Binaural spatialisation in PD > Message-ID: > <CAGkY2uoo0gj3aHYrNWvO0SGgM+=LGnYC8ETMsdScO5RYPWPu_A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > I am searching for an object for binaural spatialisation in PD. > If I am not wrong the state of the art in PD is cw_binaural~. Am I right? > All the other objects I tried do not seem to work well, i.e., earplug~, or > soundhack/+binaural~ > > Do you have any suggestions for other objects? > > Cheers > > FJ >

1 0

Binaural spatialisation in PD
by Frodo Jedi 08 Sep '19

08 Sep '19

Hi all, I am searching for an object for binaural spatialisation in PD. If I am not wrong the state of the art in PD is cw_binaural~. Am I right? All the other objects I tried do not seem to work well, i.e., earplug~, or soundhack/+binaural~ Do you have any suggestions for other objects? Cheers FJ

2 1

PD Compile Farm
by Jonathan Moore 02 Sep '19

02 Sep '19

Hi, I would like too know how to start my own PD Compile Farm I have a dedicated machine and am Running Ubuntu. Thanks, jdm7dv

2 1

Re: [PD-dev] Why don't we implement zooming in Tcl?
by Christof Ressi 27 Aug '19

27 Aug '19

> Maybe I'm missing something obvious? Of course I did... We send raw Tcl commands from the core with the actual canvas coordinates and this complicates things because of how Tk's "scale" method works... Maybe it's time to eventually refactor the GUI messaging and use abstract commands instead of actual Tcl code, with logical coordinates instead of actual coordinates... This would mean that zooming could be implemented easily on the GUI side. But what's more important: people can replace the Tk GUI with other (better) GUIs. I think the libpd people would love that as well, because apps could easily integrate Pd's GUI into their GUI framework of choice. Also, people can offer alternative GUIs for Pd vanilla. Personally, I can imagine writing a Qt GUI. This would be similar to how Supercollider has alternative language clients which all talk to the Server via well-defined OSC messages. <rant> I appreciate Pd's minimalism but a simple GUI should also be a *fast* GUI. The Tk canvas implementation is actually pretty terrible performance-wise. Moving an object in a larger patch maxes out a whole core(!) on my Laptop. It appears that Tk simply redraws the whole canvas :-( Any decent GUI framework should use some kind of spatial partitioning to determine which part of the canvas actually needs to be redrawn. Qt's QGraphicsScene does this pretty well (I've written a level editor where the view can easily contain 10 thousands of tiles and editing/zooming is smooth!). So I'm pretty frustated with Tk. A short-term solution could be to patch Tk's canvas code, but in the long run I think we need an abstract GUI interface, so that people can experiment with better GUI frameworks. </rant> Christof > Gesendet: Dienstag, 27. August 2019 um 00:30 Uhr > Von: "Christof Ressi" <christof.ressi(a)gmx.at> > An: pd-dev(a)iem.at > Betreff: [PD-dev] Why don't we implement zooming in Tcl? > > Hi, I've been wondering why the zooming is implemented on the Pd core? Tk's canvas has a scale method and people have been using to implement a zoom feature, e.g. https://www.tek-tips.com/viewthread.cfm?qid=239833 > > Ideally, the core shouldn't have to know about the size of the GUI window at all and just work with "logical" coordinates. The GUI can scale the content to whatever size it wants and when communicating with the core it would transform the mouse coordinates between logical and screen coordinates. Some better GUI frameworks already do that for you (e.g. Qt's QGraphicsScene/QGraphicView), but it shouldn't be too hard to do it manually for Tk. This would also allow fractional zoom factors. Unfortunately, Tk doesn't allow fractional font sizes (or has this changed?), but we could have at least *some* steps between 100% and 200%. Also, it would make the Pd core code much easier because we wouldn't have to worry about zoom at all... > > This is just I've been wondering about when having a look at the zooming code and coming from my experience of developing GUI apps with Qt. Maybe I'm missing something obvious? > > Christof > > > > > _______________________________________________ > Pd-dev mailing list > Pd-dev(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-dev >

2 1

Why don't we implement zooming in Tcl?
by Christof Ressi 27 Aug '19

27 Aug '19

Hi, I've been wondering why the zooming is implemented on the Pd core? Tk's canvas has a scale method and people have been using to implement a zoom feature, e.g. https://www.tek-tips.com/viewthread.cfm?qid=239833 Ideally, the core shouldn't have to know about the size of the GUI window at all and just work with "logical" coordinates. The GUI can scale the content to whatever size it wants and when communicating with the core it would transform the mouse coordinates between logical and screen coordinates. Some better GUI frameworks already do that for you (e.g. Qt's QGraphicsScene/QGraphicView), but it shouldn't be too hard to do it manually for Tk. This would also allow fractional zoom factors. Unfortunately, Tk doesn't allow fractional font sizes (or has this changed?), but we could have at least *some* steps between 100% and 200%. Also, it would make the Pd core code much easier because we wouldn't have to worry about zoom at all... This is just I've been wondering about when having a look at the zooming code and coming from my experience of developing GUI apps with Qt. Maybe I'm missing something obvious? Christof

1 0

a new object/functionality similar to max's [if]
by Tsz Kiu Pang 24 Aug '19

24 Aug '19

Hi all, <porres(a)gmail.com> Alexandre has recently requested a new object/functionality similar to max's [if] on github: https://github.com/pure-data/pure-data/issues/663 So I was looking it for a while, and came up with a list of things that have to be modified/added in order to accommodate the new object, as discussed on github. I guess the main question is that I feel like this is quite a big change to the expr family since no class has been added to it for the past 19/20 years, so I am just wondering whether my approach (adding a new class to the [expr], [expr~], [fexpr~] mix) is correct, and whether this functionality is something that we need. I will probably put in a pull request soon if there is no objection... Kind regards, TK

5 8

Fwd: external help, please
by Alexandre Torres Porres 22 Aug '19

22 Aug '19

Hi folks, I need help on an external. I wanna perform a task on an array of signal inputs. It's a multichannel object, and I define the number of channels with an argument. Here's just the core of it, as an object named "mtx~", where I map the input to the output. And this is what happens. [image: Imagem inline 1] So you see I get a weird mirrored output, instead of something like "1 2 3 4 5 6". The perform method in the code is just static t_int *mtx_perform(t_int *w){ t_mtx *x = (t_mtx *)(w[1]); int nblock = (int)(w[2]); t_float **in_vectors = x->x_in_vectors; t_float **out_vectors = x->x_out_vectors; t_int i; for(i = 0; i < x->x_ch; i++){ t_float *in = in_vectors[i]; t_float *out = out_vectors[i]; t_int n = nblock; while(n--) *out++ = *in++; } return (w + 3); } What am I doing wrong? How should this go? See attached the help test example and code. Thanks

11 26

Jump to page:

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