Pd-dev June 2003

pd-dev@lists.iem.at

20 participants
20 discussions

new pure-data.org
by Hans-Christoph Steiner 12 Jun '03

12 Jun '03

The pure-data.org discussion seems to have died down. So I guess its time to start implementing, if the IEM Plone is ready. There is a basic architecture on the Wiki http://pd.iem.at/pdwiki/index.php?PdComunitySite , that has gone through a couple revisions. It seems like a good starting point for implementation. I am ready to start, who's on board? .hc

4 4

including linux-only externals in build system
by Hans-Christoph Steiner 10 Jun '03

10 Jun '03

I have written a few objects for the linux input event system and the iFeel mouse that I would like to include in the build/debian package system, but these objects are linux-only and always will be (I am working on separate cross-platform versions). So in build/src/, should I do this: #ifdef LINUX #include "../hcs/ifeel.c" #endif or is there a better way? .hc

1 0

rebinding tab and shift-tab in dialog windows
by Krzysztof Czaja 09 Jun '03

09 Jun '03

hi all, the diff below (against 0.36) patches Tab/Shift-Tab behaviour: . clears the actual binding for shift-tab . restores the bindings in iemgui_dialog window (the same could be done in other dialogs, but let this patch be tested by others first). Also included are the two fixes previously reported: . tcl/tk 8.4 map event fix . mozilla/netscape fix Krzysztof --- ../src/u_main.tk 2002-11-28 06:58:14.000000000 +0100 +++ pd.tk 2003-06-07 15:07:00.000000000 +0200 @@ -34,7 +34,7 @@ # "text" dialogs below. Also we have to get rid of tab's changing the focus. bind all <Key-Tab> "" -bind all <Shift-Key-Tab> "" +bind all <<PrevWindow>> "" bind Text <Control-t> {} bind Text <Control-s> {} # puts stderr [bind all] @@ -234,6 +234,7 @@ proc menu_documentation {} { global help_directory + global pd_nt set filename [tk_getOpenFile -defaultextension .pd \ -filetypes { {{documentation} {.pd .txt .htm}} } \ @@ -831,7 +832,7 @@ bind $name.c <KeyRelease> {pdtk_canvas_keyup %W %K %A} bind $name.c <Motion> {pdtk_canvas_motion %W %x %y 0} bind $name.c <Alt-Motion> {pdtk_canvas_motion %W %x %y 4} - bind $name.c <Map> {pdtk_canvas_map %W %s} + bind $name.c <Map> {pdtk_canvas_map %W 0} # bind $name.c <Unmap> {puts stderr map} focus $name.c # puts stderr "all done" @@ -2187,6 +2188,14 @@ label $id.space5 -text "" pack $id.space5 -side top + if {[info tclversion] < 8.4} { + bind $id <Key-Tab> {tkTabToWindow [tk_focusNext %W]} + bind $id <<PrevWindow>> {tkTabToWindow [tk_focusPrev %W]} + } else { + bind $id <Key-Tab> {tk::TabToWindow [tk_focusNext %W]} + bind $id <<PrevWindow>> {tk::TabToWindow [tk_focusPrev %W]} + } + bind $id.dim.w_ent <KeyPress-Return> [concat iemgui_ok $id] bind $id.dim.h_ent <KeyPress-Return> [concat iemgui_ok $id]

2 2

strict aliasing trouble
by Krzysztof Czaja 07 Jun '03

07 Jun '03

hi, -Wno-strict-aliasing flag is required for compiling current Pd source with gcc-3.3. In principle, due to strong optimization, it would be better not to set this flag, but patch the offending code instead. The iemgui constructors might easily be patched by union-wrapping t_iem_init_symargs and t_iem_fstyle_flags, but there is the PD_BADFLOAT macro too... What shell we do? Krzysztof

1 0

pure-data.org int'lization
by Hans-Christoph Steiner 06 Jun '03

06 Jun '03

So, since pure data seems to be in use around the world, I think it would be good to include some non-English resources in the new pure-data.org. Plone already supports many languages, but I think we need to add multi-lingual content as well. I have a started a list of docs that I think should be incorporated into the new pure-data.org: http://pd.at.or.at/pddocs.html Please send stuff my way if you think it should be added to this. .hc zen \ \ \[D[D[D[D

1 0

Re: [PD-dev] new pure-data.org
by Marc Lavallée 06 Jun '03

06 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans-Christoph Steiner wrote: > http://pd.iem.at/pdwiki/index.php?PdComunitySite I didn't realised there was a list of voluntaries. > I am ready to start, who's on board? I'm about to learn Plone for other web sites, and I'd like to help. - -- Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+4CE9QdzoeKQ0PccRAoZFAJ9NmNs3JisZ3w9WCfxYfHz0OFBxuQCg5Sip 5bGc4Sqcipgzg2Oz93MD0a8= =04RX -----END PGP SIGNATURE-----

1 0

Re: [PD-dev] External Manager - Load my Externals
by bbogart＠ryerson.ca 04 Jun '03

04 Jun '03

I entirely disagree, #1 its in the menu of PD: One starts PD, then changes the settings, if s/he wants to use the new setting (if s/he does not want to, why is s/he changing them?) so s/he quits PD and starts it again. #2 its a separate program: (a) Changes settings One starts the launcher, changes the settings, and hits the "launch PD" button. (b) Using the default settings One clicks on the shortcut or runs the script (created by the launcher) for the default options. One the user has created a number of config sets, then they don't use the launcher except to tinker with the settings. At worst having it in the start is an extra click. (the PD launch button) At worst having it in the menu is quiting and waiting for PD to start again (anoying if it has lots of libs, on slower machine) I'm failing to see a strong counter argument to having it a separate program. perhaps I'm missing a point, I really want the software to be as clean to the user as possible, restarting PD to change settings is simply a pain. Thanks for the thinking and critisism, keep it coming! Ben ----- Original Message ----- From: Frank Barknecht <fbar(a)footils.org> Date: Saturday, May 31, 2003 1:28 pm Subject: Re: [PD-dev] External Manager - Load my Externals > Hallo, > bbogart(a)ryerson.ca hat gesagt: // bbogart(a)ryerson.ca wrote: > > > I think a home on the PD menu would be a great place for this > > project, IF PD could load externals and change flags on the fly. > > (without restarting) without this having it the menu would make > > little sense, if It is to be integrated into PD without the ability > > to do this then it would be a kind of splash page, starting up > > before PD, but then how to deal with loading and saving multiple > > configuration sets? I think the most elegant solution would be to > > run it seperate from PD. Mind you I think it would be amazing if PD > > would load/remove libs and change audio settings on the fly, is this > > even possible? > > Even without this - i.e. with restarting Pd - this would be best > placed into a Pd-window menu. The reason is mostly usability. An > external launcher would be another program to run. > > ciao > -- > Frank Barknecht _ ______footils.org__ > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

7 18

space in label bug in slider properties
by jfm3＠ouroboros-complex.org 04 Jun '03

04 Jun '03

If I put a space in a label for a slider, the rest of the properties get all weird. I thought I reported this before and someone came up with a relatively simple fix... (jfm3)

3 2

Re: [PD-dev] External Manager - Load my Externals
by bbogart＠ryerson.ca 03 Jun '03

03 Jun '03

Thanks for the critisism Guenter, I agree, a preferences dialog is ideal (and what I want, and I'd start writing it now If I knew enough about PD internals to do so). Yes you are right that a launcher shines when one worries about libraries. Single externals have a lot of advantages, but can we get rid of libraries altogether? Collections of related objects, like Gem for example. The new chaos release will have code shared between the objects. I guess the question is will the number of libs drop to some amount small enough to be managable? different PD config files would be a great feature, very nice if a menu of them came up when you start PD (if desired) Great that Miller is going this way, changing stuff on the fly fantastic! So where does that leave us? There is still a need for such a program, at least at this time. Is it worth the effort to develop it when it would be phased out by PD functionality soon.. Well the hope is that the code, or some part thereof, would end up being integrated into PD. Another reason we're planning on using tcl. I think it would be valid to create the LME, if its code could be resued in PD, and if it will be a year or more before on-the-fly parameter changing and the death of massive lib mamagement. Just to focus the discussion one more time: The idea came up when Matt and I taught a PD workshop. We did the installation of Gem as part of the workshop, and it was far beyond the skills of most people interested in using the software, to add the damn -lib Gem flag to the .pdrc (which is a painful file to edit without terminal!) I myself tried talking through the shortcut creation (under windows) process to one of the workshop memebers, it took 30min!!!! and that was only one library... Is LME worth pursuing or not? Ben ----- Original Message ----- From: guenter geiger <geiger(a)xdv.org> Date: Monday, June 2, 2003 5:05 am Subject: Re: [PD-dev] External Manager - Load my Externals > Ok, some (critical) thoughts: > > * Preferences: again, a launcher is a bad idea IMO, it should be a > preference dialog. > Don't think about software being written once and then its done. > If you have the launcher, you will want to have preferences sooner > or later, ... > > * External loader comes from the concept of having libraries. I have > mentioned several times that this is not a good way how to > write externals, because it merely adds complexity in the > build processes and uses up more RAM. > > We should get rid of the concept of libraries. (Hide the "external > loader" in a "advanced" tab if you like, but don't write a program > that is an "external loader" above all). > > * Different configurations: I think this is a very good concept and > should be easy to add by using different names for pd config files. > > Last but not least, Miller is already thinking about preferences, > expecially for audio settings, and changing them on the fly is not > too far away ... > > Guenter > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.kug.ac.at > http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev >

2 1

devel_0_37 branch
by guenter geiger 03 Jun '03

03 Jun '03

Hi there ! I just opened the devel_0_37 branch on CVS. There are not too many differences between Millers version and this one. - configure.in checks for tcl/tk headers again (this is needed for Debian mainly). - the tcl/tk 8.4 patch - JACK support as s_audio_jack.c (until jack support works in portaudio) I have not yet included any of the patches from devel_0_37, mainly because several have already been there (thanks Miller, I hope it wasn't too much of a pain to incorporate them. If so, let us now, and we will try to find a better procedure). I am going to incorporate some of the (small) changes that are needed for cross platform linux stuff (SPARC, IA64, etc, etc, ..). If an important feature is missing (some of Thomas threading stuff ??) please let us discuss it. A last thing, Frank , you said ALSA does not work on 0.37, but it should, because there is still native ALSA support. The CVS devel_0_36 had a slighlty different ALSA implementation which made it possible to use the Hammerfall HDSP, should we use incorporate that ? Well, thats it, happy hacking Guenter

5 12

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 2003