Pd-dev November 2016

pd-dev@lists.iem.at

7 participants
8 discussions

how to get correct sample rate in an external object, even when overlap?
by katja 29 Nov '16

29 Nov '16

Hello, An external that I'm working on needs to know sample rate. Member s_sr of struct t_signal is normally used for the purpose, but this value isn't representative in a subpatch with overlap because it gives the total rate for the overlapping signal vectors. My external is specifically meant to work with use-case-dependent block size, overlap and downsampling, that's why I care. I know there's a feature request from 2005 about adding an 'overlap' member in the t_signal struct (https://sourceforge.net/p/pure-data/feature-requests/16/). That never happened - you can't add a member to a struct in a stable API, can you? Is there a workaround? The [samplerate~] object does it correctly, but uses functions / data types which aren't part of the API, or which are even local to the file (d_ugen.c). Could anyone think of another approach? Katja

1 0

[pure-data:bugs] #1275 changing num radio cells in a subpath via loadbang causes a TCL error
by danomatika 28 Nov '16

28 Nov '16

--- ** [bugs:#1275] changing num radio cells in a subpath via loadbang causes a TCL error** **Status:** open **Group:** v0.47 **Created:** Mon Nov 28, 2016 07:41 PM UTC by danomatika **Last Updated:** Mon Nov 28, 2016 07:41 PM UTC **Owner:** nobody **Attachments:** - [hradio-error.pd](https://sourceforge.net/p/pure-data/bugs/1275/attachment/h… (262 Bytes; application/octet-stream) On Mac OS 10.11.6, using a custom build of Pd 0.47-1: I was using an abstraction from rjlib that shows an hradio object in a GOP area and tracked down the following bug. Changing the number of cells in a radio object placed in a subpatch via a loadbang-ed number message to change the numer of cells results in an error: ~~~ (Tcl) INVALID COMMAND NAME: invalid command name ".x7d811430.c" while executing ".x7d811430.c delete 7aa63e00BASE0" ("uplevel" body line 40) invoked from within "uplevel #0 $docmds" ~~~ >From what I can tell, the loadbang fires before the radio is drawn for the first time since it is in a subpatch, so there are no cells to delete leading to the error. This also, for some reason, causes sliders and radios to be come unresponsive since the controls no longer re-draw in the particular patch where I first had the bug. The fix I have for now is to add a 5ms delay after the loadbang. I think the real fix is to only call IEM_GUI_DRAW_MODE_ERASE in hradio_number() if the radio has already been drawn. Attached is a patch which triggers the error. --- Sent from sourceforge.net because pd-dev(a)lists.iem.at is subscribed to https://sourceforge.net/p/pure-data/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/pure-data/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

1 0

Iem_gui objects in vanilla and zoom
by Fred Jan Kraan 27 Nov '16

27 Nov '16

Hi, While trying to understand the zoom function to apply it to other GUI objects, I studied the bng and tgl objects, and in the process came up with a solution that fixed both. For the iem_gui objects only the basic generic GUI parameters are available in a struct; x & y position coordinates, height and width. All other GUI dimensions are not accessible outside the drawing functions. The only option to get a correct zoom is to apply the zoom-factor to all appropriate dimension values in all GUI functions. At least for bng I have this working. With some more refactoring this could be applied without adding too much to the declared mess in the objects code. Greetings, Fred Jan

1 2

cos and large amplitude signal in?
by Nicolas Danet 26 Nov '16

26 Nov '16

Hi, The cos signal object seems to give bad results for a large amplitude signal in (> 1024). As far as i understand it is limited to (2^19 / COSTABSIZE) due to the fractional trick here < https://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_osc.c#l1… >. Is it a well known limitation? #N canvas 188 157 698 331 12; #X obj 25 170 cos~; #X obj 25 219 snapshot~; #X floatatom 25 245 0 0 0 0 - - -; #X obj 92 185 metro 500; #X obj 92 159 r metro; #X msg 387 92 \; metro 0; #X msg 368 38 \; pd dsp 1 \; metro 1; #X text 455 53 <-Click to start; #X text 456 98 <-Click to stop; #X msg 83 34 1025; #X obj 25 122 sig~ 1023; #X msg 25 33 1024; #X msg 146 34 1026; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 2 0; #X connect 3 0 1 0; #X connect 4 0 3 0; #X connect 9 0 10 0; #X connect 10 0 0 0; #X connect 11 0 10 0; #X connect 12 0 10 0; #X coords 0 0 1 1 200 140 0;

2 2

Re: [PD-dev] More info about dsp_phase in d_ugen.c
by Pierre Guillot 18 Nov '16

18 Nov '16

Perhaps Miller would have a better answer but I try: When the graph is compiled, the dsp_phase value is used to set up the x_phase value of the block. Thereafter, this x_phase value is used to determine if the block should be performed or not. So I didn't test it but perhaps should try to use it with several subpatches with their own block sizes. For example, if the block size of a subpatch is 128 samples, then perhaps you'll stop the dsp in the main process at 64 samples before this subpatch was performed and when you'll restart the dsp, the block will wait only 64 samples (instead of 128) to execute its chain because dsp_phase%128 would be 64. 2016-11-18 14:12 GMT+01:00 Nicolas Danet <nicolas.danet(a)free.fr>: > > Hi, > > Ah Ah, you are right... but that is precisely the part i understand ;-) > > In all the tests i did, at the time it initializes the block value phase, > the (dsp_phase % block_size) result is always zero (ditto for inlet > prolog). The only code where it is not zero is in the outlet epilog at < > https://sourceforge.net/p/pure-data/pure-data/ci/master/ > tree/src/g_io.c#l518 >. But the result seems weird. > > a/ i did a mistake in my modified code. > b/ it is used only by the one shot dsp-chain feature (that i removed in my > code). > c/ it doesn't do anything. > d/ ... > > Anyway, thanks for your reply. > > e/ I will try to remove that stuff and wait for an hypothetical crash! > > ----- Mail d'origine ----- > De: Pierre Guillot <guillotpierre6(a)gmail.com> > À: Nicolas Danet <nicolas.danet(a)free.fr> > Cc: pd-dev(a)lists.iem.at > Envoyé: Fri, 18 Nov 2016 13:37:20 +0100 (CET) > Objet: Re: [PD-dev] More info about dsp_phase in d_ugen.c > > Hi Nicolas, > I'm not sure but I think it's the total amount of dsp ticks since the > opening of PD and it's mostly used by the block objects to know when to run > their DSP blocks (something like if dsp_phase%block_size==0 then perform). > > 2016-11-18 7:55 GMT+01:00 Nicolas Danet <nicolas.danet(a)free.fr>: > > > Hello, > > > > I really have hard time to understand what's the dsp_phase variable > > (d_ugen.c) is supposed to do. > > I obtain always zero or weird values in the prolog / epilog calls. > > Is it related to the one shot tick feature provided by the block object? > > Thanks for clues or links to any information/discussion. > > > > < https://sourceforge.net/p/pure-data/pure-data/ci/master/ > > tree/src/d_ugen.c#l101 > > > < https://sourceforge.net/p/pure-data/pure-data/ci/master/ > > tree/src/g_io.c#l518 > > > > > _______________________________________________ > > Pd-dev mailing list > > Pd-dev(a)lists.iem.at > > https://lists.puredata.info/listinfo/pd-dev > > > >

2 1

More info about dsp_phase in d_ugen.c
by Nicolas Danet 18 Nov '16

18 Nov '16

Hello, I really have hard time to understand what's the dsp_phase variable (d_ugen.c) is supposed to do. I obtain always zero or weird values in the prolog / epilog calls. Is it related to the one shot tick feature provided by the block object? Thanks for clues or links to any information/discussion. < https://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_ugen.c#l… > < https://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/g_io.c#l518 >

2 2

FYI yet another fork...
by Nicolas Danet 04 Nov '16

04 Nov '16

Hello, For fun i started to "refactoring" the code of Pd. It is far from finished (might to be done before this summer) but it could interest some of you. Let me know for attribution / license concerns (i'll rename it later if it worth the cost). < https://github.com/nicolasdanet/PureData >

4 5

To free inlets and outlets or not to free in-/out-lets?
by Fred Jan Kraan 04 Nov '16

04 Nov '16

Hi Devs, According to the Externals-HOWTO it is required to free the created inlets and outlets. This makes sense as Pd allocates memory for them and frees it on calling inlet_free() and outlet_free(). But the practice is not very common, and the (recent) pd_free also attempts to free them. It does this after checking there is a *_free() method and calling it. Is there a good reason to free the in- and out-lets from the object *_free() method anyhow? After all, it is extra code, that could contain errors too? Greetings, Fred Jan

2 2

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 November 2016