Pd-dev June 2008

pd-dev@lists.iem.at

24 participants
90 discussions

[ pure-data-Bugs-2005281 ] block~-overlapped canvases: samplerate wrong for dsp objects
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #2005281, was opened at 2008-06-28 18:11 Message generated for change (Settings changed) made by xovo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005281&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: pd-devel Group: v0.41.0 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Thomas Grill (xovo) >Assigned to: Miller Puckette (millerpuckette) Summary: block~-overlapped canvases: samplerate wrong for dsp objects Initial Comment: There's a strange behavior in canvases with overlapped blocks without resampling (e.g. set with [block~ 1024 2]). In such canvases e.g. [osc~ 440] delivers a cosine wave with an actual frequency of 220 Hz, because of the double overlap. This is because dsp signal vectors carry the wrong sample rate (sp[0]->s_sr = 88200 instead of 44100). [samplerate~] correctly reports 44100 because it uses a different method of retrieving the sample rate. For osc~ it's possible to take into account the wrong internal sample rate, but that's certainly not possible in more general cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005281&group_…

1 0

[ pure-data-Bugs-1721404 ] xsample lib not loading
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #1721404, was opened at 2007-05-18 15:50 Message generated for change (Comment added) made by xovo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721404&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: v0.39.2 >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: kyleklip (kyleklip) Assigned to: Thomas Grill (xovo) Summary: xsample lib not loading Initial Comment: The xgroove~ and xplay~ objects are not working for me on Pd-0.39.2-extended-rc2 (OS X 10.4.9). The *.pd_darwin files are in the /extra folder, and other objects are loading fine from there (tested vasp and it loads). Could this be an issue with the actual compiled externals? I know that flext can be a bit tricky on OS X (at least for me). ---------------------------------------------------------------------- >Comment By: Thomas Grill (xovo) Date: 2008-06-28 18:15 Message: Logged In: YES user_id=350252 Originator: NO I consider that a packaging issue or version mismatch... there's a PD API change from 0.39 to 0.40 iirc, so flext-based objects must be compiled explicitly for either version. ---------------------------------------------------------------------- Comment By: Luke Iannini (lukeiannini) Date: 2007-07-01 23:02 Message: Logged In: YES user_id=1541432 Originator: NO Sorry, that's 392RC4 not 392RC2. ---------------------------------------------------------------------- Comment By: Luke Iannini (lukeiannini) Date: 2007-07-01 23:01 Message: Logged In: YES user_id=1541432 Originator: NO Hi all, These are working fine for me on both 392RC2 (out of the box) and 0.40.2 autobuilds (though 0.40.2 does not have it loading by default in the plist) on Mac/Intel 10.4.10. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-05-29 03:35 Message: Logged In: YES user_id=27104 Originator: NO For the flext-based externals, Pd-extended just includes the binaries built by Thomas Grill, which were downloaded from his site: http://grrrr.org/ext/beta/pd/osx/ Pd-0.39.2-extended-rc2 has the latest from that site. Other than that, I don't know much about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1721404&group_…

1 0

[ pure-data-Bugs-2005281 ] block~-overlapped canvases: samplerate wrong for dsp objects
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #2005281, was opened at 2008-06-28 18:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005281&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: pd-devel Group: v0.41.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Grill (xovo) Assigned to: Nobody/Anonymous (nobody) Summary: block~-overlapped canvases: samplerate wrong for dsp objects Initial Comment: There's a strange behavior in canvases with overlapped blocks without resampling (e.g. set with [block~ 1024 2]). In such canvases e.g. [osc~ 440] delivers a cosine wave with an actual frequency of 220 Hz, because of the double overlap. This is because dsp signal vectors carry the wrong sample rate (sp[0]->s_sr = 88200 instead of 44100). [samplerate~] correctly reports 44100 because it uses a different method of retrieving the sample rate. For osc~ it's possible to take into account the wrong internal sample rate, but that's certainly not possible in more general cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2005281&group_…

1 0

block~-overlapped canvases: samplerate wrong for dsp objects
by Thomas Grill 28 Jun '08

28 Jun '08

Hi, i just stumbled over a strange behavior in canvases with overlapped blocks without resampling (e.g. set with [block~ 1024 2]). In such canvases e.g. [osc~ 440] delivers a cosine wave with an actual frequency of 220 Hz, because of the double overlap. This is because dsp signal vectors carry the wrong sample rate (sp[0]- >s_sr = 88200 instead of 44100). [samplerate~] correctly reports 44100 because it uses a different method of retrieving the sample rate. I consider that a bug and would file a bug report, but since this must have been present for a long time and must surely have been discovered by other people as well it might also be a feature.... any ideas? gr~~~

2 2

[ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #2004979, was opened at 2008-06-28 12:28 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&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: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events") Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2008-06-28 14:05 Message: Logged In: YES user_id=569446 Originator: YES I'm using the "trunk", not a branch. I did a "cd trunk/externals; make hid" as told in hid's README. It still starts with debugging then. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 12:58 Message: Logged In: YES user_id=27104 Originator: NO I just fixed this and some other bugs and annoyances with [hid]. This should be fixed by this commit, let me know if it is not: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_…

1 0

[ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #2004979, was opened at 2008-06-28 06:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&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: Fixed Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events") Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 06:58 Message: Logged In: YES user_id=27104 Originator: NO I just fixed this and some other bugs and annoyances with [hid]. This should be fixed by this commit, let me know if it is not: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_…

1 0

[ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by SourceForge.net 28 Jun '08

28 Jun '08

Bugs item #2004979, was opened at 2008-06-28 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Nobody/Anonymous (nobody) Summary: hid defaults to debugging (flood of "hid_get_events") Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_…

1 0

Re: [PD-dev] bang [block~] to query current blocksize
by Mathieu Bouchard 28 Jun '08

28 Jun '08

On Fri, 23 May 2008, Hans-Christoph Steiner wrote: > It seems that adding an outlet to block~/switch~ seems to be the most obvious > interface for getting the data. Perhaps just a message then? sending a "get blocksize" message to either object could output "blocksize $1" through the last outlet, and likewise, "get overlap" and "get oversample" would output those properties through same-named messages out of last outlet, and just "get" would output all of them. It's a scheme that I am already using in many of my externals and I will figure out a clean way to have it happen with my abstractions. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec

1 0

[ pure-data-Bugs-1945042 ] [avg~] and [tavg~] from zexy broken in pd-ext
by SourceForge.net 26 Jun '08

26 Jun '08

Bugs item #1945042, was opened at 2008-04-17 11:29 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1945042&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: pd-extended Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [avg~] and [tavg~] from zexy broken in pd-ext Initial Comment: my test-patch: [avg~] | [print] doesn't print anything at all, even if audio is turned on or a non-zero signal is sent (e.g. [1 ( - [sig~] ) the same goes for [tavg~] i tested with pd-extended-0.40.3-20080308 on ubuntu dapper. ---------------------- the same behaviour i get with a current checkout of zexy from pd-svn, when i use the pd-extended makefile and compile zexy like this: cd pd-svn/externals make zexy -------------------------- [avg~] and [tavg~] work perfectly, if i compile them with the original makefile: cd pd-svn/externals/zexy/src ./configure make the resulting zexy.pd_linux _doesn't have his bug --------------------- -> the problem seems to be related to how zexy is compiled and not to the source of avg~ or tavg~. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2008-06-25 22:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: IOhannes m zmlnig (zmoelnig) Date: 2008-06-11 08:39 Message: Logged In: YES user_id=564396 Originator: NO i cannot reproduce this using Pd-0.40.3-extended-20080611-debian-testing-i386.deb and should this be a "bug" rather than a "patch" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1945042&group_…

1 0

please remove old pdlua from SVN
by Claude Heiland-Allen 25 Jun '08

25 Jun '08

Hello, Can one of you fine developers with sf.net access please delete: pure-data/trunk/externals/loaders/pdlua It's at pdlua-0.3, 2 versions behind the current release... Either that or make it refer dynamically to the current development repository: https://devel.goto10.org/svn/maximus/pdlua Thanks, Claude -- http://claudiusmaximus.goto10.org

3 3

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 June 2008