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

[Hans-Christoph Steiner]

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

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

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

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


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.

.hc



----------------------------------------------------------------------------

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