Pd-dev December 2006

pd-dev@lists.iem.at

22 participants
74 discussions

[ pure-data-Patches-1608063 ] Trouble building on Mac OS X (patch included :)
by SourceForge.net 11 Dec '06

11 Dec '06

Patches item #1608063, was opened at 2006-12-03 20:58 Message generated for change (Comment added) made by kunowoudt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1608063&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: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Trouble building on Mac OS X (patch included :) Initial Comment: I mistakenly installed OS X on a case-sensitive file system. It seemed the most logical to me, but I later learned that that is not the default. This has exposed that some of the mac related #includes rely on a case-insensitive file-system. IMO that is a bug, and I have attached a patch which fixes those which I found in the pd-extended source tree. Note that the patch also includes some other small Mac OS X build related changes to the Makefile: I had some trouble with the Makefile in packages/darwin_app doing 'mv' and 'ln' to files which already exist, which resulted in either [y/n] prompts to overwrite a file or just the Makefile aborting. ---------------------------------------------------------------------- Comment By: kuno (kunowoudt) Date: 2006-12-11 17:52 Message: Logged In: YES user_id=1174173 Originator: NO Thank you for fixing!. I've submitted the patch for only the gem related files to the sourceforge bugtracker for GEM now. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-12-04 00:39 Message: Logged In: YES user_id=27104 Originator: NO I fixed the case problems in externals/io/hidio/HID Utilities Source/HID_Utilities.h and externals/hcs/hid/HID Utilities Source/HID_Utilities.h as well as packages/darwin_app/Makefile. The "rm" stuff is handled by the "package_clean" target, so I didn't include that stuff from the patch. The Gem stuff should be submitted as its own patch. In general patches should only cover very specific sections of code, as specific as possible. ---------------------------------------------------------------------- Comment By: kuno (kunowoudt) Date: 2006-12-03 21:07 Message: Logged In: YES user_id=1174173 Originator: NO Woops, forgot to login. bug submitted by me <kuno(a)frob.nl>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1608063&group_…

1 0

branching doc
by Hans-Christoph Steiner 11 Dec '06

11 Dec '06

I started with the advice from Jonas Bülow and edited it to reflect the version tags used in Pd and made it into a wiki page. Please edit/add as appropriate: http://puredata.org/docs/developer/Branching .hc ------------------------------------------------------------------------ All information should be free. - the hacker ethic

1 0

[ pure-data-Patches-1612910 ] Patch to OSCx to support multicast
by SourceForge.net 11 Dec '06

11 Dec '06

Patches item #1612910, was opened at 2006-12-10 22:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1612910&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: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Sinclair (radarsat1) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to OSCx to support multicast Initial Comment: Hello, I needed to try some multicast stuff with Pd, but found that the OSCx externals didn't support it, so I made some small changes. Just thought I'd send it along in case it is useful to someone else. [sendOSC] can now take an optional TTL argument in its "connect" message. This is "Time To Live" which says how many jumps the UDP packet is allowed to make before dying out. Without setting this, multicast only works on the local LAN. [dumpOSC] can now take an optional "Group" argument _before_ the port number. (I put it before for consistancy with sendOSC.) For example: [dumpOSC 224.0.1.1 7879] When this argument is provided, it will join the given multicast group. (using setsockopt) Tested so far on Linux (Ubuntu Dapper) and OS X 10.4.8 ppc. I also modified configure.ac a little to make it work properly with Pd-0.40-2.app on OS X. Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1612910&group_…

1 0

Multicast for OSCx
by Stephen Sinclair 11 Dec '06

11 Dec '06

Hello, I needed to try some multicast stuff with Pd, but found that the OSCx externals didn't support it, so I made some small changes. Just thought I'd send it along in case it is useful to someone else. [sendOSC] can now take an optional TTL argument in its "connect" message. This is "Time To Live" which says how many jumps the UDP packet is allowed to make before dying out. Without setting this, multicast only works on the local LAN. [dumpOSC] can now take an optional "Group" argument _before_ the port number. (I put it before for consistancy with sendOSC.) For example: [dumpOSC 224.0.1.1 7879] When this argument is provided, it will join the given multicast group. (using setsockopt) Tested so far on Linux (Ubuntu Dapper) and OS X 10.4.8 ppc. I also modified configure.ac a little to make it work properly with Pd-0.40-2.app on OS X. Steve

2 1

supporting MSVC6
by Mathieu Bouchard 10 Dec '06

10 Dec '06

On win32, is there any reason for still supporting MSVC6 instead of switching to MinGW and/or Cygwin? For example, any binary-only externals that only work with a MSVC6-compiled pd... or some other library in that situation. _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

4 5

loader: 0.40 or devel_0_39 ?
by Mathieu Bouchard 10 Dec '06

10 Dec '06

I see that the loader code in Miller's 0.40, Miller's 0.39 and devel_0_39 are completely different. This means that the diff between the first two and the diff between the latter two, have a lot of conflicts that can't be fixed without sitting down and figuring out what should be done. So, my question is, is everybody satisfied by Miller's 0.40's s_loader.c ? If yes, then I can just use that. Else, how should some devel_0_39 features be added to it? I'm thinking specifically of the altname parameter, which doesn't appear at all in Miller's. What is it useful for? _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

3 4

Re: [PD-dev] branching advice
by Hans-Christoph Steiner 09 Dec '06

09 Dec '06

Since Thomas is talking about branches, I thought I would forward this advice I received off-list. I think it makes a lot of sense: On Nov 2, 2006, at 9:00 AM, Jonas Bülow wrote: > Hi, > > I have some 8 years of using CVS for 40-50 modules. As I understand > you understand it is of great importance to have a good policy > working with branches in CVS. > > My principles for branches (shared by many others) can be > summarized as: > > - set a ordinary tag on the branch point, name it BRANCHED_VX_Y > - create a branch on the branchtag, call if BRANCH_VX_Y > > Now, when you want to find what has happend on your branch you can > diff from the branch point to the branch head by doing > > cvs diff -r BRANCHED_VX_Y -r BRANCH_VX_Y > > Many people forget to create a tag where the branch is created > which makes it hard to syncronize between branches. > > VX_Y is a symbol for the prefix of the version, i.e V0_39. V0_39_1 > is then a tag on the branch. > > Main development is performed on the main trunk. I.e with the above > example there are no tags starting with V0_39 on the main trunk > after the tag BRANCHED_V0_39. The first tag should be an increment, > e.g V0_40 or higher. > > CVS is not very user friendly doing merges between branches. The > first merge beteen branches is simple, just use the BRANCHED_VX_Y- > tag. merging the work on the branch BRANCH_VX_Y to HEAD (symbolic > name for main trunk) by doing "cvs update -j BRANCHED_V0_39 -j > V0_39_1" in HEAD. > > If you do incremental merges from one branch to another you need to > manually keep track of points of merge. A good habit is to tag > these point as MERGED_FROM_xxx on the target and MERGED_TO_xxx on > the source. The next time you to a merge you use one of these tags > to refere to from where the merge should be done. > > Hans-Christoph Steiner wrote: >> On Oct 30, 2006, at 3:24 PM, IOhannes m zmölnig wrote: >>> Hans-Christoph Steiner wrote: >>>> Anyone have any good advice on making a branch in CVS? Or >>>> perhaps a good HOWTO? Its time to make a branch for the >>>> Pd-0.39.2-extended release. >>> >>> what is your exact problem? >>> >>> how does "cvs tag -b extended_0_39_2" (within the cvsroot) not >>> fit your needs? >>> >>> >>> btw, googling for "cvs tag" returned http://www.psc.edu/~semke/ >>> cvs_branches.html as the second hit (the first one was a dead link) >>> >>> there is no magic involved in tagging. >>> >>> btw, i thought someone mentioned a "best practice CVS" document a >>> while ago ;-) >> I know tagging, that's dead simple. I am talking about a branch. >> I can google "cvs tag" or "cvs branch" myself too, but a personal >> recommendation is worth a lot more than a google search. >> I am more interested in experience in managing changes in the >> branch. Some changes should get folded in to MAIN, others are >> only for the branch. I am sure there are things that you can do >> that will make your life easier when the time to merge comes. >> .hc >> --------------------------------------------------------------------- >> --- >> All information should be free. - the hacker ethic >> _______________________________________________ >> PD-dev mailing list >> PD-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev >> <jonas.bulow.vcf> ------------------------------------------------------------------------ http://at.or.at/hans/

2 1

slowing down dsp function inside perform loop
by Eric Lyon 08 Dec '06

08 Dec '06

Greetings, Is there anything in Pd comparable to MaxMSP's defer_low() mechanism? As I understand it, defer_low() will force a function to proceed at a more leisurely pace to assure that it doesn't crowd out the highest-priority DSP operations. In terms of observed performance, when the function in question was run with a regular function call in MaxMSP, it resulted in all kinds of horrible glitching in the audio playback. After running it through defer_low() everything worked quite smartly. In Pd, running the function with a regular function call simply crashes Pd after a few seconds of operation. TIA, Eric

9 17

SourceForge has some more problems.
by Mathieu Bouchard 07 Dec '06

07 Dec '06

Trying to use cvs tonight, I get one of three problems: 1. Sometimes it rejects my correct password 2. Sometimes it aborts due to a locked file. 3. The rest of the times, it accepts the commit, but borks the message to pd-cvs(a)iem.at: cvs commit TODO ChangeLog matju(a)pure-data.cvs.sourceforge.net's password: Checking in TODO; /cvsroot/pure-data/pd/src/Attic/TODO,v <-- TODO new revision: 1.1.2.28.2.2; previous revision: 1.1.2.28.2.1 done Checking in ChangeLog; /cvsroot/pure-data/pd/src/Attic/ChangeLog,v <-- ChangeLog new revision: 1.1.4.11.2.4; previous revision: 1.1.4.11.2.3 done Mailing pd-cvs(a)iem.at... Generating notification message... Generating notification message... done. Mailing pd-cvs(a)iem.at... Generating notification message... Traceback (most recent call last): File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ? main() File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 426, in main contextlines, fromhost, replyto) File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 224, in blast_mail pwinfo = pwd.getpwuid(os.getuid()) KeyError: 'getpwuid(): uid not found: 151795' _ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada

1 0

dsp_tick() in d_ugen.c
by Jarbas Jacome 06 Dec '06

06 Dec '06

Hello, brothers! Tudo beleza? I'm trying to understand the DSP scheduling. I think my questions are similar to Tim Blechmann ones two years before: http://lists.puredata.info/pipermail/pd-dev/2004-04/002407.html Please, help me: someone calls canvas_dodsp function (question 1: who? when?) g_canvas.c canvas_dodsp (...) { /* create a new "DSP graph" object to use in sorting this canvas. dc = ugen_start_graph(...); /* finally, sort them and add them to the DSP chain */ ugen_done_graph(dc); } d_ugen.c ugen_done_graph (...) { ugendoit() for each unit } ugen_doit (...) { calls mess1(&u->u_obj->ob_pd, gensym("dsp"), insig) --> question 2: This is calling dsp_add() to add each dsp object perform function in dsp_chain. Isnt it? question 3: So, does it call "canvas_dodsp" when the object is the canvas? (If yes this answers question 1). :D } But my main doubt is: question 4: where is the code which finally execute the dsp calculations, i. e. the code which call the perform functions of each object? I think is this one, called by Pd main loop: m_scheduler() which calls sched_tick() which calls dsp_tick() void dsp_tick(void) { if (dsp_chain) { t_int *ip; for (ip = dsp_chain; *ip; ) ip = (*(t_perfroutine)(*ip))(ip); ---> chain execution? dsp_phase++; } } is it correct? THANX, BRO! j.jR.

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 2006