[PD-dev] automake in git (was: uploading Pd git repository to sourceforge)
here is a patch for current git that should make the automake functional again. note: when doing a make install, the pd binary only get's installed into /usr/local/bin/pd (by default) and not into /usr/local/lib/pd/bin/pd; this is not a problem unless you try to start Pd from the gui-side (pd-gui will only look into /usr/local/lib/pd/bin/pd for the binary) note: for extra/, i have build on the original makefile by miller, as it seems to be more extendable than hc's suggestion, which resulted in a rather tedious enumeration of all the files to be compiled in a centralized file. that's all the issues i currently know of. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PATCH 06/10] fixed race-condition in the audio/midi API initialization
That's the idea of the wait4pd stuff, to make sure that pd is started
before continuing on. I don't think this is necessary. Do you have a
way to trigger pd taking too long to start up?
.hc
On Jul 15, 2010, at 2:57 AM, IOhannes m zmoelnig wrote:
if Pd takes too long to startup, Pd-gui will initialize the audio/
midi API-menus
with NULL-lists;
if Pd finally shows up, the menu cannot be modified anymore, and
thus the user
cannot select the API they want.
the fix moves the audio/midi APIs into a sub-menu of Media, and
provides a
function ::pd_menus::build_media_api_menus that will clear the old
API-menus and
refill them with the new API-lists.
this allows Pd-core, to update the API-lists after the GUI has been
initialized.
---
tcl/pd-gui.tcl |1 +
tcl/pd_menus.tcl | 50
+-
2 files changed, 34 insertions(+), 17 deletions(-)
diff --git a/tcl/pd-gui.tcl b/tcl/pd-gui.tcl
index c99decc..b4f20b3 100755
--- a/tcl/pd-gui.tcl
+++ b/tcl/pd-gui.tcl
@@ -460,6 +460,7 @@ proc pdtk_pd_startup {major minor bugfix test
if {$::tcl_version = 8.5} {find_default_font}
set_base_font $sys_font $sys_fontweight
fit_font_into_metrics
+::pd_menus::build_media_api_menus $::pdwindow_menubar.media
set ::wait4pd started
}
diff --git a/tcl/pd_menus.tcl b/tcl/pd_menus.tcl
index fc617df..7157c5e 100644
--- a/tcl/pd_menus.tcl
+++ b/tcl/pd_menus.tcl
@@ -224,6 +224,32 @@ proc ::pd_menus::build_find_menu {mymenu} {
-command {pdsend {pd finderror}}
}
+
+## update the audio/midi API lists
+# this is done by first clearing the menus, and then rebuilding
them from scratch
+proc ::pd_menus::build_media_api_menus {mymenu} {
+if { [winfo exists $mymenu.audio] } {
+$mymenu.audio delete 0 [ $mymenu.audio index last]
+set audio_apilist_length [llength $::audio_apilist]
+for {set x 0} {$x$audio_apilist_length} {incr x} {
+$mymenu.audio add radiobutton -label [lindex [lindex
$::audio_apilist $x] 0] \
+-command {menu_audio 0} -variable ::pd_whichapi \
+-value [lindex [lindex $::audio_apilist $x] 1]\
+-command {pdsend pd audio-setapi $::pd_whichapi}
+}
+}
+if { [winfo exists $mymenu.midi] } {
+$mymenu.midi delet 0 [ $mymenu.midi index last]
+set midi_apilist_length [llength $::midi_apilist]
+for {set x 0} {$x$midi_apilist_length} {incr x} {
+$mymenu.midi add radiobutton -label [lindex [lindex
$::midi_apilist $x] 0] \
+-command {menu_midi 0} -variable ::pd_whichmidiapi \
+-value [lindex [lindex $::midi_apilist $x] 1]\
+-command {pdsend pd midi-setapi $::pd_whichmidiapi}
+}
+}
+}
+
proc ::pd_menus::build_media_menu {mymenu} {
variable accelerator
$mymenu add radiobutton -label [_ DSP On] -accelerator
$accelerator+/ \
@@ -237,23 +263,13 @@ proc ::pd_menus::build_media_menu {mymenu} {
$mymenu add command -label [_ Load Meter] \
-command {menu_doc_open doc/7.stuff/tools load-meter.pd}
-set audio_apilist_length [llength $::audio_apilist]
-if {$audio_apilist_length 0} {$mymenu add separator}
-for {set x 0} {$x$audio_apilist_length} {incr x} {
-$mymenu add radiobutton -label [lindex [lindex
$::audio_apilist $x] 0] \
--command {menu_audio 0} -variable ::pd_whichapi \
--value [lindex [lindex $::audio_apilist $x] 1]\
--command {pdsend pd audio-setapi $::pd_whichapi}
-}
-
-set midi_apilist_length [llength $::midi_apilist]
-if {$midi_apilist_length 0} {$mymenu add separator}
-for {set x 0} {$x$midi_apilist_length} {incr x} {
-$mymenu add radiobutton -label [lindex [lindex
$::midi_apilist $x] 0] \
--command {menu_midi 0} -variable ::pd_whichmidiapi \
--value [lindex [lindex $::midi_apilist $x] 1]\
--command {pdsend pd midi-setapi $::pd_whichmidiapi}
-}
+menu $mymenu.audio
+menu $mymenu.midi
+$mymenu add cascade -label [_ Audio] -menu $mymenu.audio
+$mymenu add cascade -label [_ Midi] -menu $mymenu.midi
+
+build_media_api_menus $mymenu
+
if {$::windowingsystem ne aqua} {
$mymenu add separator
create_preferences_menu $mymenu.preferences
--
1.7.1
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism.- retired U.S. Army general, William Odom
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] automake in git (was: uploading Pd git repository to sourceforge)
On Jul 15, 2010, at 5:19 AM, IOhannes m zmoelnig wrote: here is a patch for current git that should make the automake functional again. note: when doing a make install, the pd binary only get's installed into /usr/local/bin/pd (by default) and not into /usr/local/lib/pd/bin/ pd; this is not a problem unless you try to start Pd from the gui-side (pd-gui will only look into /usr/local/lib/pd/bin/pd for the binary) note: for extra/, i have build on the original makefile by miller, as it seems to be more extendable than hc's suggestion, which resulted in a rather tedious enumeration of all the files to be compiled in a centralized file. That rather tedious enumeration is something that rarely changes and provides error checking where automatic enumeration does not. A build system should know if any of the relevant files are missing, and it should ignore all non-relevant files. Therefore tedious enumeration is often the best practice. .hc that's all the issues i currently know of. fgmasdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PATCH] made automake system kind-of work
On 2010-07-15 16:06, Hans-Christoph Steiner wrote: FYI: if you remove all makefiles in 'extra' you can replace it with the extra/Makefile from pd-gui-rewrite-0.43 which builds all objects in 'extra'. It has the added advantage of working on GNU/Linux, Mac OS X, MinGW and Cygwin, plus is based on the Makefile template for libraries. The existing 'extra' makefiles have always been problematic when it comes to anything but GNU/Linux. true. however the extra/Makefile from pd-gui-rewrite is again a big monolithic chunk with all files (and by-now non-existant files as well) enumerated. it reminds me of the old externs/Makefile for pd-extended. that's one reason why i chose not to use that. fgmasdr IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] automake in git
On 2010-07-15 16:08, Hans-Christoph Steiner wrote: That rather tedious enumeration is something that rarely changes and provides error checking where automatic enumeration does not. A build system should know if any of the relevant files are missing, and it should ignore all non-relevant files. Therefore tedious enumeration is often the best practice. sure sometimes this is true. in other cases, it boils down to a human-written list that contains files that were non-relevant from the beginning... anyhow, i'm not so objecting enumeration, but i'm very much objecting enumeration of files for extra/pd~/ in extra/Makefile. shouldn't they be enumerated in extra/pd~/Makefile? fgma IOhannes smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] automake in git
On Jul 15, 2010, at 10:13 AM, IOhannes m zmoelnig wrote: On 2010-07-15 16:08, Hans-Christoph Steiner wrote: That rather tedious enumeration is something that rarely changes and provides error checking where automatic enumeration does not. A build system should know if any of the relevant files are missing, and it should ignore all non-relevant files. Therefore tedious enumeration is often the best practice. sure sometimes this is true. in other cases, it boils down to a human-written list that contains files that were non-relevant from the beginning... Which files are non-relevant that are included in extra/Makefile? anyhow, i'm not so objecting enumeration, but i'm very much objecting enumeration of files for extra/pd~/ in extra/Makefile. shouldn't they be enumerated in extra/pd~/Makefile? Or how about making 'extra' have a flat directory structure, that would also simplify things. The symlinking in the existing extra makefiles is horrendous, IMHO. I've wasted too much time on those kludges. .hc Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] 0.43 startup procedure and vwait WAS: [PATCH 06/10] fixed race-condition in the audio/midi API initialization
On 07/15/2010 04:46 PM, Hans-Christoph Steiner wrote: The vwait timeout would not be needed if we can rely on 'pd' to actually fully die when it exits/crashes. On Mac OS X at least it is often doesn't completely crash and the process just sits there doing who knows what. If this happens on startup, pd-gui's exec call will not return, and pdtk_pd_startup won't be called and pd-gui will just sit and wait forever, giving us a zombie pd-gui. The vwait stuff wouldn't be needed if we can rely of pd to exit completely on all platforms. Just removing the vwait stuff is just replacing one problem with another. sure. i'm only talking about the race-condition. whether the vwait is there for other things is entirely beyond my scope. iirc, this is the title of this thread as well. Relax, no one is suggesting fixing a race condition with a timeout. Can you describe how to reproduce the race condition? What's actually racing? Did Miller's changes fix it? i did not experience any problem with miller's changes so far (which does not mean that the race-condition is gone, it just didn't show up) racing was between pd-gui and pd: if the latter was to late, either pd-gui would timeout or the media menu would be initialized wrongly (no audio/midi APIs available) leaving all this aside, i still think that it is a good idea for Pd to be able to change the dynamic entries of the menu at any time. if the available APIs change, Pd could update the menu accordingly (sounds like a stupid idea? but if jackd is running, then the only really available API would be jack (OSS, ALSA, portaudio being all blocked by jackd; ich jackd stops, other APIs would become available again) gfmasdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] uploading Pd git repository to sourceforge
On 15/07/10 17:08, IOhannes zmölnig wrote: On 07/12/2010 05:33 AM, Miller Puckette wrote: o Pd developers -- is it only me that cannot open files via open? No, I got this error too. Command line -open is what I used so far, but obviously unsatisfactory. i get: snip bad option -cursor: Claude ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-3011285 ] fix gl_goprect logic
Patches item #3011285, was opened at 2010-06-03 19:54 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3011285group_id=55736 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: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: fix gl_goprect logic Initial Comment: Based on a patch from Ivica Ico Bukvic, this change seems to help the GOP red rectangle get set more accurately, and according to Ivica also helps with other GOP bugs. I checked it into Pd-extended 0.42.5 here: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revrevision=13586 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=3011285group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-2848888 ] (0.43) Windows/Cygwin/MinGW build fixes
Patches item #284, was opened at 2009-09-02 01:29 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=284group_id=55736 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: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: (0.43) Windows/Cygwin/MinGW build fixes Initial Comment: In order to build on Cygwin and MinGW cleanly and with a simple build system, the macro 'MSW' should be replaced with the automatic macro '_WIN32' (the preceeding underscore is important). It should be replaced in all .c and .h files, and can be done using a simple replace, like sed -i 's|MSW|_WIN32|' *.[ch]. Then the patch attached fixes a couple of minor Cygwin-specific macro tests. Also, once MSW is replaced with _WIN32, then this chunk of code can also be removed from m_pd.h: /* old name for MSW flag -- we have to take it for the sake of many old nmakefiles for externs, which will define NT and not MSW */ #if defined(NT) !defined(MSW) #define MSW #endif -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-15 17:40 Message: almost all of this has been accepted into 0.43 -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-10-28 13:35 Message: Ok, these patches are pretty messy in their current form. Miller, let me know whether you want cleaned up patches, or whether you just want to take this stuff directly from the pd-gui-rewrite/0.43 branch. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-09-03 16:11 Message: Wait, there's more! Its a tiny one.ASIO is C++, so Pd should use g++ when including ASIO, therefore everything needs to build with g++. From what I've read, when linking C++ into C, then main() needs to be compiled with g++ and everything needs to be linked using g++. So, this newest fix is just a one-liner that g++ pointed out in its strictness. Basically there is a malloc() that isn't cast in u_pdreceive.c: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-gui-rewrite/0.43/src/u_pdreceive.c?r1=12232r2=12231pathrev=12232 -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-09-02 18:57 Message: Ok, so now I had to sort out the HAVE_UNISTD_H define, that one was basically being used as: #ifndef _WIN32, so I put that in instead. MinGW has unistd.h, so HAVE_UNISTD_H was causing issues. But MinGW is WIN32 API, so it doesn't have all the UNIXy stuff. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=284group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-2886889 ] (0.43) build fixes for Android, clean up for Linux/BSD
Patches item #2886889, was opened at 2009-10-27 00:41 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=2886889group_id=55736 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: Closed Resolution: Accepted Priority: 7 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: (0.43) build fixes for Android, clean up for Linux/BSD Initial Comment: Android seems to be an odd mix of Linux and BSD. In the process of porting Pd to android, I found a few inconsistencies: - int32 was being using in UNIX land, when int32_t should be used there (int32 is Windows and IRIX) - int32_t should come from stdint.h not sys/types.h - sighandler_t is not defined in Android, but sig_t is defined in Linux, MacOSX, and Android I checked these on Ubuntu 9.04, Mac OS X 10.5.8, Cygwin, MinGW, OpenBSD, and Android. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-15 17:52 Message: accepted in 0.43.0-test1 -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-01 21:05 Message: FYI: this patch has already been included in the pd-gui-rewrite/0.43 branch: https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=2886889group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] uploading Pd git repository to sourceforge
Should be fixed now (in git repo) thanks Miller On Thu, Jul 15, 2010 at 12:38:59PM -0700, Miller Puckette wrote: Sure enough... will debug. thanks M ` On Thu, Jul 15, 2010 at 08:18:41PM +0100, Claude Heiland-Allen wrote: On 15/07/10 17:08, IOhannes zm?lnig wrote: On 07/12/2010 05:33 AM, Miller Puckette wrote: o Pd developers -- is it only me that cannot open files via open? No, I got this error too. Command line -open is what I used so far, but obviously unsatisfactory. i get: snip bad option -cursor: Claude ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1944380 ] fixed help patch for plugin~
Patches item #1944380, was opened at 2008-04-16 17:19 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1944380group_id=55736 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: bugfix Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: fixed help patch for plugin~ Initial Comment: The plugin~ object was incorrectly using a [print message. By reading the source, I saw that it should have been using an [info message. I changed this and added [print] objects so that the output in response to the info messages can be seen. I added attribution of this fix to the file, which you can feel free to remove if it is inappropriate. -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-15 18:18 Message: this should be fixed in SVN and Pd-extended 0.42.5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1944380group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1836228 ] [patch] simplify pd_makeversion() in src/s_main.c
Patches item #1836228, was opened at 2007-11-21 23:37 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1836228group_id=55736 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: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Miller Puckette (millerpuckette) Summary: [patch] simplify pd_makeversion() in src/s_main.c Initial Comment: This minor patch simplifies the pd_makeversion() function in src/s_main.c. It replaces the sprintf / malloc / strcpy, with the equivalent single call to asprintf. It also provides the side benefit of removing the length limitation introduced by the intermediary stack buffer (with bounds that weren't being checked). -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-15 19:36 Message: this is implemented completely differently in 0.43, so this is out-of-date. -- Comment By: Russell Bryant (russellbryant) Date: 2008-01-05 23:30 Message: Logged In: YES user_id=1942915 Originator: YES File Added: makeversion.patch2.txt -- Comment By: Russell Bryant (russellbryant) Date: 2008-01-05 23:29 Message: Logged In: YES user_id=1942915 Originator: YES Actually, I mean sprintf to snprintf. Anyway, here is an updated patch that includes the change from sprintf to snprintf, as well as a simplification to use strdup() instead of malloc/strcpy. -- Comment By: Russell Bryant (russellbryant) Date: 2008-01-05 23:26 Message: Logged In: YES user_id=1942915 Originator: YES Well, it turns out that asprintf() is a GNU extension, and is not a part of standard C or POSIX. So, this probably will not be acceptable. However, I'd like to still leave it open, as I'd like to see the strcpy changed to strncpy ... -- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-23 14:24 Message: Logged In: YES user_id=27104 Originator: NO Funny, I originally submitted the patch with this function and it included asprintf(). Miller accepted the patch, but replaced the asprintf() with the sprintf/malloc/strcpy combo, with only this comment: modified to avoid the effete asprintf() call, then took for 0.40 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478072aid=1836228group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
