Your concept is a great improvement over built-in array list view. It
index no matter how long the array is. Thank you for this new year's
present.
I figured out some refinements. Attached version has:
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'.
as a framework / language for dsp prototyping. Imagine a whole
spectrum viewer etc. Each tool would do a small job and they could be
chained together by array name and index offset. Yummy.
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>
>