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

[Jonathan Wilkes]

--- On Thu, 11/25/10, Ivica Ico Bukvic <ico at vt.edu> wrote:

> From: Ivica Ico Bukvic <ico at 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" <zmoelnig at iem.at>
> Cc: pd-list at 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 at iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>