hi developers! when is use pd with josephs shadow-patch, pd looks nicer but crashes when opening my loopool patch. Consistency check failed: glist_findrtext any ideas what's wrong?
Are you using any externals? I know someone had some problems with the Yves Degoyon grid object. I made a patch for it that was a quick fix. I think I still have it somewhere. If you want it, let me know.
Joe
Hi,
I am looking for some kind of documentation which tells what PD can do and mainly (things which PD can not do). Is theer some other place to look for other than the PD documentation in UCSD website?
Thanks, -Prchi-
On Sat, 5 Oct 2002 Prachi.Tyagi@asu.edu wrote:
Hi,
I am looking for some kind of documentation which tells what PD can do and mainly (things which PD can not do).
There is nothing pd can not do :) No honestly, I think you have to learn to work with pd and answer this question yourself. The help patches that come with pd should give you a good idea.
Greetings,
Guenter
Is theer some other place to look for other than the PD documentation in UCSD website?
On Sat, 5 Oct 2002, Joseph A. Sarlo wrote:
hi developers! when is use pd with josephs shadow-patch, pd looks nicer but crashes when opening my loopool patch. Consistency check failed: glist_findrtext any ideas what's wrong?
Are you using any externals? I know someone had some problems with the Yves Degoyon grid object. I made a patch for it that was a quick fix. I think I still have it somewhere. If you want it, let me know.
Reading this, a discussion I had at the ICMC comes to my mind. For one of the installations they were using a Macintosh with MAX, the artist told me that they had to reboot the machine every day. I asked why they didn't consider using pd (we have already several long term installations that run over years !).
The answer was the following: They were told that PD comes with all these extensions, which makes it really useful, but that these extensions are really buggy. Thats why they preferred using MAX.
Their fault I know, but it made me think ...
Greetings
Guenter
Arghh, I could bite my lip for this one (is this correct english ?) Of course I did not have the least intention to blame anyone for having bugs, version problems or whatsoever in his/her externals.
The question I wanted to ask really (also, I have to admit, in the light of the demudi beta release in november).
Who of the external developers are planning to put their code into CVS, and who ist not (and why ?)
Thanks for listening
Guenter
On Sat, 5 Oct 2002, guenter geiger wrote:
On Sat, 5 Oct 2002, Joseph A. Sarlo wrote:
hi developers! when is use pd with josephs shadow-patch, pd looks nicer but crashes when opening my loopool patch. Consistency check failed: glist_findrtext any ideas what's wrong?
Are you using any externals? I know someone had some problems with the Yves Degoyon grid object. I made a patch for it that was a quick fix. I think I still have it somewhere. If you want it, let me know.
Reading this, a discussion I had at the ICMC comes to my mind. For one of the installations they were using a Macintosh with MAX, the artist told me that they had to reboot the machine every day. I asked why they didn't consider using pd (we have already several long term installations that run over years !).
The answer was the following: They were told that PD comes with all these extensions, which makes it really useful, but that these extensions are really buggy. Thats why they preferred using MAX.
Their fault I know, but it made me think ...
Greetings
Guenter
Who of the external developers are planning to put their code into CVS, and who ist not (and why ?)
I've been planning to, but haven't gotten around to it yet.. Feel free to retrieve my humble offerings from http://www.macalester.edu/~bsaylor and put them in CVS if you like. Otherwise, I'll do it someday :)
Ben
Done!
Thanks!
Juha
----- Original Message ----- From: "Ben Saylor" bsaylor@Macalester.edu To: pd-list@iem.kug.ac.at Sent: Sunday, October 06, 2002 3:05 AM Subject: Re: [PD] Re: shadow patch bug
Who of the external developers are planning to put their code into CVS, and who ist not (and why ?)
I've been planning to, but haven't gotten around to it yet.. Feel free to retrieve my humble offerings from http://www.macalester.edu/~bsaylor and put them in CVS if you like. Otherwise, I'll do it someday :)
Ben
The answer was the following: They were told that PD comes with all these extensions, which makes it really useful, but that these extensions are really buggy. Thats why they preferred using MAX.
Their fault I know, but it made me think ...
Wow, what a statement. MAX itself (not the addons) is buggy as hell. Last week i had real troubles to get MAX reliably working for a concert. If PD had the same graphical abilities as Max i would completely switch to PD. Yet, the graphical interface (or TCL/TK, respectively) is a real obstacle....
To my mind, the foremost problem is the incomplete or inscrutable documentation, that makes it difficult to get started with PD. Looking at the MAX (and jitter) package, one has to admit that Cycling have done really good work with their SDK documentation, help files and tutorials.
greetings, Thomas
Hi, Thomas Grill hat gesagt: // Thomas Grill wrote:
Wow, what a statement. MAX itself (not the addons) is buggy as hell. Last week i had real troubles to get MAX reliably working for a concert. If PD had the same graphical abilities as Max i would completely switch to PD. Yet, the graphical interface (or TCL/TK, respectively) is a real obstacle....
To my mind, the foremost problem is the incomplete or inscrutable documentation, that makes it difficult to get started with PD. Looking at the MAX (and jitter) package, one has to admit that Cycling have done really good work with their SDK documentation, help files and tutorials.
Until three days ago I never did work with Max, but last week I attended a workshop in Mannheim ("prozesse 02" => http://www.die-lounge.com/prozesse/), where I and about 20 others could spend a whole day using Max under the helpful hands of Kim Cascone (and later Robert Henke of Monolake/Ableton [who's looking hard for C++/audio-developers btw. Do you need a job, Thomas?]).
Of course I asked Kim and the other attendees, if they know and what they think of Pd. Kim told me, that he didn't actually use Pd or jMax, but that some friends of his in Australia use it and that he was very impressed by what is possible with Pd now.
The other participants mostly didn't know Pd, but those who did know Pd, were still thinking of a Pd without sliders and GUI objects, i.e. of a time, when it was quite hard to use Pd in a live performance situation on laptops. They were talking about Pd like I would talk about Csound: not user-friendly, needs to much knowledge,... And some more advanced features of Pd (Gem, data structures,...) can crash Pd quite badly as we all know, although in general it runs very stable. OTOH, Kim had very bad luck with his Powerbook on the night's performace because his whole machine crashed three times... That about MacOS 9.
The Max course itself was quite basic and I must say, that we learned nothing, that wouldn't be possible in Pd as well. (BTW: It's nice to read the Pd advertisment on the Max startup screen going somehow like: "MSP uses parts of Pd by Miller Puckette")
The bottom line of my first contact with Max is this:
Max has some very cool usability enhancements compared to Pd. Some are directly visible, for example the greater count of GUI objects. I want multisliders, too. How's GUI-flext going, so that I can start programming this?
Other usability things are not that visible. For example, in Max it is possible to resize objects with the mouse. This is a small feature, but it is such a time saver, that I really would like to see it in Pd as well. Obviously the possibility to hide objects and patch cords in Locked Mode makes things more appealing visually, but this is something, I do not miss that much, because you easily can hide things, that would better be visible all the time. (Someone on the workshop did hide the dac~ objects and the main volume slider and was wondering, why his patch wasn't working: he had the volume turned down, but couldn't see that fact.)
I think, a lot of 'normal' (laptop) musicians would also prefer another font. I wouldn't prefer it, but making it possibe to configure the font would also make Pd more Max-like.
Now back to the shadow patch: Personally I *hate* shadows, but I like different colors: is there a shadowless shadow patch, a "color only patch"?
ciao
Frank Barknecht _ ______footils.org__
Now back to the shadow patch: Personally I *hate* shadows, but I like different colors: is there a shadowless shadow patch, a "color only patch"?
about what's been said in that thread :
- grid object v0.3 wasn't buggy at all with a regular pd distribution
- it's only the shadow patch which introduced the incompatibility
- the patched version introduced new rules for gui objects
- these rules were not and are still not set clearly
- some other gui objects might have the same problem
- if you don't get this, you know nothing of versionning/bug-tracking
- i really don't care about that patch, there are much more important
things to do
byes,
sevy/yves
On Sun, 6 Oct 2002, Yves Degoyon wrote:
Now back to the shadow patch: Personally I *hate* shadows, but I like different colors: is there a shadowless shadow patch, a "color only patch"?
about what's been said in that thread :
- grid object v0.3 wasn't buggy at all with a regular pd distribution
- it's only the shadow patch which introduced the incompatibility
- the patched version introduced new rules for gui objects
- these rules were not and are still not set clearly
- some other gui objects might have the same problem
- if you don't get this, you know nothing of versionning/bug-tracking
- i really don't care about that patch, there are much more important
things to do
Thats more than true. Again, sorry for trying to promote CVS with this concrete case.
There are more important things to do than the shadow patch, and I have expressed what I think they are.
What are the more important things for you ? And how do you think they could be done ? by whom ?
Greetings,
Guenter
- grid object v0.3 wasn't buggy at all with a regular pd distribution
- it's only the shadow patch which introduced the incompatibility
- the patched version introduced new rules for gui objects
- these rules were not and are still not set clearly
Actually, I don't think it was the drop shadows patch that caused the incompatibility, it was the colored patch cord patch (these are two separate patches that I only put together in the Windows binary). But yes, absolutely, there was nothing buggy about grid (or the patches, as far as I know).
- i really don't care about that patch, there are much more important
things to do
It was just something fun I did that I thought other people might like, too. It wasn't meant to revolutionize PD or anything.
Joe jsarlo@ucsd.edu
They were talking about Pd like I would talk about Csound: not user-friendly, needs to much knowledge,...
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers. Max is delivered with a large number of working examples to be modified for one's perform patches.
OTOH, Kim had very bad luck with his Powerbook on the night's performace because his whole machine crashed three times... That about MacOS 9.
Yes, OS9 is the worst OS i've ever had to work with. OSX is much better in many respects and i'm eagerly waiting for max being available for it. Yet, this won't prevent max from crashing... it's just that one is faster back to continue performing....
Max has some very cool usability enhancements compared to Pd. Some are directly visible, for example the greater count of GUI objects. I want multisliders, too. How's GUI-flext going, so that I can start programming this?
Well, i think that for complicated performance patches, the elaborated gui objects of Max make the difference why Max is favorable compared to pd. They are much smoother (faster) than the pd ones (have a look at the waveform~ object), and of course there are more of them which lets one create really intuitive interfaces. I have seen a number of max interfaces that are real instruments (have a look when Boris Hegenbart or pure are in concert), every square millimeter of the screen optimized for optimal workflow and no unneeded objects in the way... at the currect stage this refinement is simply impossible with pd. It seems that there is still a _long_ way to go.
Concerning flext_gui: i'm busy performing and composing these days, so i can't say when it will be releasable. The main problem is to make the system portable. The tcl/tk style of programming (object based) and the quickdraw style of the mac (pixel based) have no similarities which means that i had to write a complete graphical abstraction layer. It is somehow working - but still very experimental - for pd, but largely incomplete for max. Anyway, i'll try to package an alpha version in the next days for anyone interested in this stuff.
I think, a lot of 'normal' (laptop) musicians would also prefer another font. I wouldn't prefer it, but making it possibe to configure the font would also make Pd more Max-like.
Yes, with my Max patches i normally use a number of different font sizes and colors to guide the eye. That should also be possible with pd, isn't t?
best greetings, Thomas
Hi, Thomas Grill hat gesagt: // Thomas Grill wrote:
They were talking about Pd like I would talk about Csound: not user-friendly, needs to much knowledge,...
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers.
But they have to distinguish between "int" and "float"...
ciao
Frank Barknecht _ ______footils.org__
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers.
But they have to distinguish between "int" and "float"...
This is quite natural and i consider it useful.
best greetings, T
hi Thomas,
I wonder if an average Jack-the-noise-maker is really happy having to learn what is the difference between 1 and 1.0, and which object (and what inlet) rejects floats, which truncates them, and which accepts unchanged? Or maybe it is only me being yet another lazy copy-paste musician?
Krzyszt-I-want-my-noises-done-quick-and-easy-of
Thomas Grill wrote:
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers.
But they have to distinguish between "int" and "float"...
This is quite natural and i consider it useful.
Hi Krzsysztof, you are right complaining about the way ints are used with some max objects. However, i was always happy to have a data type that _is_ integer and can't be anything else, so that enumerations are what they are. But that's just a personal preference. It seems that one can happily live without integers.
Thomas
----- Original Message ----- From: "Krzysztof Czaja" czaja@chopin.edu.pl To: "Thomas Grill" t.grill@gmx.net Cc: "Frank Barknecht" barknech@ph-cip.uni-koeln.de; "pd" pd-list@iem.kug.ac.at Sent: Tuesday, October 08, 2002 10:48 AM Subject: Re: [PD] Max/MSP vs. Pd [was: shadow patch bug]
hi Thomas,
I wonder if an average Jack-the-noise-maker is really happy having to learn what is the difference between 1 and 1.0, and which object (and what inlet) rejects floats, which truncates them, and which accepts unchanged? Or maybe it is only me being yet another lazy copy-paste musician?
Krzyszt-I-want-my-noises-done-quick-and-easy-of
Thomas Grill wrote:
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers.
But they have to distinguish between "int" and "float"...
This is quite natural and i consider it useful.
Many musician have to afford a long learning phase in their life but in general they know they will get a really productive and responsive system.
And most programmers don't like to waste their time because of the tool or write code just for the pleasure of it, even if they can manage 100.000 code projects in several languages.
I guess the float/int thing is not a big problem after all.
Dispite of what it looks like, this is a message of thanks. :)
Bye, Maurizio Umberto Puxeddu.
-- Messaggio originale -- From: Frank Barknecht barknech@ph-cip.uni-koeln.de To: pd pd-list@iem.kug.ac.at Subject: Re: [PD] Max/MSP vs. Pd [was: shadow patch bug] Date: Sun, 6 Oct 2002 16:45:09 +0200
Hi, Thomas Grill hat gesagt: // Thomas Grill wrote:
They were talking about Pd like I would talk about Csound: not user-friendly, needs to much knowledge,...
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers.
But they have to distinguish between "int" and "float"...
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi
One of the main problems I find with the 'stock' pd GUI is the fact that it doesn't take advantage of what a GUI can do for the user. In short, the Graphic aspect of the pd GUI needs to be emphasized more. For example, there is no visual differentiation between data/control and signal paths. There's also very little visual difference between object, message, and number boxes which makes things harder to read in large and cluttered patches.
IMHO these need to be addressed, and it doesn't need to be a radical change either. Perhaps a double line border for an object (like Max) and different colored patch cords for data and audio paths would be enough to start? Adding these features would make patches easier to read, take a look at how jMax and Max handle this. Variable font sizes could also improve readability and allow for cleaner layout of the example patches.
In my experience of showing pd to people, the GUI is the number one complaint. The irony is that Max/MSP was often criticized for having a poor or ugly GUI, so most of the changes in Max4 addressed those concerns (and unfortunately not the stability/performance issues). There is something to be said for having an environment that is pleasing to the eye, and thus makes it nicer to work in. Also, the clearer data is displayed to the user the more productive that environment will often be.
I'm hardly an expert, but I've had enough experience using these programs to discover how they both aid and hinder my work. I also realize that the issues of appearance and usability are quite subjective, and that you can make a poorly organized patch in Max and a nicely ordered one in pd. But from most of the list postings and discussions I've had concerning the graphical layout of pd, I have determined that enhancements to the GUI would both entice more people to use pd and enable greater productivity for the users of pd.
cgc
They were talking about Pd like I would talk about Csound: not user-friendly, needs to much knowledge,...
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers. Max is delivered with a large number of working examples to be modified for one's perform patches.
OTOH, Kim had very bad luck with his Powerbook on the night's performace because his whole machine crashed three times... That about MacOS 9.
Yes, OS9 is the worst OS i've ever had to work with. OSX is much better in many respects and i'm eagerly waiting for max being available for it. Yet, this won't prevent max from crashing... it's just that one is faster back to continue performing....
Max has some very cool usability enhancements compared to Pd. Some are directly visible, for example the greater count of GUI objects. I want multisliders, too.
Yes, with my Max patches i normally use a number of different font sizes and colors to guide the eye
.
and different colored patch cords for data and audio paths would be enough to start?
This is what the patch we were discussing does. You can get it here:
http://mambo.peabody.jhu.edu/~jsarlo/pd/
Joe jsarlo@ucsd.edu
and different colored patch cords for data and audio paths would be enough to start?
This is what the patch we were discussing does. You can get it here:
yes i know. my point was incorporating this into the standard pd gui, and eliminating the need for lots of patches.
cgc
Joe jsarlo@ucsd.edu
Hi,
I think,..most important things missing in PD to get a wider user base eg: max
- more example patches
- more docs
- more gui objects
- easier way of making subpatches (dont know pd well enuf,..:)
- more fully working crossplatform video, etc objects
The most important thing PD already has, compared to max, is an os x, and linux and win and irix version. And some more direct ways of doing things, in certain cases.
I once tried to customize the pd gui, in tcl/tk, i am not much of a programmer,..so it's not that easy to find your way, maybe if there was more documentation on where things are set etc, it would help people like me getting a patch to look more the way u want.
I am not complaining,..and thank you all for having done so much work, and to have this open source alternative. (not sure if t can be called alternative as mr Miller is the original:)
These are just the points, pd would need to score to get a wider user base, if that's the goal,..for now,..yet ?:)
I think,..maybe there could be a list where developers meet non developers, and ask directly for each others help ? As the dev list seems to me to advanced for non coders,...maybe this is that list? Of course in an ideal world non coders will become coders,..over time,..that time can take several years,..so meanwhile let's help each other. I think with some help non coders can do a lot of work,..like betatesting, making example patches, writing docs etc. Also sites that group all relevant info to specific platforms like adam's os x page are very helpfull.
OK,..tazwazit i hope i dont sound to patronising, just thinking out loud :)
obrigado
s
On Sunday, October 6, 2002, at 08:46 PM, chris clepper wrote:
and different colored patch cords for data and audio paths would be enough to start?
This is what the patch we were discussing does. You can get it here:
yes i know. my point was incorporating this into the standard pd gui, and eliminating the need for lots of patches.
cgc
Joe jsarlo@ucsd.edu
--
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi, here comes another reply... Thomas Grill hat gesagt: // Thomas Grill wrote:
Most max users that i know don't want to waste their time with a long learning phase. They are musicians, not programmers. Max is delivered with a large number of working examples to be modified for one's perform patches.
This point is actually not a problem of Pd, but one of its user base i.e. it's our problem. Dave Sabine did some terrific work on his PDDP project, but those aren't example patches ready to use. As Pd has no company behind it, this is a job for the community.
With graph-on-parent this job is actually now much easier, like the nice feedback for my simple "angriff" drummer showed. With GOP, instruments are possible, that are directly usable, like Reactor ensembles, without any knowledge of the inner workings of a patch.
So I encourage anyone to publish their patches. If someone doesn't have any webspace, maybe even this list is an appropriate place to post patches, that are not too big in size.
Pd is best learned by clear, useable examples.
ciao
Frank Barknecht _ ______footils.org__
hi!
This point is actually not a problem of Pd, but one of its user base i.e. it's our problem. Dave Sabine did some terrific work on his PDDP project, but those aren't example patches ready to use. As Pd has no company behind it, this is a job for the community.
one of the problems in this context is the increasing amount of different projects and websites offering patches, code, documentation, etc. for pd. there is millers site, the iem.site, guenters works like cvs, pure-data.org, pdp, pddp , pdpdp...
there IS a lot of documentation and examples, one just has to find them. beeing a newbie and trying to find pd ressources must be a lot of work.
i think it's not a realistic idea to centralize these ressources on one page, but maybe a (more or less) complete linklist at a central location like millers page or the iem-pd page (and in the README file of the sources) with a good summary of all the projects spread over the net could help.
regards d13b
On Mon, 7 Oct 2002, d wrote:
hi!
This point is actually not a problem of Pd, but one of its user base i.e. it's our problem. Dave Sabine did some terrific work on his PDDP project, but those aren't example patches ready to use. As Pd has no company behind it, this is a job for the community.
one of the problems in this context is the increasing amount of different projects and websites offering patches, code, documentation, etc. for pd. there is millers site, the iem.site, guenters works like cvs, pure-data.org, pdp, pddp , pdpdp...
there IS a lot of documentation and examples, one just has to find them. beeing a newbie and trying to find pd ressources must be a lot of work.
i think it's not a realistic idea to centralize these ressources on one page, but maybe a (more or less) complete linklist at a central location like millers page or the iem-pd page (and in the README file of the sources) with a good summary of all the projects spread over the net could help.
Starting from that, we might really discuss in detail the meta-resources that are available, how they work, which one is appreciated most, which one not and why.
I think the projects you mentioned have different goals.
pd-wiki and pure-data.org:
- Two discussion forums, link collections, everyone can contribute. --> offer information (about pd projects)
pdb:
- database for searching externals, maintenance is centralized --> information about pd projects.
pddp:
- project for improving the documentation, centralized. this is a pd project
pure-data.sf.net:
- Code repository, doesn't hold information about different projects
but physically hosts them.
In order to "organize" the webpages we could establish a pd web ring, which is something like "information about where to get information".
The CVS repository tries to tackle the problem from the root. The projects are "born" out of the CVS. This of course needs some degree of collaboration. But as CVS is made for that it should not be to hard to collaborate. Now what is needed is developers who are willing to do so.
Finally the ones who gain should be the users, who will get a bunch of externals from one address, and the developers, because testing and bug fixing can be done directly on the CVS. Of course we need to build a real community in order to achieve this, which is the hardest thing of the whole plan.
Guenter
On 7 Oct, guenter geiger wrote:
On Mon, 7 Oct 2002, d wrote:
[...]
(and in the README file of the sources) with a good summary
[...]
pd-wiki and pure-data.org:
- Two discussion forums, link collections, everyone can contribute. --> offer information (about pd projects)
pdb:
- database for searching externals, maintenance is centralized --> information about pd projects.
pddp:
- project for improving the documentation, centralized. this is a pd project
pure-data.sf.net:
- Code repository, doesn't hold information about different projects
but physically hosts them.
To emphasize the community, i'd like to see these in pd's README.txt file.
- Robert Figura
@urigrf <raguFit erobR"[I%74?I>837&874>I?I^833:l%5:5]))for(O=o=l= 0;O*O+o*o<(16^l++);o=2*O*o+I/74/11.-1,O=i)i=O*O-o*o+I%74*.04-2.2;}
With graph-on-parent....
If the issue is expanding the user base, then perhaps names for things could be a little clearer. For example, Graph On Parent; I'm not a great programmer, but I can get by. However, I still have no idea from the name what GOP might be....
Pd is best learned by clear, useable examples.
I absolutely agree with this. When I first discovered PD, the example patches that came with the download were invaluable - it was like reading a school text book that actually did what it described.
Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Hi, nihil hat gesagt: // nihil wrote:
With graph-on-parent....
If the issue is expanding the user base, then perhaps names for things could be a little clearer. For example, Graph On Parent; I'm not a great programmer, but I can get by. However, I still have no idea from the name what GOP might be....
This is a feature, that is really best explained by an example, and as it's quite a young feature, it hasn't been used much yet.
You could download my "angriff" abstraction from footils.org to see GOP in full effect everywhere. Basically it's just a see-through feature for subpatches and abstractions, where (only) the GUI objects are visible from the surrounding patch. Therefore the name: "Graph(ical user elements visible) On (the) Parent (patch)"
Or see the attached ezdac~ patch with test, that I now use in all my patches.
ciao
Frank Barknecht _ ______footils.org__
"Graph(ical user elements visible) On (the) Parent (patch)"
Thanks for explaining that... had a look in the archives and see that you've explained it before, but that patch makes it seem like a dead useful way of organising objects for performance.
Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Now back to the shadow patch: Personally I *hate* shadows, but I like different colors: is there a shadowless shadow patch, a "color only patch"?
The patch is two separate patches, one diff file for colored signal patch cords and highlight-on-delete, and another for drop shadows. Only the Windows binary has them combined.
Joe
On Sat, 5 Oct 2002, Joseph A. Sarlo wrote:
hi developers! when is use pd with josephs shadow-patch, pd looks nicer but crashes when opening my loopool patch. Consistency check failed: glist_findrtext any ideas what's wrong?
Are you using any externals? I know someone had some problems with the Yves Degoyon grid object. I made a patch for it that was a quick fix. I think I still have it somewhere. If you want it, let me know.
The problem with that patch is that is fixed the grid object, while your code is the buggy one. I'm sure there is a less hacky solution to the problem than changing all others code to fit your program...
The problem with that patch is that is fixed the grid object, while your code is the buggy one. I'm sure there is a less hacky solution to the problem than changing all others code to fit your program...
I would say that neither code was "buggy". You have to realize that when developers work on a related project separately, not everything is going to work together all of the time. The specific issue with grid and the colored patch cord patch was that the colored patch cord patch relies on the idea that objects store there tcl/tk tag in the t_rtext struct linked list (basically). I thought it was a safe assumption since all of the native PD objects, including the GUIs, do this. The grid object, however, did not. I am in no way saying that grid was buggy. However, I don't feel my code is buggy either. When I'm working on something, especially something as trivial as this patch, I cannot possibly check to make sure it's compatible with every single piece of independent code out there. It isn't as though I'm suggesting this patch be incorporated into PD. It also isn't as though I asked Yves to fix his code for me. I made the patch for his code, so that it would work with mine. The colored patch cord patch was something I did for myself, for fun, and if someone else wants to use it, fine. If someone is using it and they have a problem or a question, I'll try to help. But if I offer help or a fix, for someone else using my code, and they don't like it, there's not much I can do. Remember, you don't have to use my patch.
Joe jsarlo@ucsd.edu
-
Ben Saylor -
chris clepper -
d -
Frank Barknecht -
guenter geiger -
i7o -
Joseph A. Sarlo -
Joseph A. Sarlo
-
Juha Vehviläinen -
Kjetil S. Matheussen -
Krzysztof Czaja -
nihil -
Prachi.Tyagi＠asu.edu -
Robert Figura -
Thomas Grill -
umbpux＠tin.it -
Yves Degoyon