--- On Thu, 11/25/10, Ivica Ico Bukvic <i...@vt.edu> wrote:
> From: Ivica Ico Bukvic <i...@vt.edu> > Subject: Re: [PD] call for testers for L2Ork iteration of pd-extended (based > on 0.42.x branch) > To: "IOhannes m zmölnig" <zmoel...@iem.at> > Cc: pd-list@iem.at > Date: Thursday, November 25, 2010, 7:18 PM > > > thanks for sharing. > > a couple of very minor remarks: > > - - your webpage froze firefox/iceweasel on my eeepc > the first time i > > accessed it; i assume this is due to the animated > tagcloud. is there any > > conceptual reason for maaking a navigation aid eat > 100% on 2 cores? > > I wish I had an answer for you as the cloud is pure > javascript and it > works just fine on my MSI wind U100 netbook (single core > with > hyperthreading, so I guess you could call it Intel's fake 2 > cores) as > well as on my Android phone (where it is somewhat slow but > does not > impede the rest of the webpage). I would love to hear from > the others as > well regarding this, because if this problem is more > widespread I will > look into altering/replacing it with something else. > > > > > once i managed to download it, i only played a few > minutes with it, so.. > > > > - - when releasing tarballs you should get rid of the > .svn folders; these > > hold a copy of all files, so you could reduce the size > of the unpacked > > bundle to about 50% > > Unfortunately in my case it had no difference whatsoever as > I've not > used svn on this branch in some time. I believe the > binaries are what is > causing the tarball to be as large as it is. At any rate, I > will > reupload it without the .svn folder. > > > > > - - the "magnifying glass" (i think you all refer to > the "Patch cord > > viewer" (or "cord inspector" how i would call it) by > this term), is a > > very nice feature. > > what i find weird is, that i can only switch to "cord > viewing" when in > > edit mode; Ctrl-r in Run-mode simple doesn't do > anything; i would expect > > to switch my patch into run mode if needed > > Well, this is the way original Sarlo's code works, so I > haven't given it > much thought until now. Now that you brought it up, I feel > like the > current design makes more sense as the cord monitoring > undoubtedly saps > some of the CPU and as such one would probably not want to > run it in > "runtime/performance" mode anyhow. OTOH if you are looking > to monitor > what passes through the cords, this in and of itself > suggests you are > likely troubleshooting something and as such are looking to > edit the > patch anyhow, so based on these two observations alone I > would say the > current behavior makes sense. Then again, I may be missing > something > here in which case I would certainly like to hear opinions > from others > as well. > > All that said, I like your term better. > > > > > - - the "inlet highlighting" (this looks more like a > "magnifying glass" to > > me) is a nice idea but it doesn't really help yet. > e.g. with objects > > that have more inlets then available width (e.g. > [pix_info]) you still > > have the same problem as before (though a bit bigger); > i also think that > > the magnification amount is a bit too small, but this > might be due to my > > very small screen size (at first i wouldn't even > notice a real > > difference then to the original connection cursor). it > would probably be > > a good idea to let the user change the amount of > magnification) > > > > Good idea. I'll add this to the todo (shouldn't be too > hard--it really > simply boils down to designing the edit menu and providing > appropriate > hooks). That said, what would be even better is simply > adding a tooltip > that reflects which inlet/outlet is selected and what it > does. This was > recently discussed and with the highlighting in place this > would boil > down to simply adding another two arrays to glist and > filling them with > per-object descriptors (this last part being the biggest > pain as it > would have to be added pd-wide). In the interim, it could > simply check > for null entries and ignoring those that have not been > implemented. > > I think I'll take a stab at this one soon. Before you do, you should ask Miller what exactly his comments mean in: http://sourceforge.net/tracker/index.php?func=detail&aid=1056914&group_id=55736&atid=478072 Also see: http://sourceforge.net/tracker/index.php?func=detail&aid=2838176&group_id=55736&atid=478072 > > > - - why is the default selection color "orange/red"? > is this a pd-extended > > thing? for me this is very close to the > error-indicating color "red" > > (e.g. when an object fails to create) > > Because I find it hard to discern between blue and black > (selected vs. > deselected) on such thin lines that constitute most of the > gui and which > occurs a lot more often than the red invalid objects. That > said, I will > up the width on the red objects which should solve this > problem. I find the orange text _very_ difficult to read. > > > > > - - something i think is only inherited from > pd-extended, but whiich makes > > me shout out loud, is that when i start pd-l2ork it > creates a > > "pd-externals" folder in my home directory. even if i > don't do anything > > apart from opening! > > i think this is _very_ rude. > > This is indeed inherited from pd-extended and I think we > need to hear > from Hans on this one as I certainly wish to maintain as > much > pd-extended compatibility as reasonably possible. Hans? > > Many thanks for your feedback! > > Best wishes, > > Ico > > > > _______________________________________________ > Pd-list@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list