Hi katja,Thanks! I'll have a look at your revisions. "tabview" sounds like a decent name, as long as it isn't used anywhere else in Pd-land. Just an fyi-- I gutted all the arrayviewlist functionality for the GUI port of Pd-l2ork. Best,Jonathan
On Friday, January 1, 2016 2:24 PM, katja <katjavetter@gmail.com> wrote:
Hi Jonathan,
Your concept is a great improvement over built-in array list view. It is now a very useful debug tool since you can jump to any desired index no matter how long the array is. Thank you for this new year's present.
I figured out some refinements. Attached version has:
It is temporarily called 'arraylistview2' for evaluation, and a patch with tests is included in the tarball. An issue with the name anyhow is confusion between 'arraylistview' and 'arrayviewlist'. Pd's built-in method goes with message 'arrayviewlistnew'. Maybe it could be a completely different name, like 'tabviewer'.
Jonathan, your approach makes me realize once more how powerful Pd is as a framework / language for dsp prototyping. Imagine a whole collection of debug instruments along the same line, like zoom viewer, spectrum viewer etc. Each tool would do a small job and they could be chained together by array name and index offset. Yummy.
cheers, Katja
On Wed, Dec 30, 2015 at 4:15 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I did some revisions on an abstraction replacement for the listview button in the array dialog.
Rather than hook into a button buried in a dialog, I'm going to just throw the abstraction in "extra" somewhere. That's about as discoverable as it currently is, plus one could use it as a control in a patch if they wish. But the best part is that it requires zero code in the core/GUI, opening up revisions and bugfixes to anyone who can write a Pd patch.
Improvements welcome, as well as shorter abstraction name (as long as it's obscure enough not to clash with anything else).
-Jonathan
On Thursday, November 19, 2015 12:20 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
That's just a matter of creating a single number box and connecting its output to [s $0-offset].
Well, there's bounds checking, too-- the point is it's all just a Pd patch so you're unlikely to crash Pd by revising the functionality. Plus the barrier to entry is much lower than the small number of people who can untangle garray-related spaghetti code.
-Jonathan
On Friday, November 13, 2015 4:00 AM, katja katjavetter@gmail.com wrote:
That looks good Jonathan. In current array list view the entries are grouped per 1000 and arrows let you switch groups. For 'large' arrays (say one second of audio samples) this is inconvenient. Maybe your patch approach could even provide a better solution, like the option to select a specific range.
There's also method 'arrayviewclose' which I sometimes (ab)use to close a list view from within a patch. You don't want to try update an audio array list view in real time!
On Fri, Nov 13, 2015 at 1:32 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
I don't know. Something like this with the guts hidden?
I didn't do the hard stuff, like handling out-of-bounds elements if the array isn't a multiple of ten-- it's just a prototype.
So, in that method you and katja are abusing, I can forward the arrayname as well as the current $0 count. Then I can open the patch and immediately send a message to the relevant $0- receiver, and the patch will populate the value table accordingly.
And then I can get rid of all the arraylistview C/GUI code that's scattered about.
-Jonathan
On Thursday, November 12, 2015 4:55 PM, Matt Barber brbrofsvl@gmail.com wrote:
A Pd patch with what in it?
On Thu, Nov 12, 2015 at 4:21 PM, katja katjavetter@gmail.com wrote:
On Thu, Nov 12, 2015 at 8:36 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Would you mind if this opened a Pd patch instead of a tk dialog?
Could be OK if the list is editable, like current array list view.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list