new object i'd like for the holidays
Hi all,
I've been really getting into using jitter matrices (matrixes? never
sure about the proper plural for those) as large-scale arrays for
data storage and retrieval. I was a bit hesitant at first, because
we need to send them messages like "getcell X X X" and then parse out
data of the form "cell X X X val X X X X", which may change depending
on the matrix dims/type (and I try to avoid regexp whenever possible,
just to stay sane). But I have to say, this is a really nice way of
storing and retrieving and manipulating large amounts of data. Not
that it can't be improved...
What bothers me still are the messages I need to send. If a matrix
is a virtual object, referencing some hazy collection of memory
blocks somewhere in my mysterious computer, why can't the cells be
treated this way to? Why can't there be an object like
[jit.matrixcell myMatrix X X X] that refers to a single cell of a
matrix, and when banged, spits out the contents of that cell, or when
a list comes in, set the cell it refers to to the list contents? It
could have a few messages like "cell X X X" to update the cell it
referenced, and "refer MATRIX_NAME" to change the matrix it pointed
to, and spit out errors if that matrix didn't exist. Really simple,
no parsing necessary, unless it also had a right outlet from which
you could get all the usual matrix info stuffs, like dims, type,
name, etc.
I'd do this, but a quick look at the jitter code is like peeking
inside a manhole cover in NYC. Lots of wires, pitfall, wet and angry
alligators... best not to muck about there unless you have some time
on your hands, and steel boots.
So, is this a practical idea?
Happy Holidays!
-Evan
what about jit.submatrix -> jit.iter?
wes
hi wes
i've seen you use this technique before, it's a generally a good
technique and I actually started out using it on a few projects, BUT
I have found examples where this breaks badly under high stress.
Unfortunately, I can't find any of them right now, as luck would have
it. I will dig some more. I do remember that if you're constantly
changing the jit.matrix at the top, the jit.submatrix may not update
fast enough or in sync with your changes, whereas if you use getcell/
setcell you have a much better chance of getting the correct (for
your purposes) data. Dang, I wish I could find that patch so I can
illustrate this happening. It was not a bug but a timing issue that
needed to be taken into account.
Also, I don't like jit.iter. Too easy to make it do horrible things
to your computer. That, and I just find it conceptually opaque, by
which I mean try explaining it properly to someone else. It does too
much in a single object, for general purposes - an object that could
get you a single cell, where you have exact control over which cell
it points to (so you can iterate through it yourself) is generally
much more useful to me than having to remember what jit.iter's
outlets do and which I can ignore. Just my 2 cents (and I do use
jit.iter a lot these days).
Now that you mention it, since jit.iter already does this, and its
close cousin jit.spill has source code available in the Jitter dev
kit, maybe I can (eventually) roll my own object.
Cheers
Evan
On Dec 27, 2007, at 2:54 PM, Wesley Smith wrote:
> what about jit.submatrix -> jit.iter?
>
> wes
>
>
Not to deter you from making whatever object suits your needs in C,
but the following sounds like it would be relatively simple to make
as an abstraction using patcherargs. As for cell X X X val X X X X,
to get the value will always be zl slice dimcount+2, where dimcount
can be found using zl len on the output of the getdim message, or
even simpler, zl ecils planecount.
-Joshua
On Dec 27, 2007, at 4:42 AM, evan.raskob [lists] wrote:
> Hi all,
>
> I've been really getting into using jitter matrices (matrixes?
> never sure about the proper plural for those) as large-scale arrays
> for data storage and retrieval. I was a bit hesitant at first,
> because we need to send them messages like "getcell X X X" and then
> parse out data of the form "cell X X X val X X X X", which may
> change depending on the matrix dims/type (and I try to avoid regexp
> whenever possible, just to stay sane). But I have to say, this is
> a really nice way of storing and retrieving and manipulating large
> amounts of data. Not that it can't be improved...
>
> What bothers me still are the messages I need to send. If a matrix
> is a virtual object, referencing some hazy collection of memory
> blocks somewhere in my mysterious computer, why can't the cells be
> treated this way to? Why can't there be an object like
> [jit.matrixcell myMatrix X X X] that refers to a single cell of a
> matrix, and when banged, spits out the contents of that cell, or
> when a list comes in, set the cell it refers to to the list
> contents? It could have a few messages like "cell X X X" to update
> the cell it referenced, and "refer MATRIX_NAME" to change the
> matrix it pointed to, and spit out errors if that matrix didn't
> exist. Really simple, no parsing necessary, unless it also had a
> right outlet from which you could get all the usual matrix info
> stuffs, like dims, type, name, etc.
>
> I'd do this, but a quick look at the jitter code is like peeking
> inside a manhole cover in NYC. Lots of wires, pitfall, wet and
> angry alligators... best not to muck about there unless you have
> some time on your hands, and steel boots.
>
> So, is this a practical idea?
>
>
> Happy Holidays!
>
> -Evan