meeble

is there an easy way to scale every value in a matrix? I mean just like the scale object, which allows me to set an low and high input and a low and high output. i.e. take all matrix cell values from 205 to 255 and scale them from 127 to 255.

The jit.scalebias doesn't do this, and I can't seem to figure out how to scale like that using jit.op

any ideas? I've considered using jit.spill and a several [scale] objects, but that seems like a tedious solution.

is there an easy way to scale every value in a matrix?  I mean just like the scale object, which allows me to set an low and high input and a low and high output.  i.e. take all matrix cell values from 205 to 255 and scale them from 127 to 255. 

any ideas?  I've considered using jit.spill and a several [scale] objects, but that seems like a tedious solution.


scale-values-for-every-cell-in-matrix

Alright, I think this is loosely still on topic.

I'm using a matrixctrl object to manage a gates, and have modified the phasor~ based clock (originating from Gregory Taylor's Step by Step book) which is capable of subdividing the bar down to any tuplet up to 128 (at present). 

I feel like the logical next step would be to scale (or down/ up-sample) the pattern (column-wise -- quantizing the cell data to the lower/ scaling to the higher, rather than just truncating or extending), which led me here. 

I've read through the jit.gen reference and have seen the list of operators under jit.op, but have seen nothing with regard to the scale operator. 

I will say I found the jit.gen example snippet (

) and have achieved the desired scaling behavior (X-wise) by detaching [swiz y] and [sin], but I'm struggling to figure out how to situate(/ format) jit.gen to communicate with (

Alright, I think this is loosely still on topic.

I'm using a matrixctrl object to manage a gates, and have modified the phasor~ based clock (originating from Gregory Taylor's Step by Step book) which is capable of subdividing the bar down to any tuplet up to 128 (at present). 

I feel like the logical next step would be to scale (or down/ up-sample) the pattern (column-wise -- quantizing the cell data to the lower/ scaling to the higher, rather than just truncating or extending), which led me here. 

I've read through the jit.gen reference and have seen the list of operators under jit.op, but have seen nothing with regard to the scale operator. Have I managed to overlook something or?

I will say I found the jit.gen example snippet (gen.waves) and have achieved the desired scaling behavior (X-wise) by detaching [swiz y] and [sin], but I'm struggling to figure out how to situate(/ format) jit.gen to communicate with (receive/ send cell data from/ to) matrixctrl. 

Hey Aaron, (jitter) matrix != matrixctrl or matrix~, they are quite unrelated.

My apologies. To clarify — am I wrong in thinking that I should be able to convert a matrixctrl list to a format that jit.matrix is able to understand, and populate said matrix with those black & white values? (To then process and convert back.)

Perhaps there’s a more efficient way (using zl/ other forms of list processing) to wrap/ scale/ fold and/ or whatever else to a matrixctrl list, but I’m not that adept and such methods haven’t occurred to me.

The thing that gave me the idea was using jit.noise/ jit.matrix to populate matrixctrl with cells — I assume if that’s possible, the reverse should be possible as well. My apologies if I’m mistaken.

But the question is – what do you want to achieve: neither (imo) jitter matrix nor matrixctrl are primary meant as a step sequencers, but can be used that way. If you want to scale values of vertical position you can do fe. this:

Thanks so much for the help and suggestions, guys.

This is the general concept -- Basically pattern resampling (up or down in resolution/ step length):

In Gregory Taylor's book, he uses [matrixctrl] to manage gates (

) in tandem with [live.step]. I was wanting to have the option of modulating the step length/ column count without truncating or extending the pattern.

1. The conversion back to matrixctrl list appears to be getting thrown by the changing column count. 

2. It'd be nice if there were a way of toggling whether repeats were represented or 

3. Perhaps this isn't necessary, and there's a way of doing this without using a conversion to jit.matrix. (Perhaps KLSDIZ's suggestion of using scale would work in this manner, but I figured I'd go ahead and share this, incase my desired result was unclear.)

Thanks so much for the help and suggestions, guys.

This is the general concept -- Basically pattern resampling (up or down in resolution/ step length):


In Gregory Taylor's book, he uses [matrixctrl] to manage gates (or counts that sound) in tandem with [live.step]. I was wanting to have the option of modulating the step length/ column count without truncating or extending the pattern.

My current thoughts are:
1. The conversion back to matrixctrl list appears to be getting thrown by the changing column count. 

2. It'd be nice if there were a way of toggling whether repeats were represented or 
 ignored when returning to matrixctrl. 

3. Perhaps this isn't necessary, and there's a way of doing this without using a conversion to jit.matrix. (Perhaps KLSDIZ's suggestion of using scale would work in this manner, but I figured I'd go ahead and share this, incase my desired result was unclear.)


while it can be cool to use a matrix to handle or store and recall data in bunches, i dont think it is required to do it for a simple 2 D matrix. 

i also dont think you need to use float32 to store 0s and 1.

it starts making sense when you use one matrix to store 10 such sequences, each of 5 rows, in 10 dimensions.

also, if you use use a matrix as "database" anyway, you could as well get rid of the matrixcontrol object and use the jit.pwindow as GUI object:


while it can be cool to use a matrix to handle or store and recall data in bunches, i dont think it is required to do it for a simple 2 D matrix. 

i also dont think you need to use float32 to store 0s and 1.

it starts making sense when you use one matrix to store 10 such sequences, each of 5 rows, in 10 dimensions.

also, if you use use a matrix as "database" anyway, you could as well get rid of the matrixcontrol object and use the jit.pwindow as GUI object:

[route mouseidle]
[unpack 0 0]
[/ 10] [/ 10]
...


Re: float32 -- lol, that's fair, yeah. *further indicating my comparable inexperience*

Re: [jit.pwindow] -- Oh, interesting. I'm not sure I've encountered that being used in place of [matrixctrl]. Why would anyone use [matrixctrl], if [jit.pwindow] is capable of serving the same function, while offering more flexibility? (Or at least, why is [matrixctrl] as ubiquitous as it seems to be?) (

And yeah, I'm currently hunting down more info on how to set it up in the way I've come to use matrixctrl.

Re: float32 -- lol, that's fair, yeah. *further indicating my comparable inexperience*

Re: [jit.pwindow] -- Oh, interesting. I'm not sure I've encountered that being used in place of [matrixctrl]. Why would anyone use [matrixctrl], if [jit.pwindow] is capable of serving the same function, while offering more flexibility? (Or at least, why is [matrixctrl] as ubiquitous as it seems to be?) (And yeah, I'm currently hunting down more info on how to set it up in the way I've come to use matrixctrl.)

Re: float32 -- lol, that's fair, yeah. *further indicating my comparable inexperience* 

Re: jit.pwindow & jit.matrix -- Oh, interesting. I'm not sure I've encountered those being used in place of [matrixctrl]. Why would anyone use [matrixctrl], if they are capable of serving the same function, while offering more flexibility? (Or at least, why is [matrixctrl] as ubiquitous as it seems to be?) (

And yes, I'm currently hunting down more info on how to set them up in the way I've come to use matrixctrl. The reference/ help files were the first places I visited.)

Re: float32 -- lol, that's fair, yeah. *further indicating my comparable inexperience*  

Re: jit.pwindow & jit.matrix -- Oh, interesting. I'm not sure I've encountered those being used in place of [matrixctrl]. Why would anyone use [matrixctrl], if they are capable of serving the same function, while offering more flexibility? (Or at least, why is [matrixctrl] as ubiquitous as it seems to be?) (And yes, I'm currently hunting down more info on how to set them up in the way I've come to use matrixctrl. The reference/ help files were the first places I visited.)

Also, in the patcher attached to my second last post, the dimensions pulled from [jit.matrixinfo] (

in the subpatcher titled "jitmatrix_2_ directly above the final matrixctrl object

) are never the same dimensions as are being sent. I have no idea why this is, or why any attempt to compensate/ correct incurs a slew of error messages/ stack overflow. 

I've gone ahead and included a de-encapsulated version with additional comments in this one:

Also, in the patcher attached to my second last post, the dimensions pulled from [jit.matrixinfo] (in the subpatcher titled "jitmatrix_2_ directly above the final matrixctrl object) are never the same dimensions as are being sent.  I have no idea why this is, or why any attempt to compensate/ correct incurs a slew of error messages/ stack overflow. 

I've gone ahead and included a de-encapsulated version with additional comments in this one:

You would use a float32 matrix if you wanted to use the continuous mode of [matrix~]. When you do that, you can store the internal values of [matrix~] in a float32 [jit.matrix].

If you want to use [jit.pwindow] as interface, you can display the value as a gray level value and click & drag the mouse to raise/lower the value. I used this technique a long time ago, but was not satisfied with the user experience with this kind of matrix interface.

You would use a float32 matrix if you wanted to use the continuous mode of [matrix~]. When you do that, you can store the internal values of [matrix~] in a float32 [jit.matrix].
If you want to use [jit.pwindow] as interface, you can display the value as a gray level value and click & drag the mouse to raise/lower the value. I used this technique a long time ago, but was not satisfied with the user experience with this kind of matrix interface.

it is a pity that there are no 2-bit matrixes; you always waste a lot of space storing "on/off" type of data in an 8bit matrix channel.

@KLSDIZ: my sincerest apologies for the lack of response. I was pretty swamped in prep for a set that I didn't return once I found a fix for the issue I was experiencing. (I believe it was an ordering issue)

Anyways, I sincerely appreciate the effort to assist. <3

@KLSDIZ: my sincerest apologies for the lack of response. I was pretty swamped in prep for a set that I didn't return once I found a fix for the issue I was experiencing. (I believe it was an ordering issue)

Anyways, I sincerely appreciate the effort to assist. <3

Alright, so I've been on an off working on a solution for scaling matrixctrl cell states for a while. 

My first attempt was to convert matrixctrl to jit.matrix and resample that image, and convert back. 

1. Repeats occur when upsampling a state to a higher resolution.

2. it's not very efficient (most felt when dealing with larger column/ row counts)

So I started working on another method using two expr (I've also tried vexpr) objects to scale, with a modulo following to confine the values to the desired row/ column count. The issue I believe I'm running into with it, is that cells aren't told to clear when the resolution shifts. That and perhaps some bugs with regard to ordering operations. 

I've attached a patch including the latter attempt and some commentary. If anyone has a moment to give this a glance over, I'd love to hear their thoughts. Perhaps there's a better way of going about this than I've been able to think of. Any additional insight would be very much appreciated. 

jitfree_scalar.maxpat

Alright, so I've been on an off working on a solution for scaling matrixctrl cell states for a while. 

My first attempt was to convert matrixctrl to jit.matrix and resample that image, and convert back. 

The issues with that being: 
1. Repeats occur when upsampling a state to a higher resolution.
2. it's not very efficient (most felt when dealing with larger column/ row counts)


So I started working on another method using two expr (I've also tried vexpr) objects to scale, with a modulo following to confine the values to the desired row/ column count. The issue I believe I'm running into with it, is that cells aren't told to clear when the resolution shifts. That and perhaps some bugs with regard to ordering operations. 

I've attached a patch including the latter attempt and some commentary. If anyone has a moment to give this a glance over, I'd love to hear their thoughts.  Perhaps there's a better way of going about this than I've been able to think of. Any additional insight would be very much appreciated. 

Sincerely, 
Aaron

scale values for every cell in matrix?