new object i'd like for the holidays


    Dec 27 2007 | 12:42 pm
    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

    • Dec 27 2007 | 2:54 pm
      what about jit.submatrix -> jit.iter?
      wes
    • Dec 27 2007 | 5:03 pm
      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 > >
    • Dec 27 2007 | 6:23 pm
      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