On Mon, 16 Feb 2004, Frank Barknecht wrote:
On Mon, 16 Feb 2004, Frank Barknecht wrote:
Windows and XFree use different default dpi. So many of the patches created on Windows use a 12 font, while many Linux users prefer font size 10. 10 looks tiny on Windows, whereas 12 looks rather large on Linux. The problem is, that tighly spaced objects will overlap on Linux, but might look nice on Windows. Actually your changes probably won't collide with this particular problem.
Ok, I'll keep that in mind...
Did you do some performance tests?
No, haven't yet, and prolly will try that only much later, inserting a piece of code in both versions of Pd (i mean devel_0_37 and mine) and measuring things like number of dropouts and client-server bandwidth and such. I am confident that my version will eventually become faster than devel_0_37, at least when configured with the classic Pd layout. I am rewriting a bunch of code in Tcl/Tk, which may seem slower, except that the way I do it it reduces the client-server bandwidth being used, which is good, especially wrt dropouts.
On Wed, 18 Feb 2004, Frank Barknecht wrote:
I'd prefer it the other way around and strongly would vote for manual segmenting instead of automatic. No algorithm would be able to tell, which patch cords *I* would like to be segmented,
I very well understand that, and my segmentation algorithms prolly will be crappy at first, so a manual mode is a must =)
and which ones I would like straight. Also I wonder: How would an algorithm look like that deals with ambiguities created by segmenting? Would it just not allow cords to run on top of each other? Running on top could be cleaner in some cases, but it also would be hazardous for reading a patch in a lot of other cases.
It would use a particle system such that the nodes of the cords repulse each other into nonambiguous positions. (Just kidding.)
Seriously, if anyone wants to try writing that algorithm, it would be nice... =)
Mathieu Bouchard http://artengine.ca/matju