Wetterberg

I am building an application in Jitter, and have come across this possibly very simple, yet baffling problem. My matrices keep switching planecount on me?!?

Now, this is absolutely user error at the root, but surely @adapt 0 should prevent this from ever happening? I need a jit.matrix 1 char 16 16, and it keeps screwing up for me. I have attached a small picture of the infected area for your perusal in lieue of a readable patch to give you.

Cheers for any insights... this is driving me nuts, to be honest.

hi all,
I am building an application in Jitter, and have come across this possibly very simple, yet baffling problem. My matrices keep switching planecount on me?!?

Cheers for any insights... this is driving me nuts, to be honest.


matrix-resizing-problem

On 30 janv. 08, at 01:11, Andreas Wetterberg wrote:

> I am building an application in Jitter, and have come across this 

> possibly very simple, yet baffling problem. My matrices keep 

> Now, this is absolutely user error at the root, but surely @adapt 0 

> should prevent this from ever happening? I need a jit.matrix 1 char 

> 16 16, and it keeps screwing up for me. I have attached a small 

> picture of the infected area for your perusal in lieue of a readable 

> Cheers for any insights... this is driving me nuts, to be honest.

You're right, @adapt 0 force the matrix to not adapt to the 

characteristic of the input matrix, but in [jit.rubix] support only 4 

planes (and @type char). So no matter what you do, [jit.rubix] will 

output a 4 planes matrix. You probably need a [jit.unpack] if you want 

> hi all,
> I am building an application in Jitter, and have come across this  
> possibly very simple, yet baffling problem. My matrices keep  
> switching planecount on me?!?
>
> Now, this is absolutely user error at the root, but surely @adapt 0  
> should prevent this from ever happening? I need a jit.matrix 1 char  
> 16 16, and it keeps screwing up for me. I have attached a small  
> picture of the infected area for your perusal in lieue of a readable  
> patch to give you.
>
> Cheers for any insights... this is driving me nuts, to be honest.

You're right, @adapt 0 force the matrix to not adapt to the  
characteristic of the input matrix, but in [jit.rubix] support only 4  
planes (and @type char). So no matter what you do, [jit.rubix] will  
output a 4 planes matrix. You probably need a [jit.unpack] if you want  
to extract only one plane.

On Jan 29, 2008, at 4:11 PM, Andreas Wetterberg wrote:

> picture of the infected area for your perusal in lieue of a 

> Cheers for any insights... this is driving me nuts, to be 

Look at jit.rubix.help and/or the html reference page. This object 

only accepts 4 plane char matrices. So your attempt to change this is 

being overridden by the behavior of the object.

You'll have to find either another solution or work with 4 plane 

> hi all,
> I am building an application in Jitter, and have come across this  
> possibly very simple, yet baffling problem. My matrices keep  
> switching planecount on me?!?
>
> Now, this is absolutely user error at the root, but surely @adapt 0  
> should prevent this from ever happening? I need a jit.matrix 1 char  
> 16 16, and it keeps screwing up for me. I have attached a small  
> picture of the infected area for your perusal in lieue of a  
> readable patch to give you.
>
> Cheers for any insights... this is driving me nuts, to be  
> honest.

Look at jit.rubix.help and/or the html reference page. This object  
only accepts 4 plane char matrices. So your attempt to change this is  
being overridden by the behavior of the object.

You'll have to find either another solution or work with 4 plane  
matrices and ignore the other planes.

Yeah, the problem did also appear to occur with regular jit.matrix'es, 

though... I figured that as long as I had adapt 0 on both the problem 

shouldn't be permeating the sytem like it did... hm. Thanks for your 

> On Jan 29, 2008, at 4:11 PM, Andreas Wetterberg wrote:

>> I am building an application in Jitter, and have come across this 

>> possibly very simple, yet baffling problem. My matrices keep 

>> Now, this is absolutely user error at the root, but surely @adapt 0 

>> should prevent this from ever happening? I need a jit.matrix 1 char 

>> 16 16, and it keeps screwing up for me. I have attached a small 

>> picture of the infected area for your perusal in lieue of a readable 

>> Cheers for any insights... this is driving me nuts, to be 

> Look at jit.rubix.help and/or the html reference page. This object 

> only accepts 4 plane char matrices. So your attempt to change this is 

> being overridden by the behavior of the object.

> You'll have to find either another solution or work with 4 plane 

Yeah, the problem did also appear to occur with regular jit.matrix'es, 
though... I figured that as long as I had adapt 0 on both the problem 
shouldn't be permeating the sytem like it did... hm. Thanks for your 
help, Joshua and EJ.

Joshua Kit Clayton skrev:
>
> On Jan 29, 2008, at 4:11 PM, Andreas Wetterberg wrote:
>
>> hi all,
>> I am building an application in Jitter, and have come across this 
>> possibly very simple, yet baffling problem. My matrices keep 
>> switching planecount on me?!?
>>
>> Now, this is absolutely user error at the root, but surely @adapt 0 
>> should prevent this from ever happening? I need a jit.matrix 1 char 
>> 16 16, and it keeps screwing up for me. I have attached a small 
>> picture of the infected area for your perusal in lieue of a readable 
>> patch to give you.
>>
>> Cheers for any insights... this is driving me nuts, to be 
>> honest.
>
>
> Look at jit.rubix.help and/or the html reference page. This object 
> only accepts 4 plane char matrices. So your attempt to change this is 
> being overridden by the behavior of the object.
>
> You'll have to find either another solution or work with 4 plane 
> matrices and ignore the other planes.
>
> -Joshua
>
> .
>


On 30 janv. 08, at 02:40, Andreas Wetterberg wrote:

> Yeah, the problem did also appear to occur with regular 

> Yeah, the problem did also appear to occur with regular  
> jit.matrix'es, though...

matrix resizing problem