[PD] call for testers for L2Ork iteration of pd-extended (based on 0.42.x branch)
hans at at.or.at
Sun Nov 28 02:16:19 CET 2010
On Nov 25, 2010, at 1:18 PM, Ivica Ico Bukvic wrote:
>> 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?
> 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,
>> - - when releasing tarballs you should get rid of the .svn folders;
>> hold a copy of all files, so you could reduce the size of the
>> 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
>> edit mode; Ctrl-r in Run-mode simple doesn't do anything; i would
>> 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
> 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.
I think it makes a lot of sense to only have the Cord Inspector
available during Edit Mode, like Ico said, play/run mode should not
have other things drawing on the CPU.
>> - - 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
>> have the same problem as before (though a bit bigger); i also think
>> 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
> that reflects which inlet/outlet is selected and what it does. This
> recently discussed and with the highlighting in place this would boil
> down to simply adding another two arrays to glist and filling them
> 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.
There is a tooltip patch in the patch tracker from Günter Geiger. Its
a good idea, but needs to be implemented differently, without changing
the core data structures. I don't remember the details, but I think
it shouldn't be hard to do.
>> - - why is the default selection color "orange/red"? is this a pd-
>> 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
> occurs a lot more often than the red invalid objects. That said, I
> up the width on the red objects which should solve this problem.
Blue is the standard in all OSs I've used. But it wouldn't be hard to
make it a preference.
>> - - 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
>> 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?
Pd-extended aims to be newbie friendly. Creating this folder is one
example of that. I see no harm in Pd-extended creating this folder,
but those who don't like it rarely use Pd-extended anyway.
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
More information about the Pd-list