Pd-dev November 2012

pd-dev@lists.iem.at

9 participants
83 discussions

[ pure-data-Patches-3585469 ] Drop-in replacement for helpbrowser.tcl
by SourceForge.net 11 Nov '12

11 Nov '12

Patches item #3585469, was opened at 2012-11-08 13:59 Message generated for change (Comment added) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: Drop-in replacement for helpbrowser.tcl Initial Comment: Improved document browser and search engine for Pure Data internal/external documentation. This is a refactored version of this GUI plugin: http://puredata.info/Members/jancsika/searchplugindesc/ with the following mods: * same key bindings as other dialogs * withdrawing the window with <ctrl-w> or ESC will stop the current search in case it isn't finished * clearer home page ---------------------------------------------------------------------- >Comment By: Jonathan Wilkes (jancsika1) Date: 2012-11-11 12:22 Message: Made the navigation bar in a separate text widget that stays at the top when scrolling ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&group_…

1 0

[ pure-data-Patches-3585461 ] [readsf~] loops some files
by SourceForge.net 09 Nov '12

09 Nov '12

Patches item #3585461, was opened at 2012-11-08 13:09 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [readsf~] loops some files Initial Comment: some wav-files get looped when played back via [readsf~]. it seems that the problem is dues to the soundfile fitting exactly into the fifobuffer, thus the EOF (signalled by the read-thread) drain never really starts in the perform routine. (fifohead==fifosize, so the test for (!x_eof && x_fifohead >= x_fifotail && x_fifohead < x_fifotail + wantbytes-1) never triggers, resulting in a continuous drain of the entire buffer. the attached soundfile triggers this behaviour. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-08 13:11 Message: attached is a simplistic attempt to fix the problem: if the fifohead==fifosize, we wrap it to 0 even if we just read the last byte. (originally this was only done if !EOF) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585461&group_…

1 0

[ pure-data-Patches-3585469 ] Drop-in replacement for helpbrowser.tcl
by SourceForge.net 08 Nov '12

08 Nov '12

Patches item #3585469, was opened at 2012-11-08 13:59 Message generated for change (Tracker Item Submitted) made by jancsika1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jonathan Wilkes (jancsika1) Assigned to: Nobody/Anonymous (nobody) Summary: Drop-in replacement for helpbrowser.tcl Initial Comment: Improved document browser and search engine for Pure Data internal/external documentation. This is a refactored version of this GUI plugin: http://puredata.info/Members/jancsika/searchplugindesc/ with the following mods: * same key bindings as other dialogs * withdrawing the window with <ctrl-w> or ESC will stop the current search in case it isn't finished * clearer home page ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585469&group_…

1 0

[ pure-data-Bugs-3585461 ] [readsf~] loops some files
by SourceForge.net 08 Nov '12

08 Nov '12

Bugs item #3585461, was opened at 2012-11-08 13:09 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585461&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [readsf~] loops some files Initial Comment: some wav-files get looped when played back via [readsf~]. it seems that the problem is dues to the soundfile fitting exactly into the fifobuffer, thus the EOF (signalled by the read-thread) drain never really starts in the perform routine. (fifohead==fifosize, so the test for (!x_eof && x_fifohead >= x_fifotail && x_fifohead < x_fifotail + wantbytes-1) never triggers, resulting in a continuous drain of the entire buffer. the attached soundfile triggers this behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585461&group_…

1 0

[ pure-data-Patches-3585457 ] support for OSSv4
by SourceForge.net 08 Nov '12

08 Nov '12

Patches item #3585457, was opened at 2012-11-08 12:17 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&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: puredata Group: bugfix Status: Open Resolution: None >Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: support for OSSv4 Initial Comment: one of Pd's older audio-backends is OSS. while OSS is rather old and not a fast-moving target, some development does happen... e.g. a while ago (probably years) all SOUND_PCM_-defines have been renamed to SNDCTL_DSP_. luckily, the linux headers provided fallback defines, so old code (like Pd) would still compile. now OSS is not dead and is currently developed as OSSv4. unfortunately, the new OSSv4 headers have dropped the old fallback defines, and instead pro-actively create errors when the old defines are still used. the attached patch changes these defines (and provides fallbacks in case the *new* defines are not defined), in order to be able to still use the OSS backend. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-08 12:19 Message: raising priority since the old s_audio_oss.c breaks compilation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&group_…

1 0

[ pure-data-Patches-3585457 ] support for OSSv4
by SourceForge.net 08 Nov '12

08 Nov '12

Patches item #3585457, was opened at 2012-11-08 12:17 Message generated for change (Tracker Item Submitted) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&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: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: support for OSSv4 Initial Comment: one of Pd's older audio-backends is OSS. while OSS is rather old and not a fast-moving target, some development does happen... e.g. a while ago (probably years) all SOUND_PCM_-defines have been renamed to SNDCTL_DSP_. luckily, the linux headers provided fallback defines, so old code (like Pd) would still compile. now OSS is not dead and is currently developed as OSSv4. unfortunately, the new OSSv4 headers have dropped the old fallback defines, and instead pro-actively create errors when the old defines are still used. the attached patch changes these defines (and provides fallbacks in case the *new* defines are not defined), in order to be able to still use the OSS backend. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3585457&group_…

1 0

[ pure-data-Bugs-3585120 ] Number boxes always show the value zero
by SourceForge.net 07 Nov '12

07 Nov '12

Bugs item #3585120, was opened at 2012-11-07 03:45 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585120&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: Open Resolution: None Priority: 5 Private: Yes Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Number boxes always show the value zero Initial Comment: Although the tone works and even can be altered by scrolling, the numbers in the boxes always show the value zero. Pd version 0.42.5-extended Windows 7 Home Premium / Intel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3585120&group_…

1 0

[ pure-data-Bugs-3584788 ] Problem: GUI freezes with Windows OS
by SourceForge.net 06 Nov '12

06 Nov '12

Bugs item #3584788, was opened at 2012-11-06 08:27 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3584788&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: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Hans-Christoph Steiner (eighthave) Summary: Problem: GUI freezes with Windows OS Initial Comment: Pd version 0.42.5-extended or 0.43.4-extended 20121101 Windows XP SP3: off the shelves Celeron 2,40Ghz 2Go or VMWare on MacPro OSX Lion (faster, but exactly the same facts) I try to create a windows version of a big MIDI app with many gui objects and abstractions, that runs perfectly and with few latencies on OSX or Linux. 1. on launching, the gui appears more than one minute after the pd console window 2. all gui object are frozen, i.e the GUI objects (sliders, toggles...) do not reflect values received through their receive symbols 3. the turn around to update the window is to miimize it then to maximize it again ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3584788&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 06 Nov '12

06 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support Initial Comment: FIrst round of patches to add support for OpenBSD. ---------------------------------------------------------------------- >Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 05:13 Message: #1 yes, the build-system is messed up (or rather, it is in a state of transition) #2 .../src/configure adds HAVE_foo to CPPFLAGS (and .../configure adds it to DEFS), which get expanded in the resp. makefiles (so technically you are right, they don't get added to CFLAGS) #3 i said "makefile.nt" and not "makefile.in", which is the 3rd(!) build-system that is there and which is used to build on w32 using MSVC. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-06 04:45 Message: I might be missing something but unless you add it manually I don't see where configures adds the HAVE_XXX to CFLAGS unless you do it manually. And src/makefile.in is processed by src/configure(.in) so only ../configure.ac and ../src/configure.in need to be modified. <rant> You have a pretty messed up build system. </rant> ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 03:57 Message: if the patch comes from git, then please create a branch, commit to that and then create a patch-set using "git format-patch master". as for the HAVE_ALLOCA_H: if you don't instruct configure to write defines into config.h, it will add them to the CFLAGS, so that the compilation will still work. thus, no need to change the build-system. bear in mind though, that currently Pd uses to separate build-systems: .../configure.ac and .../src/configure.in (and .../src/makefile.nt); you might need to modify all 3 in order to get accepted (yes, it's a PITA) ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:48 Message: @zmoelnig: The patch comes from git. My main concern is how to proceed with the other changes that require more changes than just extending an existing ifdef. For example the exclusion of alloca.h, etc. In my git clone I've modified configure to use config headers and so I can do ifdef HAVE_ALLOCA_H, etc. but I'm not sure if such patches will be accepted. The reason I've break them down is so they can be committed while I understand what your preference is. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 02:39 Message: this patch is simple enough (almost trivial) as it only adds "#ifdef __OpenBSD__" to the clauses that are already handled by "__FreeBSD__". i don't see a reason to not include it (but of course this all depends on miller). small note on patches: - the patch doesn't apply here (`patch` thinks the diff is garbage) - Pd is developped in git; it would be great if you could generate your patches using git as well; see [1] - as for atomicity of patches: personally i think creating a (few) smaller patches is not a real problem; make sure that those patches are logical units rather than reflecting your iterative trial-and-error history to fix a problem. then attach all patch files to this ticket (rather than creating a new patchtracker-ticket for each file) [1] http://puredata.info/docs/developer/GitWorkflows/ ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:03 Message: Comments please? I'd really to move forward with this. Thanks. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-10-29 19:01 Message: That'd be ideal but since I'm not sure about the other changes (using config headers, etc.) I'm submitting what I know for certain that won't change depending on the approach. For example what should I do if alloca.h doesn't exist? In my git repo I have #ifdef HAVE_ALLOCA_H where the define is driven from autotools header check but I'm still unclear whether you want to use the headers or not (and the reason you might not want to do it since you're already using autotools). Happy to submit everything in one go if you can suggest what the best course of action is. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-10-29 18:57 Message: The best thing to do would be to make a single patch that includes everything needed for OpenBSD support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_…

1 0

[ pure-data-Patches-3581737 ] OpenBSD support
by SourceForge.net 06 Nov '12

06 Nov '12

Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support Initial Comment: FIrst round of patches to add support for OpenBSD. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-11-06 04:45 Message: I might be missing something but unless you add it manually I don't see where configures adds the HAVE_XXX to CFLAGS unless you do it manually. And src/makefile.in is processed by src/configure(.in) so only ../configure.ac and ../src/configure.in need to be modified. <rant> You have a pretty messed up build system. </rant> ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 03:57 Message: if the patch comes from git, then please create a branch, commit to that and then create a patch-set using "git format-patch master". as for the HAVE_ALLOCA_H: if you don't instruct configure to write defines into config.h, it will add them to the CFLAGS, so that the compilation will still work. thus, no need to change the build-system. bear in mind though, that currently Pd uses to separate build-systems: .../configure.ac and .../src/configure.in (and .../src/makefile.nt); you might need to modify all 3 in order to get accepted (yes, it's a PITA) ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:48 Message: @zmoelnig: The patch comes from git. My main concern is how to proceed with the other changes that require more changes than just extending an existing ifdef. For example the exclusion of alloca.h, etc. In my git clone I've modified configure to use config headers and so I can do ifdef HAVE_ALLOCA_H, etc. but I'm not sure if such patches will be accepted. The reason I've break them down is so they can be committed while I understand what your preference is. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 02:39 Message: this patch is simple enough (almost trivial) as it only adds "#ifdef __OpenBSD__" to the clauses that are already handled by "__FreeBSD__". i don't see a reason to not include it (but of course this all depends on miller). small note on patches: - the patch doesn't apply here (`patch` thinks the diff is garbage) - Pd is developped in git; it would be great if you could generate your patches using git as well; see [1] - as for atomicity of patches: personally i think creating a (few) smaller patches is not a real problem; make sure that those patches are logical units rather than reflecting your iterative trial-and-error history to fix a problem. then attach all patch files to this ticket (rather than creating a new patchtracker-ticket for each file) [1] http://puredata.info/docs/developer/GitWorkflows/ ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:03 Message: Comments please? I'd really to move forward with this. Thanks. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2012-10-29 19:01 Message: That'd be ideal but since I'm not sure about the other changes (using config headers, etc.) I'm submitting what I know for certain that won't change depending on the approach. For example what should I do if alloca.h doesn't exist? In my git repo I have #ifdef HAVE_ALLOCA_H where the define is driven from autotools header check but I'm still unclear whether you want to use the headers or not (and the reason you might not want to do it since you're already using autotools). Happy to submit everything in one go if you can suggest what the best course of action is. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-10-29 18:57 Message: The best thing to do would be to make a single patch that includes everything needed for OpenBSD support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737&group_…

1 0

← 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 November 2012