[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)

Ivica Ico Bukvic ico at vt.edu
Thu Nov 25 19:18:30 CET 2010


> 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.

> - - 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.

> 
> - - 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





More information about the Pd-list mailing list