lists@lowfrequency.or

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 

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, 

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 

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.

new-object-id-like-for-the-holidays

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 

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 

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.

On Dec 27, 2007, at 2:54 PM, Wesley Smith wrote:

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.

> 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 

On Dec 27, 2007, at 4:42 AM, evan.raskob [lists] wrote:

> 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 

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

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.

> 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


new object i'd like for the holidays