Re: [PD-dev] pd-ext documentation [was something else]
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote: > Sounds like a useful thing. How about sticking this info into a > subpatch in the help patch? They could easily be parsed with textfile > and route. Then there is only one file per object to maintain. The [pd META] approach, yes. But there is no vanilla way to get a directory listing. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] automated tests, where in SVN?
Hey all, I've written a little script to run patches as tests, and I'd like to set it up to automatically run all of the patches that are in a directory of SVN. Where shall we put such test patches in SVN? Here are a couple ideas off the top of my head: /tests 'tests' folder in the base dir of each library in SVN foo-test.pd anywhere in SVN. .hc There is no way to peace, peace is the way. -A.J. Muste ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-ext documentation [was something else]
On Feb 27, 2009, at 2:16 AM, Frank Barknecht wrote: > Hallo, > João Pais hat gesagt: // João Pais wrote: > I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something? how did you extract this list? >>> >>> I did this manually, a lot of copy and paste. >>> and yes, there might be some duplicates and some unusual objects >>> like >>> all the gemgl objects are in the list... >> >> ah ah, and I thought I was the only crazy guy going through object >> per >> object and extract the information (see excel file). ok, maybe we >> should >> discuss a more serious way of automatising this. > > I've just added the system we use in the RjDj lib to [list]-abs as > well. It's pretty simple, but cool: All objects are described in a > textfile using this format: > > objectname - short object description in one line without commas > > In [list]-abs this file is called "list-abs-intro.txt". (It also > allows lines consisting of just an integer number, which is used to > optionally make room for larger GUI objects in the overview patch.) > > A helper file reads this list into a textfile and dynamically patches > all referenced objects and descriptions into a subpatch. This patch is > called "list-abs-intro.pd". Sounds like a useful thing. How about sticking this info into a subpatch in the help patch? They could easily be parsed with textfile and route. Then there is only one file per object to maintain. .hc "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
On Fri, 27 Feb 2009, Martin Peach wrote: Too bad, you could have tested if the compiler could handle types changing while the code was being written. rofl :) I'm sure that there's a compsci department somewhere in the world where someone is writing a thesis about a type theory that would handle that case. Actually, I'd almost bet that this has already happened. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
Mathieu Bouchard wrote:
> On Fri, 27 Feb 2009, Martin Peach wrote:
>
>> You called pthread_create() with &threadargs:
>> ret = pthread_create( &thread1, NULL, mythread, &threadArgs);
>> when you probably should just use threadargs, since it's already a
>> pointer.
>> Or else you need to dereference the handle:
>> post("My symbol: %s",
>> ((*(struct floatArgStruct**))threadArgs)->s->s_name);
>
> No, it was supposed to be just threadArgs, but the type of threadArgs
> changed while writing the code, as I made him change it from a global
> variable to a malloc. In the end, it turns out it wasn't quite useful,
> because there's only going to be one extra thread, after all.
>
Too bad, you could have tested if the compiler could handle types
changing while the code was being written.
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
On Fri, 27 Feb 2009, marius schebella wrote: Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war Other possible taxonomy: three categories total: good/ bad/ ugly/ Other possible taxonomy: five categories total: easy/ normal/ difficult/ expert/ ninja/ Other possible taxonomy: five categories total: lime/ strawberry/ blueberry/ grape/ tangerine/ Other possible taxonomy: two categories total: country/ western/ _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
On Fri, 27 Feb 2009, Martin Peach wrote:
You called pthread_create() with &threadargs:
ret = pthread_create( &thread1, NULL, mythread, &threadArgs);
when you probably should just use threadargs, since it's already a pointer.
Or else you need to dereference the handle:
post("My symbol: %s",
((*(struct floatArgStruct**))threadArgs)->s->s_name);
No, it was supposed to be just threadArgs, but the type of threadArgs
changed while writing the code, as I made him change it from a global
variable to a malloc. In the end, it turns out it wasn't quite useful,
because there's only going to be one extra thread, after all.
_ _ __ ___ _ _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
B. Bogart wrote:
>
> I'm now getting a segfault when trying to access a member of the
> structure in the thread function:
>
> #0 0xf7d531cb in strlen () from /lib/i686/cmov/libc.so.6
> #1 0xf7d1f648 in vfprintf () from /lib/i686/cmov/libc.so.6
> #2 0xf7d43e04 in vsnprintf () from /lib/i686/cmov/libc.so.6
> #3 0x080c68d6 in post (fmt=0xf7f7db5a "My symbol: %s")
> at s_print.c:51
> #4 0xf7f7d829 in mythread ()
>from /home/bbogart/src/gphoto/src/pd-external/gphoto2.pd_linux
>
> The way I'm trying to access the member is as follows:
>
> post("My symbol: %s", ((struct floatArgStruct *)threadArgs)->s->s_name);
>
You called pthread_create() with &threadargs:
ret = pthread_create( &thread1, NULL, mythread, &threadArgs);
when you probably should just use threadargs, since it's already a pointer.
Or else you need to dereference the handle:
post("My symbol: %s",
((*(struct floatArgStruct**))threadArgs)->s->s_name);
Martin
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] How to pass indeterminate args to a thread
Thanks Claude!
I got lots of help from Matju on IRC so things are compiling.
I'm now getting a segfault when trying to access a member of the
structure in the thread function:
#0 0xf7d531cb in strlen () from /lib/i686/cmov/libc.so.6
#1 0xf7d1f648 in vfprintf () from /lib/i686/cmov/libc.so.6
#2 0xf7d43e04 in vsnprintf () from /lib/i686/cmov/libc.so.6
#3 0x080c68d6 in post (fmt=0xf7f7db5a "My symbol: %s")
at s_print.c:51
#4 0xf7f7d829 in mythread ()
from /home/bbogart/src/gphoto/src/pd-external/gphoto2.pd_linux
The way I'm trying to access the member is as follows:
post("My symbol: %s", ((struct floatArgStruct *)threadArgs)->s->s_name);
I've attached the full source.
All this typdef stuff is new to me, so I may have messed up something
obvious.
Thanks,
.b.
Claude Heiland-Allen wrote:
>> post("My symbol: %s", threadArgs.s->s_name);// line 92
>
> threadArgs is a pointer, '.' is only for structs/unions
>
> try '->' instead of '.' to both dereference pointer and access member
/* Gphoto2 PD External */
/* Copyright Ben Bogart, 2009 */
/* This program is distributed under the params of the GNU Public License */
///
/* This file is part of the Gphoto2 PD External. */
/* */
/* Gphoto2 PD External is free software; you can redistribute it and/or modify */
/* it under the terms of the GNU General Public License as published by */
/* the Free Software Foundation; either version 2 of the License, or */
/* (at your option) any later version. */
/* */
/* The Gphoto2 PD External is distributed in the hope that they will be useful, */
/* but WITHOUT ANY WARRANTY; without even the implied warranty of*/
/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */
/* GNU General Public License for more details. */
/* */
/* You should have received a copy of the GNU General Public License */
/* along with the Chaos PD Externals; if not, write to the Free Software */
/* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */
///
#include
#include
#include
#include
#include
#include
t_class *gphoto2_class;
typedef struct gphoto2_struct {
t_object x_obj;
t_outlet *outlet;
} gphoto2_struct;
// TODO change this to work on all funcs
typedef struct floatArgStruct {
gphoto2_struct *gphoto2;
t_symbol *s;
} floatArgStruct;
static void listConfig(gphoto2_struct *gphoto2) {
int gp_ret, numsections, numchildren, i, j;
Camera *camera;
CameraWidget *config = NULL;
CameraWidget *child = NULL;
CameraWidget *child2 = NULL;
CameraWidgetType type;
const char *name;
gp_ret = gp_camera_new (&camera);
if (gp_ret != 0) {error("gphoto2: ERROR: %s\n", gp_result_as_string(gp_ret)); gp_camera_unref(camera); return;}
// INIT camera (without context)
gp_ret = gp_camera_init (camera, NULL);
if (gp_ret != 0) {error("gphoto2: ERROR: %s\n", gp_result_as_string(gp_ret));}
if (gp_ret == -105) {post("gphoto2: Are you sure the camera is supported, connected and powered on?"); gp_camera_unref(camera); return;}
gp_ret = gp_camera_get_config (camera, &config, NULL); // get config from camera
if (gp_ret != 0) {error("gphoto2: ERROR: %s\n", gp_result_as_string(gp_ret)); gp_camera_unref(camera); return;}
numsections = gp_widget_count_children(config);
for (i=0; is->s_name);
outlet_float(((struct floatArgStruct *)threadArgs)->gphoto2->x_obj.ob_outlet, 0.1);
post("thread end.");
}
static void wrapGetConfig(gphoto2_struct *gphoto2, t_symbol *s) {
int ret;
pthread_t thread1;
// instance of structure
floatArgStruct *threadArgs = (floatArgStruct *)malloc(sizeof(floatArgStruct));
// packaging arguments into structure
threadArgs->gphoto2 = gphoto2;
threadArgs->s = s;
post("I'm about to start the thread.");
// Create thread
ret = pthread_create( &thread1, NULL, mythread, &threadArgs);
}
void *getConfig(gphoto2_struct *gphoto2, t_symbol *s) {
int gp_ret;
const char *textVal;
const int *toggleVal;
const float rangeVal;
float value;
Camera *camera;
CameraWidget *config = NULL;
CameraWidget *child = NULL;
CameraWidgetType type;
gp_ret = gp_camera_new (&camera);
if (gp_ret != 0) {error("gphoto2: ERROR: %s\n", gp_result_as_string(gp_ret)); gp_camera_unref(camera); return;}
// INIT camera (without context)
gp_ret = gp_camera_init (camera, NULL);
if (gp_ret != 0) {error("gphoto2: ERROR: %s\n", gp_result_as_string(gp_ret));}
if (gp_ret == -105) {post("gphoto2: Are you sure
Re: [PD-dev] How to pass indeterminate args to a thread
B. Bogart wrote:
> I figured that doing this with a PD type was unlikely, so I started
> messing with creating a structure for my args and passing a pointer to
> that.
>
> So I have defined my structure for a single float arg:
>
> struct floatArgStruct {
> gphoto2_struct *gphoto2;
> t_symbol *s;
> };
>
>
> just under the typedef for the external structure. (Is the external
> struct a better place for its def?)
>
> Then the function that is executed from the PD selector:
>
> static void wrapGetConfig(gphoto2_struct *gphoto2, t_symbol *s) {
> int ret;
> pthread_t thread1;
>
> // instance of structure
> struct floatArgStruct threadArgs;
>
> // packaging arguments into structure
> threadArgs.gphoto2 = gphoto2;
> threadArgs.s = s;
>
> post("I'm about to start the thread.");
>
> // Create thread
> ret = pthread_create( &thread1, NULL, mythread, (void *)threadArgs);
> }
>
> which populates the structure, and starts the thread. The struct stuff
> appears to work here)
>
> Above this is the def of the function that is to execute in the thread:
>
> void *mythread(struct floatArgStruct *threadArgs) {
> int i;
> post("thread start.");
>
> post("My symbol: %s", threadArgs.s->s_name);// line 92
threadArgs is a pointer, '.' is only for structs/unions
try '->' instead of '.' to both dereference pointer and access member
> outlet_float(threadArgs.gphoto2->x_obj.ob_outlet, 0.1);
>
> post("thread end.");
> }
>
> The errors I'm confused about are:
>
> gphoto2.c:92: error: request for member 's' in something not a structure
> or union
> gphoto2.c:93: error: request for member 'gphoto2' in something not a
> structure or union
>
> Which means that the structure is not being passed to the thread code
> correctly, as its not recognized as a structure.
>
> Next gcc complains about the way I'm initiating the thread:
>
> gphoto2.c:112: error: cannot convert to a pointer type
> gphoto2.c:112: warning: passing argument 3 of 'pthread_create' from
> incompatible pointer type
>
> In the tutorial the function args were cast as (void *) which does not
> seem to be working in this case.
>
> Does anyone have any code that does this kind of job I could look at?
>
> Or is it obvious I'm doing something really wrong?
>
> This is my first exploration into threads and custom structs (not
> counting the external struct) so I may have it totally wrong.
>
> Thanks,
> B.
>
>
>
>
> B. Bogart wrote:
>> Hey all,
>>
>> I've got some simple threading code working, and it looks like that will
>> fix my HUP issues with PD and my gphoto external.
>>
>> Problem I'm having is that I need to pass thread arguments as a pointer
>> to a structure.
>>
>> Are there some PD types I can use to make this work? (A_GIMME?)
>>
>> Or do I need to make struct that holds the *argv argc stuff, pass that
>> structure to the thread, and have it unpack the content?
>>
>> Also my code function that executes the thread does not wait for the
>> threads to complete.
>>
>> What is the best way to make my object output a bang when the thread is
>> complete?
>>
>> Any advice appreciated.
>>
>> Thanks,
>> B.
>>
>>
>
> ___
> 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
Re: [PD-dev] How to pass indeterminate args to a thread
I figured that doing this with a PD type was unlikely, so I started
messing with creating a structure for my args and passing a pointer to
that.
So I have defined my structure for a single float arg:
struct floatArgStruct {
gphoto2_struct *gphoto2;
t_symbol *s;
};
just under the typedef for the external structure. (Is the external
struct a better place for its def?)
Then the function that is executed from the PD selector:
static void wrapGetConfig(gphoto2_struct *gphoto2, t_symbol *s) {
int ret;
pthread_t thread1;
// instance of structure
struct floatArgStruct threadArgs;
// packaging arguments into structure
threadArgs.gphoto2 = gphoto2;
threadArgs.s = s;
post("I'm about to start the thread.");
// Create thread
ret = pthread_create( &thread1, NULL, mythread, (void *)threadArgs);
}
which populates the structure, and starts the thread. The struct stuff
appears to work here)
Above this is the def of the function that is to execute in the thread:
void *mythread(struct floatArgStruct *threadArgs) {
int i;
post("thread start.");
post("My symbol: %s", threadArgs.s->s_name);// line 92
outlet_float(threadArgs.gphoto2->x_obj.ob_outlet, 0.1);
post("thread end.");
}
The errors I'm confused about are:
gphoto2.c:92: error: request for member 's' in something not a structure
or union
gphoto2.c:93: error: request for member 'gphoto2' in something not a
structure or union
Which means that the structure is not being passed to the thread code
correctly, as its not recognized as a structure.
Next gcc complains about the way I'm initiating the thread:
gphoto2.c:112: error: cannot convert to a pointer type
gphoto2.c:112: warning: passing argument 3 of 'pthread_create' from
incompatible pointer type
In the tutorial the function args were cast as (void *) which does not
seem to be working in this case.
Does anyone have any code that does this kind of job I could look at?
Or is it obvious I'm doing something really wrong?
This is my first exploration into threads and custom structs (not
counting the external struct) so I may have it totally wrong.
Thanks,
B.
B. Bogart wrote:
> Hey all,
>
> I've got some simple threading code working, and it looks like that will
> fix my HUP issues with PD and my gphoto external.
>
> Problem I'm having is that I need to pass thread arguments as a pointer
> to a structure.
>
> Are there some PD types I can use to make this work? (A_GIMME?)
>
> Or do I need to make struct that holds the *argv argc stuff, pass that
> structure to the thread, and have it unpack the content?
>
> Also my code function that executes the thread does not wait for the
> threads to complete.
>
> What is the best way to make my object output a bang when the thread is
> complete?
>
> Any advice appreciated.
>
> Thanks,
> B.
>
>
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
may I suggest the following category structure Pd world series top 40 frank's special blend other utilities objects that might crash the ones I almost never use not allowed during war ... marius. 2009/2/27 Mathieu Bouchard : > On Fri, 27 Feb 2009, IOhannes m zmoelnig wrote: > >> i used [pix_sig2pix~] as an example about how categories often fail. it >> was the first object that came to my mind that clearly belongs into several >> categories at the same time. there are other objects (within zexy, vanilla, >> list-abs, creb, you-name-it) that are not simply "glue" or "math", but both >> and more. and this is not necessarily a design problem of these objects >> (though sometimes it might well be). > > I agree: see also: > > http://lists.puredata.info/pipermail/pd-list/2007-07/051652.html > http://lists.puredata.info/pipermail/pd-list/2007-07/051659.html > http://lists.puredata.info/pipermail/pd-list/2007-07/051768.html > ... and more mails in that thread. > >> fortunately loads of object do belong to a simple category, so don't let >> Gödel stop us from trying to define such categories. > > What's Gödel have to do with it at all? > > (I don't necessarily agree with the rest of your mail.) > >> otoh, the object interface for doing complex-math in signal-domain might >> look significantly different than the one in message-domain, or >> image-domain, or matrix-domain. so, not all objects doing complex-maths (in >> various domains) should go into the same category "complex-math" > > as much as possible, interfaces that are not the same about things that are, > should be transformable by a function that takes an interfaces and turns it > into another interface. This is so that people can guess how a class works, > from the knowledge of how a similar class works. It can save on the amount > of help files too. Ideally, we'd save on the number of classes, though. > > _ _ __ ___ _ _ _ ... > | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec > ___ > 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
Re: [PD-dev] Proposals for object categories
On Fri, 27 Feb 2009, IOhannes m zmoelnig wrote: i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more. and this is not necessarily a design problem of these objects (though sometimes it might well be). I agree: see also: http://lists.puredata.info/pipermail/pd-list/2007-07/051652.html http://lists.puredata.info/pipermail/pd-list/2007-07/051659.html http://lists.puredata.info/pipermail/pd-list/2007-07/051768.html ... and more mails in that thread. fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories. What's Gödel have to do with it at all? (I don't necessarily agree with the rest of your mail.) otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math" as much as possible, interfaces that are not the same about things that are, should be transformable by a function that takes an interfaces and turns it into another interface. This is so that people can guess how a class works, from the knowledge of how a similar class works. It can save on the amount of help files too. Ideally, we'd save on the number of classes, though. _ _ __ ___ _ _ _ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
> One thing I was thinking about recently is whether we need a hierarchy > of classes. In Object-Oriented Programming, there is hierarchy of > classes as part of the basis of the language. There is no hierarchy of > classes in Pd so it seems to me that there should also be no hierarchy > in the namespaces (FYI: this is contrary to something I proposed a while > back). I myself can't do many comparations with programming languages, because I'm not a programmer. can program only Pd, not C or anything else. so what I say is more to do with logic and common sense than making references to concrete standards. > Basically, I mean we should not have a library structure like this: > > audio > audio/math > audio/filters > audio/oscillators > audio/oscillators/bwlimited > > Instead, it would be a one level namespace, to keep things simple, so > maybe something like this: > > audio > audiomath > filters > oscillators > bloscillators > > Or even better, have more descriptive, fun and hopefuilly more memorable > names, like: > simpillators > blocycle > > This isn't really a proposal of any kind, but more a discussion point. it's good to consider it, but I think it makes it more complicated. if you have a root division of control / audio / graphics / ect., it's much easier to find other lower categories of objects. and that filters information and saves time - if one is looking for band-limited-oscillators, he knows he should to go to audio->oscillators first. and not look at once at 30+ categories until he finds whatever he wants to. about "descriptive, fun and hopefuilly more memorable names", I've also seen this a bit in the pdpedia, and was on my mind: if there are already standards for objects, I don't know if it's efficient to reinvent the wheel (and give it a funny shape). Pd (or any language) should also be ready for scientific use, and in that way comply with the already existing standards. Or I could make up new names based on portuguese translation, that would be funny. I guess this suggestion from you was just to make sure this case gets considered? (and I hope, rejected?) ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hans-Christoph Steiner wrote: > > I don't think we should try to come up with an hierarchy in which > everything can fit. pix_sig2pix~ can stay in Gem for now. This > should be the standard libs of common things, which is currently split > across libs like vanilla, zexy, list-abs, creb, etc. sorry for being unclear, this is clearly a misunderstanding. i used [pix_sig2pix~] as an example about how categories often fail. it was the first object that came to my mind that clearly belongs into several categories at the same time. there are other objects (within zexy, vanilla, list-abs, creb, you-name-it) that are not simply "glue" or "math", but both and more. and this is not necessarily a design problem of these objects (though sometimes it might well be). fortunately loads of object do belong to a simple category, so don't let Gödel stop us from trying to define such categories. however what i think is relevant is that all categories should be on the same level. e.g. "complex-math" and "signal" are categories on different levels: nothing keeps you from doing complex-math in signal-domain. otoh, the object interface for doing complex-math in signal-domain might look significantly different than the one in message-domain, or image-domain, or matrix-domain. so, not all objects doing complex-maths (in various domains) should go into the same category "complex-math" if we have fixed (library-like) categories, then objects should not wander through categories either. otoh, categories should have more than one entry. e.g. if we only have a single bandlimited oscillator, why would we create a category "bandlimitedosc~" rather than just put it into the "osc~" group (btw, should [osc~] itself go into the bandlimitedosc~ group or not?). but when enough blosc~s show up to form a separate category, should we move our original osc into the new group? so people cannot find it anymore. or should we just have a handful of really big groups? who would be willing to maintain them (e.g. the "fx~" group) mf.ar IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd-ext documentation [was something else]
> I've just added the system we use in the RjDj lib to [list]-abs as > well. It's pretty simple, but cool: All objects are described in a > textfile using this format: > > objectname - short object description in one line without commas > > In [list]-abs this file is called "list-abs-intro.txt". (It also > allows lines consisting of just an integer number, which is used to > optionally make room for larger GUI objects in the overview patch.) > > A helper file reads this list into a textfile and dynamically patches > all referenced objects and descriptions into a subpatch. This patch is > called "list-abs-intro.pd". I think that it would be the best idea as well - many libraries already bring their object description - that's pd's "official" format as well, as used in the old 0.INTRO.txt file. would it be possible to make that libs don't get compiled/added to the package if that list is missing? or desirable? ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
Hi, > João Pais wrote: >> >> exactly. in the contrary of the before mentioned libraries, these are >> more >> groups of externals compassing different groups: glue, math, matrix, ... > > please someone explain to me the differences. > > this sounds all very nice on a piece of paper, but to which category > does [pix_sig2pix~] belong to? > - image (or even graphics, since i think that any segregation between > graphics and images should _not_ be done anyhow) > - signal > - glue > - misc I wouldn't try to be very radical (or anal) here. I wrote somewhere else (but don't remeber where) that cohese libraries - like Gem, Pdp, vasp, and maybe others - already close themselves from the outside world, so they should remain as a group, and the group inserted in the best main category above them. check the page now, actually I also joined both video/graphics categories, and put some subcategories in. As for individual cases, they should be checked case to case. Gem has signal objects, but since it's goes is video, it should go to the video section. I think this doesn't affect cohese libraries that much, because it makes no sense to split them apart. but it will help with libraries that are just a group of lots of utilities for different categories - zexy, etc etc, also jmmmp, etc. For example, the IEM libs split themselves up at some point, now we have iem-gui, iem-matrix, ... ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
On Feb 27, 2009, at 5:52 AM, IOhannes m zmoelnig wrote: > João Pais wrote: >> >> exactly. in the contrary of the before mentioned libraries, these >> are more >> groups of externals compassing different groups: glue, math, >> matrix, ... > > please someone explain to me the differences. > > this sounds all very nice on a piece of paper, but to which category > does [pix_sig2pix~] belong to? > - image (or even graphics, since i think that any segregation between > graphics and images should _not_ be done anyhow) > - signal > - glue > - misc > > mfga.sdr > IOhannes I don't think we should try to come up with an hierarchy in which everything can fit. pix_sig2pix~ can stay in Gem for now. This should be the standard libs of common things, which is currently split across libs like vanilla, zexy, list-abs, creb, etc. .hc 'You people have such restrictive dress for women,’ she said, hobbling away in three inch heels and panty hose to finish out another pink- collar temp pool day. - “Hijab Scene #2", by Mohja Kahf ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] Proposals for object categories
João Pais wrote: > > exactly. in the contrary of the before mentioned libraries, these are more > groups of externals compassing different groups: glue, math, matrix, ... please someone explain to me the differences. this sounds all very nice on a piece of paper, but to which category does [pix_sig2pix~] belong to? - image (or even graphics, since i think that any segregation between graphics and images should _not_ be done anyhow) - signal - glue - misc mfga.sdr IOhannes ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
