Pd-dev December 2004

pd-dev@lists.iem.at

22 participants
43 discussions

06 Jul '05

hi, my last mail got nuked by the server, did you change config? it never used to have a prob with a faked 'from' field to match the subscribed address... anyways my vote is do away with the numbers. ive made a lot of minor tweaks to devel, which ive already made to impd as well, and definitely don't want to make them a 3rd time (that would be 3 strikes..). to fix/add stuff like: / .pdrc not being read on windows (pd.ini) / not being able to select 2 outs and 6 ins with portaudio / not being able to put tcl in your system path on win32 / no ASIO with non-MSVC on win32. / a few linux64 fixes / merge jsarlo's VST io sppt / almost everything from impd that wasnt in g_* files nonetheless in the actual code theyre too trivial for anyone else to notice, and an order of magnitude smaller than the contributions Tim has made, but i wouldnt want them to get lost..so in order of preference from most to least 1: do away with numbering, and just have a 'devel'. every month or so, make sure it compiles on all 3 platforms and dump into MAIN..theres few enough developers and i dont think theyre stepping on toes and generally work on difft things.. 2: keep numbering, but devel_0_56 becomes devel_0_57, so the 'little guy's stuff isnt lost, and so he doesnt have to bug miller or guenter or whoever and possibly paste a bunch of stuff in again and get grey hairs.. 3: crazy all-night frankenstein hack/merge fest with version # change that might lose features and add new bugs.. i mean the same reason i'd vote for 'devel' as rather using debian 'sid' than 'sarge' or something thats doomed (like win32)...

8 41

is namecanvas obsolete or not?
by Tim Blechmann 03 Jan '05

03 Jan '05

hi miller, hi devs ... i wrote an abstraction using message-based patching ... therefor, i was sending the messages to pd-test.pd ... but since it's an abstraction all other instances of test will receive the same message, resulting in the multiple creation of the object ... to solve this, i had to use namecanvas $0-test... and send the messages there ... (example patch is attatched) am i missing something obvious or is namecanvas not as obsolete as the helpfile says... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

7 17

Variable number of control inlets in external
by Ian Smith-Heisters 02 Jan '05

02 Jan '05

Hi all, I'm trying to write a simple external in C. I read IOhannes' tutorial, and got simple framework running that had four inlets and outlets and the ability to send a bang to output the values of the inlets to their respective outlets. Next I want to be able to pass a single argument that will specify the number of inlets and outlets in addition to the first hot inlet. Below is the code I have, which certainly doesn't work. Summarily (is that a word?), I've just been trying to make n inlets and push the values of those inlets to the first outlet on a bang. I figure once I have that I can do the outlets pretty easily. The pertinent parts of the code are these: // Initialize dataspace typedef struct _genmut { t_object x_obj; t_float rating, num_inlets; t_float *nums_vec; t_outlet *f_out1, *f_out2, *f_out3, *f_out4; } t_genmut; //Methods void genmut_bang(t_genmut *x) { // just trying to get the right number of inlets first, then I'll work // on outlets. This should push the numbers from the inlets to the // first outlet. But it doesn't. for (i = 0; i < &x->i_numinlets; i++) outlet_float(x->f_out1, x->nums_vec[i]); } // Constructor void *genmut_new(t_floatarg ni) { t_genmut *x = (t_genmut *)pd_new(genmut_class); int i; x->num_inlets = ni; // set rating to default x->rating = 1; // dynamically create the inlets for (i = 0; i < ni; i++) floatinlet_new(&x->x_obj, &x->nums_vec[i]); x->f_out1 = outlet_new(&x->x_obj, &s_float); x->f_out2 = outlet_new(&x->x_obj, &s_float); x->f_out3 = outlet_new(&x->x_obj, &s_float); x->f_out4 = outlet_new(&x->x_obj, &s_float); return (void *)x; } My difficulty is only compounded by my obviously rudimentary and somewhat dusty C skills. I'm unclear on how to create the vector that would make a dynamically sizeable array for the inlets and outlets. Thanks for any advice. The whole of the code is below. -Ian /* genmut.c - Genetic Mutator external for Pure Data Take n floats, mutate them w/ a genetic algorithm, searching for a higher rating, which is given by the user via inlet 1. By Ian Smith-Heisters heisters [at] 0x09.com http://www.0x09.com History: Dec 28, '04: started */ #include "m_pd.h" static t_class *genmut_class; // Initialize dataspace typedef struct _genmut { t_object x_obj; t_float rating, num_inlets; t_float *nums_vec; t_outlet *f_out1, *f_out2, *f_out3, *f_out4; } t_genmut; //Methods void genmut_bang(t_genmut *x) { for (i = 0; i < &x->i_numinlets; i++) outlet_float(x->f_out1, x->nums_vec[i]); } void genmut_rating(t_genmut *x, t_floatarg f) { x->rating = f; } // Constructor void *genmut_new(t_floatarg ni) { t_genmut *x = (t_genmut *)pd_new(genmut_class); int i; x->num_inlets = ni; // set rating to default x->rating = 1; // dynamically create the inlets for (i = 0; i < ni; i++) floatinlet_new(&x->x_obj, &x->nums_vec[i]); /* floatinlet_new(&x->x_obj, &x->num1); floatinlet_new(&x->x_obj, &x->num2); floatinlet_new(&x->x_obj, &x->num3); floatinlet_new(&x->x_obj, &x->num4); */ x->f_out1 = outlet_new(&x->x_obj, &s_float); x->f_out2 = outlet_new(&x->x_obj, &s_float); x->f_out3 = outlet_new(&x->x_obj, &s_float); x->f_out4 = outlet_new(&x->x_obj, &s_float); return (void *)x; } // Setup void genmut_setup(void) { genmut_class = class_new(gensym("genmut"), (t_newmethod)genmut_new, 0, sizeof(t_genmut), CLASS_DEFAULT, 0); class_addbang (genmut_class, genmut_bang); class_addmethod(genmut_class, (t_method)genmut_rating, gensym("rating"), A_DEFFLOAT, 0); class_sethelpsymbol(genmut_class, gensym("help-genmut")); }

2 2

Only 1 Audio-inlet and GEM external
by Georg Holzmann 30 Dec '04

30 Dec '04

Hallo IOhannes, others! I want to make a GEM object with 1 audio inlet and 1 audio outlet. So I added in the setup callback: class_addmethod(classPtr, nullfn, gensym("signal"), A_NULL); If I make now the MAINSIGNALIN makro like in "normal" PD-externals I have 1 audio inlet, but it points to the data of the audio outlet !? Okay, so I added inlet_new(this->x_obj, &this->x_obj->ob_pd, &s_signal, &s_signal); to the constructor and now it works, but now I have of course two inlets and the left onw works how I want to have it. So make question: is it also possible with only one audio-inlet. If yes, what am I making wrong ? thanks, LG Georg PS: I attached the cpp file -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail

1 0

plugin~ os x
by Zachris Trolin 29 Dec '04

29 Dec '04

I've just managed to have [plugin~] compile with LADSPA support on OS X by trying to figure out the correct flags from other externals and hacking automake. I asked on the userlist some weeks ago but got no answer so I had to do it myself. Right now all automake files are in a mess but atleast it compiles and it's possible to load the external and use it without problem. If anybody else needs this mess I'll gladly share it :) I'd love to see a working plugin~ ship with the OS X distributions of pd If nobody else wants to do it I'll try to fixup the makefiles so that it should work for most architectures. /z

1 0

fixing guiqueue
by Krzysztof Czaja 25 Dec '04

25 Dec '04

hi Miller, looks like this typo in sys_unqueuegui() was behind many, if not all, quiqueue-related crashes reported on pd-list: --- s_inter.c~ 2004-10-25 05:10:19.000000000 +0200 +++ s_inter.c 2004-12-18 15:10:03.000000000 +0100 @@ -778,7 +778,7 @@ if (gq2->gq_client == client) { gq->gq_next = gq2->gq_next; - t_freebytes(gq, sizeof(*gq)); + t_freebytes(gq2, sizeof(*gq)); break; } } Krzysztof

2 1

introducing deprecation to Pd
by Hans-Christoph Steiner 22 Dec '04

22 Dec '04

So Pd is a platform that has been around long time and has been thru many renditions, so there is the inevitable build-up of cruft. Mostly it seems that this cruft has stayed around, kept for compatibility purposes. Since almost all of the externals are now in the CVS, we can now introduce a unified method of deprecation. A good example of this would be [linuxevent], [linuxjoystick], and [linuxmouse]. People have built patches using these objects, but I am in the process of finishing up a unified, cross-platform system to replace these ([hid], [linuxhid], [darwinhid], etc.) and I am no longer going to maintain them at all. So the three previous objects would be put into the "deprecated" folder, and then people who needed to use them would just add the "deprecated" folder to the path. Deprecation is very common in programming environments like Java, and I think we should be thinking of Pd as a programming environment rather than an application. Since there a number of objects that cause problems (conflicts, ancient code maintenance, etc.), I think we should deprecate them. For when we deprecate objects, I am thinking that they should be put in a folder "externals/build/src/deprecated" and then removed from their location in CVS. They will always be in the history of the CVS repository if anyone needs to get to them. .hc ________________________________________________________________________ ____ "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore

2 1

extra reorg idea
by Hans-Christoph Steiner 20 Dec '04

20 Dec '04

I'd like to propose an idea for organizing all of the objects, instead of placing everything directly in "extra" and "doc/5.reference". Everything that is aimed to be a standard part of Pd would go in "extra" and "5.reference". Then objects that have conflicted names, objects that are deprecated, or cyclone/Max-compatibility objects would go into their own folders. When someone wants to use these objects, they can add then directories using -path and -helppath. Here's an outline: - "cyclone" objects that are only for Max compatibility ([Borax~], [coll], [mousefilter], etc.) T - For name conflicts, there would be library-specific folders: - "gem" [counter], [scale], [average], [change] - "cxc" [prepend], [counter], [split] - "iem" [gate], [prepend], [speedlim] - "maxlib" [speedlim], [borax], [scale], [split] - "deprecated" would be for deprecated objects, like [linuxjoystick], etc. - there could be subdirectories for specific things like "Gem" I think this layout would solve a number of problems, and be relatively easy to implement. .hc ________________________________________________________________________ ____ "Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra

4 5

nameclashes and so on (average)
by Tim Blechmann 20 Dec '04

20 Dec '04

hi gem-devs, hi olaf, hi rest ... since i need an average object, i'm again running into a lovely nameclash... olaf, gem-devs: do you see any chance to combine both of your objects? maybe extend the maxlib average with a |reset N(, a |clear( and a |bang( message ... and remove gem's average ... cheers ... tim -- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs

3 2

pthread files line endings
by Thomas Grill 19 Dec '04

19 Dec '04

Hi Miller, since i'm playing around with various compilers at the moment: Borland C++ and MinGW have hickups with the pthread files included in the PD packages (for Windows)... they have some strange line endings - loading them in Visual C++ makes it obvious. I use metapad to get rid of it, but it should also be corrected in the PD distribution. best greetings, Thomas

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 2004