Re: [PD-dev] naming loaders: pdlua, tclpd, etc.
On Fri, 14 Mar 2008, Albert Graef wrote: In Pd/Q this is done differently; there's only one main script which defines all the Q objects in a patch (which are in fact just Q functions), but this script can be reloaded dynamically through a special "q" receiver. This operation is a bit on the heavy side, but in Q you can also create new functions at runtime, so with a little preparation you can also change the behaviour of objects written in Q by just sending them Pd messages encoding Q functions, for instance. Sounds a lot like GridFlow and the loading of ~/.gridflow_startup. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Leopard builds?
Excellent! Let me know if you need anything. I am on IRC a lot these days, #dataflow. .hc On Mar 17, 2008, at 10:02 PM, bsoisoi wrote: Hi All, From what I can see, it appears I have a successful OS X 10.5 pd- extended development environment. I was able to build all dependencies with Fink 0.28.1. I'll let you know when I'm able to get the full piece built. Thanks ~Brandon On Mar 15, 2008, at 4:51 PM, bsoisoi wrote: Hi all, I'll update you with what I passed to Hans the other day. Work has been very demanding lately (I'm a developer for a non- profit organization), we have a big release coming up so I've been working overtime. I will try again this weekend, and will report back to you. Cheers, ~Brandon On Mar 11, 2008, at 5:26 PM, Hans-Christoph Steiner wrote: I was talking more about nightlies on Leopard/Intel which bsoisoi was working on. I don't really know whether Leopard- specific builds are needed. .hc On Mar 11, 2008, at 5:15 PM, chris clepper wrote: Are builds specific to 10.5 needed? Everything I've built recently on 10.4 works fine on the newer OS. On Tue, Mar 11, 2008 at 4:02 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: Any word on the Leopard builds? That would be quite nice to have. .hc --- - Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ 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 Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Leopard builds?
Hi All, From what I can see, it appears I have a successful OS X 10.5 pd- extended development environment. I was able to build all dependencies with Fink 0.28.1. I'll let you know when I'm able to get the full piece built. Thanks ~Brandon On Mar 15, 2008, at 4:51 PM, bsoisoi wrote: Hi all, I'll update you with what I passed to Hans the other day. Work has been very demanding lately (I'm a developer for a non- profit organization), we have a big release coming up so I've been working overtime. I will try again this weekend, and will report back to you. Cheers, ~Brandon On Mar 11, 2008, at 5:26 PM, Hans-Christoph Steiner wrote: I was talking more about nightlies on Leopard/Intel which bsoisoi was working on. I don't really know whether Leopard-specific builds are needed. .hc On Mar 11, 2008, at 5:15 PM, chris clepper wrote: Are builds specific to 10.5 needed? Everything I've built recently on 10.4 works fine on the newer OS. On Tue, Mar 11, 2008 at 4:02 PM, Hans-Christoph Steiner <[EMAIL PROTECTED] > wrote: Any word on the Leopard builds? That would be quite nice to have. .hc Mistrust authority - promote decentralization. - the hacker ethic ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev The arc of history bends towards justice. - Dr. Martin Luther King, Jr. ___ 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-Bugs-1917574 ] declare not working on osx
Bugs item #1917574, was opened at 2008-03-17 21:01 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=1917574&group_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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Nobody/Anonymous (nobody) Summary: declare not working on osx Initial Comment: I am not sure if declare is working the way it is supposed to on OSX the object I am trying to create is [OSCroute]. I can create [oscx/OSCroute], but what I want to accomplish is to avoid the oscx prefix, so I tried [declare -stdpath extra/oscx] [declare -stdpath oscx] [declare -path extra/oscx] [declare -path oscx] [declare -stdlib extra/oscx] [declare -stdlib oscx] [declare -lib extra/oscx] [declare -lib oscx] I even tried [declare -stdpath extra/oscx] in combination with import oscx. and I get a console printout saying [import] loaded library: oscx, but OSCroute ... couldn't create don't know how to track down the error, or if I am maybe doing something wrong. pd-extended-0.40.3-20080222. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1917574&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] using rand() in an external
On Sun, 16 Mar 2008, Greg Surges wrote: The following code crashes Pd when the randomwalk object receives a bang... I'm stuck as to why, can anyone see a reason? check that x->f_out is really set to a return value of outlet_new. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1912314 ] [import] doesn't seem to add pathes
Bugs item #1912314, was opened at 2008-03-11 20:24 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1912314&group_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: pd-extended Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Hans-Christoph Steiner (eighthave) Summary: [import] doesn't seem to add pathes Initial Comment: tested with: Pd version 0.40.3-extended-20080308 which is installed in: /home/roman/pd-extended-0.40/usr/local/bin/pd (don't know if this infor useful. i think i should mention it, because usually it is installed in /usr/local/bin/pd) [import iemmatrix] prints: [import] loaded library: iemmatrix however, when i load this patch: [import iemmatrix] [matrix] - [matrix] doesn't get instantiated, but outputs the error: matrix ... couldn't create instantiating [iemmatrix/matrix] works fine, though. also this patch loads fine: --- [declare -stdpath extra/iemmatrix] [matrix] --- i tested the same with 'tof' and [destroysend] from the library 'tof' and got similar results. -- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-03-17 18:22 Message: Logged In: YES user_id=27104 Originator: NO caused by custom install location on GNU/Linux -- Comment By: Roman Haefeli (reduzent) Date: 2008-03-11 21:38 Message: Logged In: YES user_id=1895440 Originator: YES it turned out, that this behaviour is indeed related to the non-standard install location. it also turned out, that on linux several things in pd won't work as expexted, if pd is _not_ installed in the directory, where it was compiled for (unlike windows, where pd can be put to an arbitrary place while still everything works fine). sorry for the noise and bogus bug report -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1912314&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
First, you register a function with clock_set(). Usually that function is called myobjectname_tick(). Then when it runs, you call clock_delay() to schedule when myobjectname_tick() will get called again. .hc On Mar 17, 2008, at 4:49 PM, Greg Surges wrote: Thanks Claude and Georg, It looks like this is the right track... Looking at the metro code, I'm a little confused as to how the object continues to output bangs after the first. What does it mean that clock_delay "calls back"? Thanks On Mon, Mar 17, 2008 at 3:13 PM, Claude Heiland-Allen <[EMAIL PROTECTED]> wrote: Greg Surges wrote: > Hi all, > > Is there any way to have an external call a method periodically, without > being triggered? Clocks. Check the C API in "m_pd.h".. > I'm thinking of a histogram with a decay function, where the values are > decremented every second (or other time value). I've done something like this with Lua, although I had the decrementing done by a [gemhead] not an internal clock, for tighter syncing with visuals. That's what made the keys fade from orange->grey->blue, if you happened to be at LAC Club Night during my set. > Thanks! > > -Greg Claude -- http://claudiusmaximus.goto10.org -- http://www.uwm.edu/~gssurges/ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev Using ReBirth is like trying to play an 808 with a long stick.- David Zicarelli ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
Hallo, Greg Surges hat gesagt: // Greg Surges wrote: > It looks like this is the right track... > > Looking at the metro code, I'm a little confused as to how the object > continues to output bangs after the first. What does it mean that > clock_delay "calls back"? When you create a new clock with clock_new, you pass it a method "fn": EXTERN t_clock *clock_new(void *owner, t_method fn); "fn" is the callback method, that gets called, if you later run "clock_delay" with your clock and the delaytime. It gets "owner" passed as argument, so it's called as: "fn(owner)" In the metro-code, the clock is created in metro_new: x->x_clock = clock_new(x, (t_method)metro_tick); Here "metro_tick" get registered as the callback method of clock "x->c_clock". Then "metro_float" is responsible to start the metro, which is made by calling "metro_tick(x)" directly once, if the incoming float is not 0. After that, "metro_tick" kind of calls itself over and over again using "clock_delay(x->x_clock, x->x_deltime);": Each time, "clock_delay" is called, it waits for x->x_deltime to then call the registered method, "metro_tick(x)", again. You use clock_unset to stop the clock, and clock_free to destroy and free it completely. It may be easier to first understand how [delay] works, as it's a bit simpler. And for a more complicated object, try to figure out how [pipe] works. ;) Ciao -- Frank Barknecht _ __footils.org__ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
Thanks Claude and Georg, It looks like this is the right track... Looking at the metro code, I'm a little confused as to how the object continues to output bangs after the first. What does it mean that clock_delay "calls back"? Thanks On Mon, Mar 17, 2008 at 3:13 PM, Claude Heiland-Allen < [EMAIL PROTECTED]> wrote: > Greg Surges wrote: > > Hi all, > > > > Is there any way to have an external call a method periodically, without > > being triggered? > > Clocks. Check the C API in "m_pd.h".. > > > I'm thinking of a histogram with a decay function, where the values are > > decremented every second (or other time value). > > I've done something like this with Lua, although I had the decrementing > done by a [gemhead] not an internal clock, for tighter syncing with > visuals. That's what made the keys fade from orange->grey->blue, if you > happened to be at LAC Club Night during my set. > > > Thanks! > > > > -Greg > > > Claude > -- > http://claudiusmaximus.goto10.org > > -- http://www.uwm.edu/~gssurges/ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
Hallo! Greg Surges schrieb: > Hi all, > > Is there any way to have an external call a method periodically, without > being triggered? > I'm thinking of a histogram with a decay function, where the values are > decremented every second (or other time value). Clocks can be used to do that. Look e.g. at the code of the metro object in pd core. You could also look at externals/grh/threadlib/callbacks.c, but I guess it's easier to understand it in the metro object code. LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Calling a method periodically
Greg Surges wrote: > Hi all, > > Is there any way to have an external call a method periodically, without > being triggered? Clocks. Check the C API in "m_pd.h".. > I'm thinking of a histogram with a decay function, where the values are > decremented every second (or other time value). I've done something like this with Lua, although I had the decrementing done by a [gemhead] not an internal clock, for tighter syncing with visuals. That's what made the keys fade from orange->grey->blue, if you happened to be at LAC Club Night during my set. > Thanks! > > -Greg Claude -- http://claudiusmaximus.goto10.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Calling a method periodically
Hi all, Is there any way to have an external call a method periodically, without being triggered? I'm thinking of a histogram with a decay function, where the values are decremented every second (or other time value). Thanks! -Greg -- http://www.uwm.edu/~gssurges/ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Bugs-1912242 ] [makefilename %c] broken in some versions
Bugs item #1912242, was opened at 2008-03-11 18:41 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1912242&group_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: pd-extended Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Hans-Christoph Steiner (eighthave) Summary: [makefilename %c] broken in some versions Initial Comment: [makefilename %c] seems to be broken in various autobuilds. this is the test-patch [32( | [makefilename _%c_] | [print] here a short list of pd (extended) versions and the according output: LINUX -- Pd version 0.40.3-extended-20080308: symbol _*_ -- Pd version 0.40.3: symbol _ _ (OK) -- Pd version 0.39.3-extended: symbol _ _ (OK) --- WINDOWS -- Pd version 0.40.3 symbol _ _ (OK) -- MAC OSX 10.5.2 (tested by eni) -- Pd-0.40.3-extended-20071231 print: symbol _4_ -- Pd-0.40.3-extended-20080111 print: symbol _ _ (OK) -- Pd-0.40.3-extended-20080117 print: symbol _ _ (OK) -- Pd-0.41.0 print: symbol _ _ (OK) -- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-03-17 14:41 Message: Logged In: YES user_id=27104 Originator: NO ok, I just checked in the patch that IOhannes mentioned. Please try the autobuilds tomorrow or later. -- Comment By: IOhannes m zm�lnig (zmoelnig) Date: 2008-03-12 03:50 Message: Logged In: YES user_id=564396 Originator: NO i think this is related to the bug introduced by patch-#1688540 and fixed in patch-#1862168 http://sourceforge.net/tracker/index.php?func=detail&aid=1862168&group_id=55736&atid=478072 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1912242&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vamp plugins for PD (GSoC)
Hallo! > Yes, it would be great if some improvements got made to libxtract as a > 'side effect' of the Pd GSoC! Something that might be interesting would > be a set of MIR-inspired abstractions that use the libxtract/aubio > bindings + the Pd machine learning objects ([knn], [ann_mlp], [ann_som]) > to do common tasks - e.g. speech recognition, audio segmentation with > labelling etc. A kind of Pd MIR toolkit. Yes that would be a nice project: first coding the vamp plugin and afterwards a set of abstraction (MIR toolkit) with some common tasks. Then these abstractions would also act as documentation so that pd-people can reproduce the way they work. And if some lower-level features are missing they could be added to libxtract or other VAMP plugins. > Thinking about it, it probably would be a good idea if the vamp host was > developed separately from the PluginHost. Particularly for the purposes > of GSoC, I think projects should stay a manageable size. > The important thing is that the two project teams (VampPlugins, > PluginHost) communicate with each other so that we retain the > possibility to merge the vamp host code into the generalised plugin host > at some later stage if it seems appropriate. Hm ... I am not sure if this is such a good idea. I guess that LADSPA/VST/... plugins are quite different to VAMP plugins, which output control data. Therefore I am not sure if it actually makes sense to combine those plugin hosts ... (of course they could have a similar syntax/interface, so that it's easy to use for users) LG Georg ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] names of 'pd' tags
Hey, http://pure-data.svn.sourceforge.net/viewvc/pure-data/tags/pd/ I just added tags for 0.41.0 thru 0.41.2. Those tags for 'pd' are a bit of a mess, so I would like to propose cleaning them up. First, I think we can ditch the 'pd-' prefix since they are already in a folder called 'pd'. Second, I think we should use the very standard '.' as the separator between numbers. Third, for test releases, we can use the dash, so that they sort before released version. So something like this: pure-data/tags/pd/0.40-test1 pure-data/tags/pd/0.40-test5 pure-data/tags/pd/0.40.0 pure-data/tags/pd/0.40.1 pure-data/tags/pd/0.40.2 pure-data/tags/pd/0.40.3 pure-data/tags/pd/0.41-test5 pure-data/tags/pd/0.41.0 pure-data/tags/pd/0.41.1 pure-data/tags/pd/0.41.2 - I think we should probably also clean up the "pd-0.39-3", "pd-0.39-3-again", "pd-0.39-3-oncemore", , "pd-0.39-3-really" to be just the right 0.39.3. - do we need the test versions listed in the tags? There are only a couple existing anyway. .hc http://at.or.at/hans/ ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vamp plugins for PD (GSoC)
Thinking about it, it probably would be a good idea if the vamp host was developed separately from the PluginHost. Particularly for the purposes of GSoC, I think projects should stay a manageable size. The important thing is that the two project teams (VampPlugins, PluginHost) communicate with each other so that we retain the possibility to merge the vamp host code into the generalised plugin host at some later stage if it seems appropriate. Jamie On Sun, 2008-03-16 at 12:59 -0400, Hans-Christoph Steiner wrote: > It sounds like a very worthwhile project. It doesn't sound too small > to me. If you really are able to get everything working that > quickly, then you could spend the extra time polishing everything so > that it works really easily, then also making sure that there are > docs for it. > > .hc > > On Mar 16, 2008, at 8:29 AM, Georg Holzmann wrote: > > > Hallo! > > > > I just have come over the vamp plugins (http://www.vamp- > > plugins.org) again. > > It is a plugin system for feature extraction, audio analysis and is > > used > > by the Sonic Visualizer, Ardour, Audacity and others ... > > There already exist many plugins (see > > http://www.vamp-plugins.org/download.html and the features listed > > there) > > and it would be definitely nice to have them in pd. > > > > However, it's also not so straight forward to implement a host, > > because > > some plugins need data in frequency domain or in a specific > > blocksize ... > > > > I made a GSoC page where I described it in more details > > (http://puredata.info/dev/summer-of-code/VampPlugins) and would be > > definitely interested in implementing this for GSoC. > > Anyhow, I don't know if this project might be too small ... maybe > > it can > > be also combined with something else ? > > > > LG > > Georg > > > > ___ > > PD-dev mailing list > > PD-dev@iem.at > > http://lists.puredata.info/listinfo/pd-dev > > > > > > Access to computers should be unlimited and total. - the hacker ethic > > > > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev -- www.postlude.co.uk ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] vamp plugins for PD (GSoC)
Hi, On Sun, 2008-03-16 at 19:26 +0100, Georg Holzmann wrote: > For me, as I am interested in DSP and similar things, it would be also > nice to additionally add new or other MIR/feature extraction algorithms. > However, I think that it would be better to add such algorithms to > libxtract or any other vamp plugin collection, then also other projects > would benefit from it. I completely agree with that. This was my original motivation for writing libxtract as a C library rather than a set of Pd objects. > But on the other hand this wouldn't be a pd-only project, so I don't > know if it is suited for the GSoC program ... but in the end they would > be also available in pd - through the VAMP plugin host external ;) Yes, it would be great if some improvements got made to libxtract as a 'side effect' of the Pd GSoC! Something that might be interesting would be a set of MIR-inspired abstractions that use the libxtract/aubio bindings + the Pd machine learning objects ([knn], [ann_mlp], [ann_som]) to do common tasks - e.g. speech recognition, audio segmentation with labelling etc. A kind of Pd MIR toolkit. Jamie -- www.postlude.co.uk ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
