Pd-dev December 2010

pd-dev@lists.iem.at

19 participants
50 discussions

Access to PD SVN
by David Doukhan 07 Feb '11

07 Feb '11

Hi all, Some of you met me last year at the PDCON09, when I presented a Binaural Synthesis external for PD that I did. I'm a 27 years old ex-engineer, specialized in artificial intelligence and sound processing... I'm currently doing a Phd on expressive Text to speech synthesis in Paris. Since I received few emails of people asking me to provide them the binaural external I did, I'd like to put it on the PD SVN. In order to do it, I need to have write access to PD SVN. My sourceforge account correspond to rudk(a)users.sourceforge.net . Can someone add me to the list of the developpers? Regards, -- David Doukhan http://www.limsi.fr/Individu/doukhan/

3 5

PD L2Ork 20101229 snapshot now available
by Ivica Ico Bukvic 02 Jan '11

02 Jan '11

Please excuse cross-posting. Dear friends and fellow FOSS enthusiasts, It is my great pleasure to share with the community a belated Holiday present :-) in a form of latest snapshot of L2Ork iteration of Pure-Data. Better than ever, the latest version comes with the following improvements: *implemented apply undo for array properties and partially implemented apply undo for graph-on-parent object properties (does not apply to abstractions or top-level windows currently until I figure out how to address the indexing of toplevel windows inside the glist as well as how to address to which window such an undo belongs). *properties are disabled when right-clicking on an abstraction as modifying its settings externally does not make sense when one does not see the actual contents inside it. So, to edit the properties of an abstraction, one has to open the actual abstraction. *fixed how new arrays are created so that they always fit within the specified boundaries. Please note arrays that have been already created in prior patches remain untouched in terms of graph auto-resizing (legacy code is provided in g_editor.c canvas_vis that deals with this if anyone wishes to convert their arrays but is incomplete in that it assumes all arrays require resizing--this is however unnecessary as simple recreation of said arrays or manual readjustment of their settings ought to do the trick. -This feature needs further testing--feedback is most appreciated. *fixed how arrays deal with moving array points via mouse by restricting them within the array bounds--this should work for all gui-driven array operations, while array alterations via snapshots and other external ways of manipulating arrays remain unbound so as to allow for traditional data-flow debugging--this may change down the road in part due to introduction of the magicGlass option and in part due to belief that data monitoring should only report ranges specified by the graph. -This feature needs further testing--feedback is most appreciated. *added new feature for arrays where they report a bang through the <arrayname>_changed send (if one is provided) whenever they have been altered by a mouse click'n'drag--this in conjunction with array graph auto-resizing makes arrays formidable alternatives for multisliders. -This feature needs further testing--feedback is most appreciated. *when an array subpatch is opened and resized, the array automatically now resizes to properly fill the window. -This feature needs further testing--feedback is most appreciated. *fixed where array was not visible after reopening the patch if any of its points touched upon y graph limits. *fixed couple of segfaults caused by gridflow incompatibility--more problems remain with gridflow library compatibility, likely due to widgetbehavior and possibly also magicGlass incompatibility. Further investigation is necessary. *fixed memory leak in the disis_phasor~ external where the destructor was never properly called and updated its documentation (available in the l2ork_addons package). *fixed highlighting of signal nlets where nlet would revert to non-signal appearance after being highlighted/connected. *reintroduced array listview (this was a regression in respect to pd-extended). *improved appearance of the array listview. *fixed a few broken links in the pddp documentation and added new l2ork-specific array features to the pddp documentation. Latest snapshot is available from the usual place: http://l2ork.music.vt.edu/main/?page_id=56 Complete changelog since 11/25/2010 is available here: http://l2ork.music.vt.edu/data/pd/Changelog Happy belated Holidays! Best wishes, Ico

1 2

[ pure-data-Patches-3136648 ] [unpackOSC] can only handle bundles with depth=16
by SourceForge.net 30 Dec '10

30 Dec '10

Patches item #3136648, was opened at 2010-12-13 17:17 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136648&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Martin Peach (mrpeach) Summary: [unpackOSC] can only handle bundles with depth=16 Initial Comment: while [packOSC] can create bundles with a depth of up to 32, [unpackOSC] can only unpack them to a depth of 16. i think the 2 should be made symmetrical. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2010-12-30 06:20 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Martin Peach (mrpeach) Date: 2010-12-16 05:39 Message: That should be fixed now. I added packingOSC.h with MAX_BUNDLE_NESTING = 32. MAX_BUNDLE_NESTING could easily be made larger... ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2010-12-13 17:19 Message: attached diff raises the recursion level to 32. however, i really think that both [packOSC] and [unpackOSC] should use the same define (from a OSC.h file) twhere this is set once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3136648&group_…

1 0

Re: [PD-dev] question about building externals on Linux
by katja 29 Dec '10

29 Dec '10

Ivica Ico Bukvic wrote: >>I've taken a quick stab at trying to port John Gibson's spectdelay~ >>external from Max to Pd and got stuck at the following error: >>load_object: Symbol "spectdelay_tilde_setup" not found >From the code, it seems that the extern "C" specification is commented out together with Max-specific code for the setup function. Katja

2 1

Re: [PD-dev] [PD] how to detect if array has changed
by Felipe Rodríguez 28 Dec '10

28 Dec '10

El 28 de diciembre de 2010 13:25, Mathieu Bouchard <matju(a)artengine.ca>escribió: > On Tue, 28 Dec 2010, Felipe Rodríguez wrote: > > There is some object that can calculate in real time the bandwidth of an >> audio signal? >> > > What do you want exactly ? > I want to overlap an audio signal with a sound generated by five formants. These formants will be generated by a bank of filtered white noise. The filters will use for this purpose will be bandpass filters, which need the frequency and Q parameters of the original signal to create a smooth overlap . > > Compute the standard deviation of the frequency histogram (spectrogram) ? > > Compute the frequency bounds within which 95 % of the energy lies ? > > Compute the max frequency minus the min frequency ? > > Something else related to that ? > Thank you. > > _______________________________________________________________________ > | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC > -- Felipe www.myspace.com/feliperodriguezbarrera http://soundcloud.com/felipe-rodriguez-barrera

1 0

Re: [PD-dev] [PD] how to detect if array has changed
by João Pais 28 Dec '10

28 Dec '10

> It was a suggestion. My patch only show one possibility to achieve what > Ico was looking for, without data structure. > The use of data structure (array) is another possibility (not so > elegant, as i wrote before, the click on data structure is not enough, > you still need a metro or a mouse listener. However, it is most elegant > graphically ! ;). I think it's also elegant to compare, because it will trigger only when there's a click. If I find the array+ abstraction I've done before, I could clean it up - but only after new year.

1 0

Re: [PD-dev] [PD] how to detect if array has changed
by João Pais 28 Dec '10

28 Dec '10

what do you mean with data structures, didn't see any in your patch. to the original poster, if it's a control array, it should change when you tell it to. so, jack's first suggestion is the most efficient, before you do a change, see if the written indexes are really different. otherwise there is the hard solution, but that implies you have a constant data flow going on at the same time, it's not the most efficient solution. > Look at the patch attached to this mail. > I think array in data structures is a most elegant way to do what you > are looking for. > ++ > >> Thanks all for the reply. Forgot to mention critical part--all this >> detection should however happen when one is "drawing" the array by >> clicking with the mouse onto the array's points and dragging them to new >> positions. Hence, there is no "middleware" patch to speak of (other than >> what array inherently provides). Is there anything that may provide >> this? if that's what you want to do, then there will always be changes. it's not possible to have the hand precision. unless you use an array that has a vertical step limit. since that's not a feature from array, I did once a data structures abstraction to do it. but I can't find it now. or, if using data strucutres, you can use the click output to know when change is being made, and compare it with an older state. that makes it more efficient, the comparison patch doesn't have to be working at an x rate. actually, that abstraction I did would do the job, then. it's somewhere in my disk, was part of a bigger patch.

2 1

Re: [PD-dev] how to detect if array has changed
by Jonathan Wilkes 27 Dec '10

27 Dec '10

If you clip, then you will no longer be able to tell the difference between an array wih values at max and min y and an array with y values that exceed the min/max y. Keeping outside elements visible gives visible feedback for patching errors that cause the outside elements.

1 0

is there a way for an object to detect whethere its inlet is connected to something
by Ivica Ico Bukvic 27 Dec '10

27 Dec '10

Hi all, I guess subject says it all. For the sake of efficiency I am hoping to detect whether an inlet is connected to anything and if so to perform its signal-based operations. Otherwise, it should remain dormant. Is there anything in the existing API that allows for this? Many thanks! Ico

2 3

Re: [PD-dev] [PD] how to detect if array has changed
by Ivica Ico Bukvic 27 Dec '10

27 Dec '10

On Mon, 2010-12-27 at 17:16 +0000, Pedro Lopes wrote: > Here's my point of view: > > > 1) Theres a million and one ways. > > > 2) If an array is changed by some pd-internal probably you can track > that down in the "changer patch", thus you can control and know it. > > > 3) Array comparison (as Jack noticed) is always possible, although > slower. Thanks all for the reply. Forgot to mention critical part--all this detection should however happen when one is "drawing" the array by clicking with the mouse onto the array's points and dragging them to new positions. Hence, there is no "middleware" patch to speak of (other than what array inherently provides). Is there anything that may provide this?

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

Pd-dev December 2010